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

 

 

 

Advertisements

4 Responses to Top 10 Pitfalls for a SharePoint implementation Part 2

  1. Pingback: Top 10 Pitfalls for a SharePoint implementation « Shankar’s Musings

  2. Pingback: www.tagsto.com/trackback/

  3. Ethnocentric says:

    Somehow i missed the point. Probably lost in translation 🙂 Anyway … nice blog to visit.

    cheers, Ethnocentric!!

  4. Tiago Cardoso says:

    Hi Shankar,

    Nice points of discussion here, I would like to comment though:
    1) I agree that MOSS10 is not a replacement for the network drive. In fact if we look at 99,9% of such cases, there is barely any governance, and if MOSS is used in the sameway, information silos will also be created, that is why, a Document Library should be customized. In fact, several document lybraries should be used for diferent purposes / types of documents. If in those libraries, you add categorization data, and approval workflow, I believe it is possible to use MOSS as a document lybrary effectively.

    2. Crucial point, well said, site collection planning.

    3. So true, in fact I think this is one of the biggest challenges of MOSS, let it be 2010 or 2007 (although 2010 is far more resource expensive!). I believe for handling large data, (even in orders of hundreds of thousands of entries) SharePoint still is not providing out of the box resource effective features, and this will still lead to custom development and even paralel SQL databases.

    4. True for MOSS or any other intranet solution

    5. Nothing to add

    6. Right on

    7. Interesting and very tru, but how to do it? Do you know any case?

    8. Yes, in fact there are projects just to do this.

    9. True

    10. Totally agree, not all code should be web-parts, web-parts are just the begining, as mostly should be used for quite simple purposes, in fact applications from MS in top of SharePoint (such as Project Server) show us that it is not only a matter of deploying your set of “magic web-parts” and that is it. In my opinion, just using web-parts might lead to very fragmented implementations in SharePoint and unecessary redundancy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: