| Executive Summary: Potholes in the road to implementing Microsoft Office SharePoint Server (MOSS) and Windows SharePoint Services (WSS) can cause an implementation to go in the wrong direction, slow down, or even come to a stop. Here's what you need to know to avoid them. |
Microsoft Office SharePoint Server (MOSS) and Windows SharePoint Services (WSS) can help companies improve their organizational effectiveness and their bottom line. However, there are potholes in the road to implementing SharePoint that can cause an implementation to go in the wrong direction, slow down, or even come to a screeching stop. Here are six potholes I've encountered often in my efforts to help companies get their SharePoint implementations running smoothly and how to get around them.
Not Having a Governance Plan
SharePoint implementations can falter or fail because of poor governance. Setting policies, defining roles and responsibilities, and establishing processes to guide how your company is going to use SharePoint to accomplish its business goals is crucial. Without doing so, you're taking a huge risk. Without a governance plan, the people in your organization (e.g., end users, managers, developers, support staff, administration staff) likely won't have realistic expectations. Realistic expectations can only be set by defining the policies, people, and processes that will deliver SharePoint services.
So, if you don't have a governance plan in place, dedicate your time and resources into formulating one, even if you've already implemented some SharePoint projects. (Make formulating a governance plan your next SharePoint project.) If you already have a governance plan, don't be afraid to revisit it. A few years ago, many companies that had implemented Active Directory (AD) went through an "Oops, we didn't do it right the first time" phase. When these companies began reviewing their AD implementation, they realized that it wasn't meeting their business needs quite right or they weren't taking advantage of all the product had to offer.
A lot of companies that have implemented SharePoint are now beginning to enter the "Oops, we didn't do it right the first time" phase. (Interestingly, this phase is occurring much sooner in SharePoint's product cycle than it did in AD's product cycle.) Many companies are now looking at their SharePoint implementations and making such realizations as:
- SharePoint usage is greater or quite different than anticipated.
- Security and content management aren't quite aligned with the policies and realities of their organizations.
- They aren't taking advantage of certain SharePoint's features when they should be.
- There's some cleaning up to do, as SharePoint "in the wild" has become a bit, well, wild. Rogue, unmanaged installations need to be corralled and brought into line with standards, and data build-up has occurred because content lifecycle management wasn't in place.
If you aren't in this predicament, either your SharePoint implementation was very well planned and deployed or you're very lucky (or both). If you are in this predicament, don't feel bad. It's common for businesses to move forward differently than expected and have to adjust course later on.
Using MOSS When WSS Would Suffice
I've seen it over and over: Companies bite Microsoft's bait and commit to using MOSS too soon and too often. Many organizations are currently focusing their SharePoint implementations on collaboration to help information workers get their jobs done more effectively. In other words, they're focusing their efforts on streamlining file sharing, automating workflows, and implementing Web 2.0 (e.g., social networking) functionality. For many organizations, the additional value that MOSS brings to this particular scenario doesn't justify the cost differential between WSS (which is basically free) and MOSS.
Even in large enterprises and geographically distributed environments, WSS can serve the collaboration needs of branch and remote offices, with MOSS providing search, portal, and other enterprise-level services at headquarters. You're better off meeting as many business requirements as possible with WSS before committing to MOSS. I'm not saying that MOSS doesn't have a role to play—it most certainly does—but its roles are more likely to be in search, portal, and other services that complement collaboration.
Underestimating the Importance of End User Productivity
SharePoint has a real potential for increasing end user productivity. Depending on your business, your end users' daily work might be helped by improvements in one or more of SharePoint's functional areas (i.e., collaboration, search, portal, business process automation, content management, and business intelligence—BI). For many organizations, improvements in collaboration and search capabilities fit that bill. So, anything you can do to help your end users—such as making collaboration easier and improving searches—will help make them more efficient. When end users can get their jobs done more efficiently, costs usually decrease and revenues typically increase.
Unfortunately, most organizations don't take the time to accurately estimate the cost of employees' time when determining how much money a SharePoint project can save a company. To do so, you first need to calculate what is called a burden cost for each employee. The burden cost encompasses more than just gross salary—it represents the annual total cost that a company incurs in order for an employee to perform his or her job. It includes benefits, training, taxes, and more. The burden cost is usually more than double the employee's salary. After you calculate the burden cost, you need to divide that figure by the number of hours the employee works in a year to get the burden rate for that employee.
Admittedly, calculating the burden rate for every employee whose productivity would be improved by a SharePoint project would be time-consuming, especially if the SharePoint project had a large scope. Fortunately, you can determine the burden cost for each type of employee (e.g., customer service representative, project manager, engineer) and divide that figure by a reasonable number of work hours per year. In the United States, 2,000 hours (40 hours a week x 50 weeks) is often used. For example, suppose that a company's engineers typically have a burden cost of $150,000. The burden rate would be $75 an hour ($150,000/2,000 hours) for employees with that type of job.
When you use burden rates, you can get a true picture of a SharePoint project's ROI. For example, one company I worked with found that a specific SharePoint project would save users 10 minutes per day. Although that doesn't sound like much time, the calculations showed that the project would save the organization millions of dollars per year because it would improve the productivity of several thousand users. In fact, the ROI seemed so outrageous that the project's financial impact had to be undersold to make it believable.
In the past, it's been tough to position these "soft" savings against the "hard" costs of software licenses and implementation. However, in this economic climate, I think organizations will finally start to look at both hard and soft costs as they try to figure out how to do more with less.
Not Dealing With Political Resistance
SharePoint is the new kid on the block, compared to such competing products as IBM Lotus Notes and Xerox DocuShare. Because SharePoint came along later, you might run across people who have a lot invested politically in legacy tools. A SharePoint project might never get started or be derailed because of political resistance.
So, how do you deal with such political barriers? It all boils down to investing time in the requirements-gathering stage of a project. If you really understand the requirements, you can create metrics with which to measure your success. Presenting those requirements and metrics to your company's leaders will likely lead into a discussion about the project's ROI. If you can get your company's leaders to support your project, you should be able to get around the political barriers.
Not Thinking About Company Culture
A SharePoint project can fail because the company wasn't ready for it. Take using SharePoint for social networking, for example. For SharePoint to be successfully used to capture, retain, and leverage the knowledge that's in your employees' heads (and vanishes when they leave the company), you have to incorporate social networking into performance evaluations, compensation, and all other systems. Social networking must be part of a broader initiative at reaching specific business objectives. It must become part of the culture, not just a tool that's thrown out there. Don't try to implement a SharePoint project if the company isn't ready for it.
Not Considering All Your Options
SharePoint, particularly MOSS, has a lot of features that many companies don't take advantage of. For example, not many organizations leverage user profiles, even though they're a powerful way to improve people-search functionality.
In a nutshell, here's how user profiles work. For each user, SharePoint pulls information from AD or another LDAP database, such as Active Directory Application Mode (ADAM) or Active Directory Lightweight Domain Services (AD LDS). You can extend the default information it pulls from AD, so you can pull standard or custom attributes into SharePoint user profiles. You can also pull information from a database and use a process (e.g., Identity Lifecycle Manager or a script) to synchronize that information with the AD data, then import the combined information into the user profiles. In addition, you can use the Business Data Catalog (BDC) to pull information directly from other types of databases, such as an HR database. Although the BDC can't provide the primary source of user information, it can supplement the user information imported from an AD or LDAP database. (If you'd like more information about user profiles, see the resources listed in the sidebar "Where to Get the Scoop on SharePoint's User Profiles.")
Because user profiles can pull information from many different types of databases, they work well when you need to create a directory that end users can use to search for and connect with people in an organization. For example, a major financial services firm had a employee directory on the intranet. The intranet directory pulled information from a variety of sources, including AD. The company wanted to integrate or replace the intranet directory with SharePoint's user-profile and people-search functionality. In this case, the company had several options, including:
- Placing a link to the existing intranet directory on appropriate SharePoint pages or My Sites
- Presenting the existing intranet directory within SharePoint, such as with a page viewer web part on appropriate SharePoint pages
- Developing custom web parts to create the desired interaction with back-end data sources and/or the existing intranet directory
- Replacing the intranet directory with SharePoint user profiles, people search, and My Sites, using the BDC to pull information from sources other than AD
Each approach has its advantages and disadvantages. The first two options require the least effort, but achieve the least integration. The last two options require various amounts of configuration and custom code, depending on the functionality and two-way interaction with the back-end data. However, custom web parts are very versatile (you can do just about anything with them) and user profiles give you the ability to pull information from AD. And by using the BDC, data from other sources can pulled in, indexed, and leveraged by various SharePoint features.
Another possible but unconventional approach would be to use SharePoint's user profiles and My Site functionality without actually deploying personal My Sites. Ian Morrish discusses this strategy in his blog post "SharePoint User Profiles, My Links and My SharePoint Sites without a personal My Site". Why would you want to do this? Because My Sites can open a can of worms from a governance perspective and might not fit your corporate culture. Why not leverage all the people-search benefits of user profiles without that can of worms?
As this example demonstrates, there are usually many options to consider. When you have to make a decision like this one, it's wise to take a step back and evaluate the full spectrum of solutions—including skipping SharePoint—before blazing forward.
Avoid the Potholes
Now that you know about some of the common potholes in the road to implementing SharePoint, you can be on the lookout for them. And if you encounter one, you can take the necessary steps to make sure that your SharePoint implementation stays on track.