Just finished reading a brilliant series of posts by Australian SharePoint consultant, Paul Culmsee, that lays bare what many of us intuitively know about why so many MOSS projects meet with failure.
Paul dilutes the principal causes of SharePoint project failure into several key areas:
- 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;
- 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.
- 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…
- 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.
Start with part 1 , this series is a must read for everybody doing sharepoint projects.