Why SharePoint Deployments Fail: The Business vs IT Dilemma

The AIIM organisation has just published the results from their annual Microsoft SharePoint survey. 

The sample size is respectable (N=620) and the respondents come from all company sizes across a wide range of industries. It was a self-selection process from the total set of people invited to take the survey, so it would be in the nature of these things if the majority of respondents were using SharePoint.

The report has a lot of interesting data, but the headline message has to be that a majority of SharePoint deployments (61%) are stalled, struggling, or failing. Only 6% rated their project as a great success.

That has to be correlated with another finding, namely that 49% of the sample reported that choosing SharePoint was an IT decision. In fact, 34% said that it was the head of IT who made the decision.

Of those using it, nearly two-thirds (63%) said that their SharePoint is not connected to any other system. It's hard to see how a tool managing information can be of any relevance if it's not connected to other systems used in the company workflows.

These data seem sadly familiar to a scenario we see quite often: senior management at a company become aware that there is an information management and data governance issue. Rather than treat it for the strategic decision that it is, they instead delegate it to the IT department to act. They go with what they believe will fit with their wider IT system administration tools; and with not a lot of thought about business requirements. Even if they roll-out the project in an efficient manner and don't under-estimate the difficulty, it is highly likely that six months down the road there will be a tool in place with very low user adoption. Systems that don't get used grow stale and can become a business liability if the data they hold is no longer trusted.

And then, yet another IT project is added to the 'failed' list.

Worse than that, a minimum of two years will elapse before the situation can be recovered and the company gets the system it needed in the first place. That's assuming there's an appetite to try again.

The alternative is that the project should be led from the business side. Of course it needs IT input and advice, but it should not be IT-driven.

It may seem the alternative argues for extensive analysis and consultancy with phrases such as "information architecture" and "information governance" in profusion; and a hefty project cost. There's nothing wrong in doing this, but it isn't necessary. It's enough to build a simple category structure for your documents with an elementary security policy, decide on user roles and levels of user rights, and just get started. Procedures to serve the business policies and workflows that you want will soon emerge. That's the "Plan, Do, Study, Act" method advocated by management thinkers such as Deming or the "Build-Measure-Learn" model from the Lean Startup methodology. It works.