Alonso Robles

Joel Oleson wrote an interesting post sharing his insights on SharePoint project failures inspired by a five part post written by Paul Culmsee in cleverworkarounds.com. Joel’s insights point out that SharePoint projects are destined for failure when:

1. Developers are assumed to be the administrators,
2. SharePoint was selected as a solution before the problem was defined,
3. The deployment is not planned,
4. Budget is not allocated, and/or
5. Those who will be managing it have not played with it.

After reading Joel’s post, I took the time to read the Why SharePoint Projects Fail (Part 1, 2, 3, 4, and 5) posts by Paul Culmsee. The posts are a great read for project managers, technical leads, and sales folks who are working on (or will be working on) a SharePoint project. Paul focuses his discussion on the inherent problems found in project planning, failure to identify the problem to be remedied, mixed with the expectations of SharePoint being a solution to all problems, and underestimating the complexity of SharePoint as a product.

In my opinion, all of the points raised by Joel and Paul are valid and I have a few insights to add to the list.

Academically speaking, the success of a software project is a result of good risk management, mitigation, and contingency planning. Having a clearly defined and well accepted problem statement is a key element that allows us to identify the risks involved in order to manage them. Paul’s history lesson on the wicked problem is an important lesson to keep in mind when starting any software project.

All academics aside, the SharePoint product is a powerful, robust, complex, and versatile platform that can be used as architect a soution to solve many different business problems. However, those same power, robustness, complex, and versatile features make SharePoint a double edge sword. Just as it can be used to solve many problems, it can create many problems. In terms of project management, those problems are potential risks that may result in project failure.

My advice to help avoid SharePoint Project failure is simple and follows below.

Never identify the solution before the problem. Understanding the problem is essential to project success. Clear identification of the business problem will help stakeholders decide whether or not SharePoint is the right tool (or one of the tools needed) to do the job.

If SharePoint is being considered for the solution, then get an experts opinion. Chances are that most stakeholders and project managers have only heard about the SharePoint buzz. Let alone used SharePoint at all. It’s very possible that the technical expert on the project team has only limited knowledge about SharePoint. As such, it is essential that an expert is consulted to help the stakeholders decide whether SharePoint is the right tool for the job. As I pointed out earlier, SharePoint is a great platform for creating many solutions to business problems, but it is not the holy grail. Consulting an expert will also allow the project team to have better resource and budget estimates needed to complete the project at hand and help identify potential risks that will need to be mitigated.

If SharePoint is selected as the platform, ensure the project team has adequate training and don’t be afraid to ask an expert for help. Once SharePoint has been selected, make the investment and get the team properly trained. Be sure to consider having a SharePoint expert available to help with the project. The upfront training investment and having a SharePoint expert on the team will help with risk identification and mitigation throughout the project. In addition, familiarity with SharePoint features will result in cost savings by keeping the costs of custom development down.