Top 10 Pitfalls for a SharePoint implementation Part 2

This is a continuation of my previous post. Click here to view Part 1

 

6. Our Front office admin can manage SharePoint – A lack of good training/governance/maintenance policy destroys the user’s confidence in the portal solution. There is nothing more frustrating for an end user than waiting for a consultant to provide support within “48 hours”.

 7. We need to design every site before rolling out the portal – The traditional waterfall methodology invariably breaks down during portal implementations. Users need collaboration now and not 6/8 months down the road. An agile approach works great where you can obtain quick design wins and improve the portal adoption organically throughout the enterprise. It is a great feeling when people realize the benefits of SharePoint from their peers than a 45 minute sales pitch.

 8. Can we have our old documents please? – Migration of existing content is often overlooked until the end of the Build phase of the implementation. When user acceptance testing begins, users don’t have access to their existing data and it makes it tough for them to provide feedback and compare apples to apples. Data migration could end up becoming more complex compared to the portal setup, since the old metadata needs to be mapped to the new strategy.

 9. Over-Engineered Security – SharePoint provides tools ranging from self service site creation to completely locked down access to sites. Arriving at a security model that satisfies the business without constraining the users is crucial for success. Over engineering the security puts additional burden on the IT staff for support. Inadequate security leads to unmanaged site growth in the portal. Striking the optimum balance and documenting it early on is the key to prevent issues at a later stage.

 10. All our ASP.NET code will now be Web Parts- This is probably one of the frequent issues that I have run into. There are some applications that thrive well under the web part model. There are certain applications that do not need the constraints “offered” by SharePoint. Picking the right tool for the right Line of Business application ensures that undue burden is not placed on the internal IT staff to standardize their development on MOSS.

If you think I missed something or if you have additional points to add please feel free to link here

Here are a some additional posts that talk about similar pitfalls

http://www.sharepointjoel.com/archive/2008/05/06/insights-why-sharepoint-projects-fail.aspx

 Why do SharePoint Projects Fail? – Part 1

 Why do SharePoint Projects Fail? – Part 2

 Why do SharePoint Projects Fail – Part 3

 Why do SharePoint Projects Fail? Part 4

 Why do SharePoint Project Fail? Part 5