Why do SharePoint Projects Fail?

Just finished reading a brilliant 5–part series of posts by Aussie SharePoint consultant, Paul Culmsee, that lays bare what many of us intuitively know about why so many MOSS projects meet with failure:  It’s not the technology, it’s the people.

Paul dilutes the principal causes of SharePoint project failure into several key areas:

1. Instead of being the solution to a problem, SharePoint actually exacerbates the problem domain because it is a complex product that has come to mean many things to many people;
2. As a result of 1), SharePoint projects engender what has come to be known as “wicked problems”, or those that have no real end-game or winning scenario.  They’re almost always characterized by some significant setback or loss or disappointment.
3. Often, project managers, executive sponsors, IT and developers enter into implementations by grossly underestimating scope and underlying physical infrastructure requirements, governance measures, information architecture, and the potential impact to existing systems.  The resulting conflagration often doesn’t blossom immediately, but when it does…
4. SharePoint has become a victim of its own success, with unfortunate abuses of acronyms and terminology around its features and usage scenarios.  Often, this is done at the hands of pre-sales folks.

In almost all of my SharePoint projects I have encountered the issues and wicked problems that Paul describes – some of them lamentably brought about by too much planning and analysis paralysis (BDUF/waterfall) and some by just rushing in a “yeah, yeah, yeah I get it, we don’t need to talk to users let’s just install the thing quick fast and roll it out NOW we’ll worry about content types and site columns and governance later” fashion.

I think Paul makes a lot of solid observations in the series, perhaps none more salient than the fact that because SharePoint is so expansive and so new, it is an immature product (much like Active Directory was in 2000).  Thus, it’s really premature to be speaking in terms of recommended or best practices with respect to the product since very few people on Earth have been running it long enough or extensively enough to generate the necessary corpus of empirical practices.

Do take the time to read Paul’s blog – it’s chock-full of pragmatic SharePoint goodness borne out of practical experience.  Start with Part 1 of his Why do SharePoint Projects Fail? series – I guarantee you’ll be laughing hysterically and nodding violently in agreement with almost everything he says.