I recently carried out a review of the various “top 10 reasons for project failure” lists that pop up on the internet on a regular basis. These lists tend to be popular and as such are frequently referenced in training sessions and blogs.
Not surprisingly these lists have common themes. Collating the most frequent into one “top of the pops” list reveals the big three;
- Changing requirements
- Lack of stakeholder participation
- Lack of vision / goal
Although such lists are fun and many people will be able to relate to them, they do raise a concern in my mind. While the intent is to help organizations identify the reasons projects fail, the lists are usually expressed at such a high level of abstraction that they fail to provide any really useful insight.
Expressing problems at a high level of abstraction allows more people to relate to them, but does little to help us understand how failure occurs. To demonstrate the point, if we take the first item on the list there are many deeper issues that could be lurking under the surface.
Were requirements changing because the team;
- Failed to engage stakeholders effectively when requirements were first established?
- Used a development process that was poorly aligned with the needs of the project?
- Lacked the domain knowledge or skills to ask the right questions?
There are of course many other possibilities that would take more than a short blog post to explore.
What’s not being said is sometimes more important than what is being said. The key to understanding the causes of project failure lie at a more detailed level than that captured in these popular lists. Organizations interested in overcoming the difficulties associated with delivering technology projects need to develop the insight to be able to go beyond a simple top 10 list.