Here is a video that dramatizes Sharepoint project failures and what is needed for a successful implementation of Sharepoint.
But wait a minute. The remedies sound too familiar:
a) Clear business objectives
b) Identify critical success factors
c) Prioritize - don't do everything at once
d) Initially, Pick high visibility projects - low hanging fruits - ensure buy in
e) Plan roll out strategies
As CIO, you would wonder how the context changes but the advise from IT consulting fraternity remains the same.
So, are the stick-to-the-basics advisors being too simplistic? Or are these principles so deceptive in their simplicity that we miss them often? My guess is both these scenarios are true.
I believe there are a few additional drivers of success for such projects:
a) Avoid believing all the marketing hype surrounding Sharepoint. While it is indeed a powerful platform and can do a lot of things, it is equally important for you to know what it CANNOT do for you.
b) Sharepoint is not an "application" with a set of "features". Focus on the specific business issues that you wish to resolve and how Sharepoint can help you solve these issues.
c) Avoid "sharepoint developer = asp.net developer" syndrome. (This is also covered in the embedded video). We have been surprised to find implementations by even some very prominent clients suffering from this syndrome. A sharepoint developer needs to have deep understanding of asp.net framework and coding. However, this is only a "necessary" condition; not a "sufficient" condition for a good sharepoint developer. The costs and risks associated with this approach are too high. Ensure your implementation partner has an in-depth expertise and resorts to customization only where it is needed.
d) Ensure a realistic understanding of time and effort involved. It is relatively easy and quick to implement the capabilities relating to communication, content management, collaboration and search. However, enabling workflows, business process integration, dashboards and business intellegence capabilities requires much greater effort (involving typical SDLC stages). It is necessary to decide on your project's phasing and budget accordingly.
e) In most cases, Sharepoint is but a small part of a larger enterprise-wide initiative. It cannot be driven by the IT department alone. Sharepoint based intranets, self service portals, dashboards would touch almost all your employees. Also, the volume of content to be managed (and the pace at which it grows) is often overwhelming. It is, therefore, important to decentralize responsibilities to other concerned departments. Concurrent initiatives in terms of communication and change management are equally important to ensure the success of the project.
f) If you are looking to "integrate" sharepoint with any of your existing technologies, e.g. a document management system; take care to ensure the concerned technology vendor gives you "demonstrated evidence" of feasibility of its integration with Sharepoint. As such, MOSS 2007 has a decent document & content management capability. The need for an advanced system should arise only in exceptional cases where advanced capabilities are needed. In all such cases, it is important to go beyond the "promise of seemlessness" offered by the marketing team of the vendor.
As always, I look forward your views on the above obsevations; and if you would like to share similar thoughts and experiences.
