10 SharePoint deployment challenges

SharePoint is one of the most flexible server applications available today. But because of its highly dynamic nature, a SharePoint deployment can quickly get out of hand. Here are some of the most common challenges in managing a SharePoint deployment.

1: Enabling Office integration

SharePoint 2007 is designed to interoperate with Office 2007 to a high degree. If you have users in your organization who are still using older versions of Office, you may find that those legacy versions become a barrier to productivity. So you may want to consider deploying the latest version of Office to all SharePoint users.

2: Preventing site sprawl

One of your primary goals must be to prevent site sprawl. You can use several techniques for this. One of the most effective is to limit the number of people who allowed to create SharePoint sites. Experience has shown that if you allow users to create new SharePoint sites on a whim, some users will create sites they don’t even need, just because they can or because they’re curious. It’s better if site creation is handled by a dedicated group of people within the IT department. I also recommend establishing clear guidelines as to who is allowed to request a new SharePoint site, and under what circumstances.

3: Site lifecycle management

Unlike typical Web sites, many SharePoint sites have a limited useful shelf life. For example, it’s common for users to create SharePoint sites that are dedicated to a specific project. When the project is complete, the site is no longer needed. So it’s important to have a procedure in place for determining which sites are still in use. When a user requests that a new site be created, you should document the name and contact information of the person making the request, as well as the URL of the resulting site. This allows you to contact site owners on a periodic basis to find out whether the site is still needed.

4: Locating documents

After deploying SharePoint, some organizations eventually begin replacing file servers with SharePoint document libraries. The idea behind this move is that SharePoint contains powerful indexing features that can make documents easier to locate than they would be if they were located on a file server. Although SharePoint has a decent search engine, document libraries can and do become overloaded. It can therefore be tough for users to find the information they need within a large document library.

One way to make it easier for users to locate SharePoint documents is to enforce the use of metadata. SharePoint contains options that allow you to define individual content types and to create custom metadata fields for each one. You can require users to enter relevant metadata for each document they create. This metadata goes a long way toward helping SharePoint return relevant search results.

5: Information overload

Providing good metadata for the documents stored in a document library improves the relevancy of search results, but it will get you only so far. Another thing you can do to improve search results is to implement a policy for document lifecycle management.

While some business documents may need to be retained indefinitely, other types probably have limited usefulness. For example, the odds are good that nobody in your organization cares about a marketing proposal from 10 years ago. By working with the managers in your company, you can find out which documents are really important and come up with a plan for automatically purging other documents after a specific length of time. Doing so reduces resource consumption and helps to de-clutter search results.

6: Governance

The subject of governance seems to come up more often in regard to SharePoint than just about any other application. There is a reason for this. Without proper governance policies, a SharePoint deployment can quickly spiral out of control and evolve into something that doesn’t even remotely resemble the organization’s original SharePoint vision.

The only way to prevent your SharePoint deployment from getting out of hand is to make some tough decisions up front about how the deployment should be used and who has permission to do what. In other words, you need to decide things such as who has the authority to create a site, what types of data are allowed to be stored within SharePoint libraries, and what types of customizations you want to allow.

7: Disk space management

Disk space management is something of an art form. Most network administrators are used to dealing with file servers that store data on dedicated volumes. SharePoint, on the other hand, stores its data within a SQL database. While you can use quota management to ensure that users don’t consume an excessive amount of disk space, it is important to realize that multiple lists or libraries can be linked to a common database. Therefore, you must design your quota structure to take into account possible growth of other lists or libraries that may exist.

8: Web part management

SharePoint sites are built around the use of Web parts. This approach make site creation easier, but it also means that any changes to Web parts result in changes to every site that uses them. You’ll want to take measures to prevent Web part customizations from being made in a haphazard manner. A modification that enhances a Web part’s functionality on one site may wreck havoc on other sites that are using that Web part.

9: Service level agreements

Many organizations discover that it doesn’t take long for a SharePoint deployment to grow from being something of a novelty to becoming a mission-critical application. As with other mission-critical applications, administrators are often pressured into accepting service level agreements for SharePoint deployments.

My recommendation has always been to use the quest for service level agreements as a bargaining chip. For example, you could explain to the managers in your company that for you to be able to deliver the level of service they are requiring, you need additional server hardware or other IT resources.

10: Disaster recovery planning

I have seen a few real-world situations in which administrators verified that their backup software supported SharePoint but never really looked at what was required to perform a restoration. Unless you’re going to be performing a total restoration, most backup applications require SharePoint data to be restored to a recovery farm.

A recovery farm is a separate, dedicated SharePoint farm. Although a recovery farm does not require the same hardware resources as your production SharePoint servers, it does have to be configured with the same features, templates, patches, and software versions as your production farm. That being the case, a recovery farm isn’t really something you can just throw together at the last minute when you have to perform a restoration. You will need to have it in place in advance.

Source: TechRepublic.com 10 SharePoint deployment challenges