SharePoint 2010 is like the Swiss army knife for information management. It is a versatile platform with capabilities covering many areas of information management, from publishing and document management to business intelligence and collaboration. However, just as you can cut yourself on a knife, there are ways you can either cut yourself on SharePoint 2010. In other words, there are ways to fail even with a capable and modern platform as SharePoint in your hands, and whether you will fail is determined by how you approach it.

Let’s start with defining what I mean with failure in this context. Failure happens when a new technical platform does not provide the required business capabilities. It might happen because it does not have what it takes, or that it does not provide the required capabilities to users in ways that will allow for adoption and integration in the users’ practices. Both these paths to failure starts from how approach a platform such as SharePoint 2010.

Two Common Ways to Approach SharePoint 2010

A common scenario is that an organization -- typically the IT department -- identifies a number of reasons for moving from one or more existing technical platforms to a new one, such as the need to replace an existing platform, which is hard and costly to maintain or suffers in performance and capability. Or it identifies the need to reduce costs by consolidating platforms that provide similar capabilities. Based on those needs, and likely also an inventory of what capabilities the existing platform provides, they then assess and evaluate platforms and then go to the business stakeholders to make a recommendation. In some cases, they make the decision by themselves and inform the business stakeholders about their choice of platform.

Another common scenario is that business users are struggling with basic things such as sharing and organizing information so it can be found and retrieved by those who need it, but also with determining the accuracy, completeness and freshness of the information they find. They might also be in need of better tools for document-based collaboration and want better insights into the business operations.

So they describe their pains and needs in terms of a list of features that they would either want to add to or improve. It is typically a mix of what they already have and things they have seen in the feature specs for various products. The list is then handed over to the IT department where they take a look at the list.

It just so happens that they have a license for a platform lying around that they have been playing around with on a server, and they know that it pretty much covers all the features on the list from the business stakeholders. Because they got the license bundled with another license, it is basically no-cost. Not using it seems stupid (at this point they don't mention that they don't have the enterprise version), and they recommend the platform to the business users as a preferred platform. Because most of the features seem to come out of the box, customization costs can be avoided.

According to my own experiences, both these scenarios are common. Here is what I believe is wrong with the approaches used:

  • It is wrong to jump from insufficiently assessed and vaguely described business needs into technical features and specific technical platforms.
  • It is wrong to look at capabilities only as a matter of technology and not also include people, processes and information.
  • It is wrong to choose a platform just because it is free or already paid for, without first making an assessment of how it and other alternatives fulfill the business requirements.
  • It is wrong to assume that the license cost would be the most significant cost when implementing a new platform such as SharePoint -- if it is to deliver the required business capabilities.
  • It is wrong to make the consolidation of technical platforms and the minimization of customization costs the higher priority over delivering the required business capabilities.

In any case, if you are moving from an existing platform to a new platform, you are looking at different and even new capabilities that you currently don’t have. This is true even when moving from SharePoint 2007 to SharePoint 2010. It is inevitable that you will need to change or adapt any solutions built on the existing platform, whether it is desired or not.

The right approach is, of course, to assess and define the required business capabilities before you choose the new platform, and not as an afterthought. It is not wrong to keep technical capabilities (and their limitations) of available technical platforms in mind when defining requirements, but it is the required business capabilities that ultimately should determine what platform you choose and to what extent you need to customize it. Any other approach is destined to fail.

Avoid 'One Platform' Fundamentalism

One Platform to rule them all, One Platform to find them,
One Platform to bring them all and in the darkness bind them."

Then there’s another road that leads to failure. There is no such thing as a one-size-fits-all platform in the sense that it provides all the required capabilities and fulfills all requirements for those capabilities to all stakeholders. Choosing a common platform is always a compromise. It is about finding some common ground upon which to build the capabilities that stakeholders need for getting the job done with excellence.

A vision of single-platform strategy should not be interpreted literally and fundamentally, as if any complementary products or customizations should never be allowed. Instead, it should be interpreted as a guiding principle that aims to direct such things as redundant capabilities, unnecessary (and costly) complexity and diverging practices for common tasks. The overarching principle should always be to deliver the technical capabilities, which ensures that the required business capabilities are in place and contribute to operational excellence.

A platform such as SharePoint 2010 might fulfill most of the requirements for a certain capability, such as collaboration, publishing or document management. The functionality of SharePoint 2010 covers a range of capabilities within information management, and being the Swiss army knife for information management, it provides organizations with tools and services for many of the situations they will encounter. It is no doubt one of the best things to always have around. Yet, sometimes you will find the blade of the knife to be too short, the screwdriver to be of the wrong type, or that you cannot fit your fingers into the small scissors. You will need an additional tool, or at least customize and extend the ones you have, to get the job done. It’s as simple as that.

Versatile products like SharePoint should be seen and used as capable platforms for designing and developing services that are tailored for the needs of information and knowledge workers. If that means investing in custom development or combining SharePoint with additional products, so be it. For most situations, SharePoint is not an out-of-the-box solution to be thrown into the laps of employees. If you think it is, you won't get as much return from your platform investment as its potential. A good SharePoint 2010 implementation requires outside-the-box thinking, while at the same time you need to understand and make proper use of the goodies that exist inside the box.

Adopt a Capability-Oriented Approach

To avoid approaching SharePoint 2010 (or any technical platform or solution) in the wrong way, an organization can adopt a capability-oriented approach to business and IT planning. Such an approach helps to avoid our tendency to focus on features and products and instead allows us to focus on business objectives and business needs.

So what is a capability? Well, a capability is a business-oriented concept that is used to describe a business’ capability to perform a certain activity or process. A certain capability can be enabled or supported by any combination of information, technologies, processes and resources. Some examples of common capabilities within the information management domain are document management, project management, team collaboration and findability.

To define a capability, you have to start with looking at business objectives and business needs. Then you develop business scenarios together with business stakeholders to describe the capability in question. Such scenarios are easier for business stakeholders to understand than the technical deliverables, which IT architect usually produce when trying to translate business needs into technical solutions.

They also describe the business context where different kinds of information, technologies and resources are to be used without losing the sight of the business objectives. Most IT projects that fail do so because they have done the opposite: They have failed to consider the business context, and they have lost sight of the business objectives early on in the project.

If you use a capability-oriented approach that starts with assessing business objectives and needs without jumping to features and products, you will soon realize that there is no one-size-fits all. You will also realize that quite a lot of the requirements for different business capabilities have similarities and are even the same in some cases, which means that you can get value from building them on a versatile technical platform such as SharePoint 2010. Just don’t fool yourself that you will find one platform from which you will get everything out-of-the-box.

Editor's Note: You may also be interested in reading: