A recent assignment demonstrated yet again, how critically important it is to take the time to decide if SharePoint is the right tool for your project.
On average, I have been seeing a $1M plus SharePoint train-wreck every 2 years. Each of the 3 projects I’ve witnessed had at least one thing in common; SharePoint was NOT the right tool for the job. All of the projects went way over-budget and under-delivered on requirements. It is this latter point that anyone can do something about.
No one wants to analyze requirements any longer than necessary. The problem lies in matching the technology choices to the requirements.
First and foremost, SharePoint was created as a team collaboration platform to add value to the Office franchise in the form of useful capabilities in back office services. Network file shares were fine to store my documents or even share documents between users, but this was a very simple beginning in terms of people effectively working together. Simple content library functions like version control and check-in/check-out were needed to make collaboration even practical on the network. The ability to set security boundaries to create a mine, yours, and ours environment was also needed to logically define sharing spaces as well as for providing basic document access control. These were the basics of collaboration that SharePoint Team System tried to address as a technology preview (some called it a product, but it fell a bit short).
From the 2003 to the current 2010 product versions, the fundamentals of what SharePoint is have largely remained unchanged. It is for this reason that I always ask a client if collaboration is a fundamental requirement in the project they are considering SharePoint for. In Intranet portals, this need is almost always present, so this is an easy one.
However, in the realm of public facing Intranet sites, the basic foundation of SharePoint is almost never a requirement. Further, other capabilities like multiple site hosting may not even be in the picture.
Secondly, the decision to adopt SharePoint must consider page content authoring. Web sites are all about content and are rarely concerned with document sharing and only document sharing; even in Intranet portal scenarios. For most cases where there is a good match between what is required and what SharePoint has to offer, the out-of-the-box capabilities of SharePoint’s publishing page editor is sufficient. Content deployment may or may not be key; i.e. it might be a nice feature, but not a necessary one in Intranet deployments.
However, in public facing web sites, content is everything and the authoring and deployment features of a Content Management System are critically important. It is this area that SharePoint 2010 still falls way short of what is required in the real world of the 21st century. In 100% of all cases where I have collaborated on a SharePoint project with a creative design firm, the designers and coders have been aghast at what working with SharePoint is really like for a web page designer.
None of this is too surprising or extreme. The patterns of behavior that I have seen have resulted in millions in wasted development/consulting expense.
This segues into the last consideration. Can I find and afford the skills required to do a SharePoint project right? I’ll cover this in Part II.