The Right Way to Approach SharePoint 2010

By Oscar Berg (@oscarberg) Aug 15, 2011

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.