Dan from Integrated Services, Inc. asked me to share my opinions on how to maximize your SharePoint investment. I will try to focus on how to avoid some of the classic mistakes that could ruin your project.

It does not make sense to reinvent the wheel here, so I will try to reuse some the classic mistakes made on various IT projects. These mistakes are listed in “Rapid Development” by Steve McConnell. Steve is probably the greatest author when it comes to software project management. His books are “a must read” for anyone managing a software project.

Steve calls these mistakes – Classic mistakes, and I will try to review those that might be related to a SharePoint project.

Classic mistake No 1. Undermined motivation
As I wrote before SharePoint is a tool for end-users. They will resist anything new. Your goal is to motivate them from the day one. There are no recipes how to do that, it all depends on your project. But you must have a business problem you are trying to solve with SharePoint implementation and you will probably need to start from that. Try to see how solving your business problem might also help your end-users to solve theirs.

Classic mistake No 2. Weak personnel
I wrote on building a SharePoint team before. Educate your people properly before you start a SharePoint project.

Classic mistake No 4. Heroics
A hero in a SharePoint project is usually a developer who thinks he can build his own version of SharePoint. SharePoint frontend looks simple, but it took Microsoft 6-8 years to build it, so a hero cannot do that on his own. In a SharePoint team you do not need heroes, you need a team of developers that can read documentation, blogs and troubleshoot problems.

Although developers like to write code, take a look at 3rd party solutions like Nintex Workflow or Bamboo Solutions. These guys did a great job of building the cool software that can help you solve your business problem.

Classic mistake No 7. Friction between developers and customers
When building a SharePoint team you need a project manager (consultant) to handle customers and developers. Customers wishes on these project might be “fuzzy” so you need a person that can translate them to your development team.

Classic mistake No 19. Wasted time during the fuzzy front end
Fuzzy front ends? There should not be fuzzy front ends on SharePoint projects. There are books, seminars, blogs, articles etc. If your developers/system engineers would like to be best in bread they must educate themselves all the time. If they know everything about SharePoint, maybe they should learn more about Project Server, Groove, Performance Point, you name it.

Classic mistake No 21. Inadequate design / site planning
The worst thing you can do on a SharePoint project is to transform demo environment to the production. Once you educate your end-users on how to use SharePoint, establish a demo environment for them. The best approach is to use a virtual machine. Microsoft already prepared these for you, and you can download them here.

You should motivate end-users to play with demo environment as much as they can. Their experiences will be very useful and you will be able to learn from these experiences and incorporate them into your production portal.

Classic mistake No 25. Omitting necessary tasks from estimates
SharePoint is flexible but that does not mean you do not need to plan your project properly. You can download a sample SharePoint project plan here. Also review other articles about Planning and architecture for Office SharePoint Server 2007 on Technet. You will not be able to use these guides on every project but they are very good to start with.

Classic mistake No 28. Requirements gold-plating
Stay agile, expect change! If you did the motivation properly your end-users will have 1000 ideas on how to improve their SharePoint portal. These requests will probably be coming late in project lifecycle. Be prepared to fulfill them.

Classic mistake No 30. Developer gold-plating
Once your developers get use to SharePoint they will also have 1000 ideas how to use latest-cutting-edge-technology in your SharePoint implementation. Yes, I know Silverlight 7.0 sounds cools, but do you really need it? The primary goal of a typical SharePoint project is to increase day-to-day productivity. For that you need reliable tools that are easy to use.

Classic mistake No 33. Silver-bullet syndrome
Yes, SharePoint is cool and great. But it not a silver bullet. Analyze business problem very carefully and propose the proper solution. As previously mentioned you need a good consultant that can map these problems to SharePoint features that can solve them. Do not promise what you cannot deliver! If you are not 100% secure you can do that with SharePoint ask someone to help you before you promise anything to your customer.

Classic mistake No 36. Lack of automated source-code control
Developing custom code for SharePoint is usually done in Virtual Machine. Do not forget to backup your code to a physical machine and backup device. VMs are great, but sometimes get corrupted and you might loose everything.

Every project is unique but I hope you will find some valuable advices here.

4 Comments

  1. http:// Says

    I am not familiar with the term “gold-planting “and want to ask if that is not perhaps a typo and you mean gold-PLATING?

    If not- what is meant by gold-planting?

  2. http:// Says

    @Nancy: Yes it is a typo.

    But you must admit that it would be cool to plant some gold in the back yard :)))))))

  3. Peter Seale Says

    I love this. I love both McConnell’s classic list (PS he’s updated the list on his blog to include 4 more, I was just reviewing the updated list recently), and I love your SharePoint interpretation.

    One thing: I’ll say that project heroics, as I understand it, is the developer who works a lot of overtime and becomes a “hero,” saving a “doomed project” with sheer effort. While admirable, heroics have no place in a project that should have planned for contingencies.

    So in SharePoint, my advice would be to pad your estimates to account for implementation difficulties/dead ends.

    Also I’ll point out that I personally underestimate deployment, every time. And by deployment, I don’t mean the act of “going live”, I mean preparing your project so that it is able to go live in the first place. This goes under the “Classic mistake No 25. Omitting necessary tasks from estimates”

  4. Toni Says

    One must also plan the approvals for deployment. With enterprise customers you will need to verify and get approval for each deployment you are planning.

    If you have the ability, use virtual machines instead of regular ones…

Leave a Reply