Schedule slippage, quality flaws and budget overruns are the familiar symptoms of a project in trouble. In business projects such problems are sadly all too common and improving success rates is one of management’s greatest challenges. It’s estimated that project failures cost the global economy hundreds of billions of dollars annually. To illustrate the point, our Catalogue of Catastrophe provides an ongoing record of some of the most notable and interesting project failures from around the world.

Such loses are a drag on the economy, a threat to the viability of the organizations executing the projects and stressful for the individuals involved. To help organizations improve project success rates, and to act as a learning resource for Project Managers around the world, this site is dedicated to answering the questions “why do projects fail?” and “how can we improve success rates?”

Although simple questions to ask, the answers have many parts and many layers. Those layers mean that the causes of failure can be viewed at a number of different levels. For example if a project underestimates how much work is involved (and hence fails because it runs out of money) you could regard the bad estimate as the cause of failure. While there is some truth in that, such a perspective is a very shallow one and under the surface there are likely a number of other contributing factors. For example tracing back through the root causes you might find that the failure to establish the project’s full scope before committing to and publishing the estimate was an underlying factor and beyond that may be other layers of contributing factors. To establish the true causes of the failure we often need to peel back the layers of the onion and think hard about contributing factors that led up to the situation within which the failure was able to occur.

Figure 1 provides a starting point for such a discussion. As the diagram shows, the common indicators that a project is in trouble are schedule and budget overruns, quality problems or the fact that the product produced by the project have failed to meet the organization’s real business needs. These outcomes are however just symptoms and the real causes of failure lie at a deeper level. These deeper factors can be divided into two general categories; Trigger events (individual actions, mistakes or problems that lead to or contributed to the failure) and Behavioural patterns (broader structural problems in the way the project is approached or managed). Sometimes a failure can be triggered by one small error or mistake made somewhere along the line (as happened in the case of the de Havilland Comet), while other times the failure is reflective of a dysfunctional environment within which multiple problems are allowed to grow over extended periods of time (such as in the Census Bureau’s failed Field Data Collection Automation project)

At an even more elemental level these contributing factors are themselves a reflection of deeper seated issues relating to the way decisions are made in the project or the organization as a whole. Although we traditional think of projects in terms of the activities needing to be performed, at a more basic level projects are made up of networks of interrelated decisions (Figure 2). Decisions are the stepping-stones of progress in a project and the outcomes a project attains is usually directly correlated to the effectiveness of the decisions made. If a team consistently makes good decisions, the chances of project success are high. If they make too many bad decisions, the chances of success are greatly reduced. Sadly dysfunctional or ineffective decision making is all too common and issues such as: lack of situational awareness, cognitive biases, political forces, organizational cultural factors and many other dynamics, often negatively influence the way project decisions are made.

Furthermore it is not only the decisions made by the project team themselves that can affect outcomes, it is also decisions made either directly or indirectly by the extended team (stakeholders and sponsor) or those who control the environment in which the project is operating. For example if Senior Management of the organization decides not to invest in proper training for their staff, the chances of problems in the project may be increased. As such when considering failures we need to look beyond what the team did and consider the broader context within which the project exists.

Common sources of project failure

Often the best way to understand the causes of project failure is to study prior projects that have failed. Although people sometimes fear discussing such issues (because of the politics involved or the fear of being held accountable for mistakes that were made), the study of failed projects provides the rich context within which underlying root causes can be witnessed and understood. To overcome the fears people may have the Catalogue of Catastrophe provides a database of samples that can be used as a platform for discussing the causes of project failure. The use of publically available information helps eliminate the personal aspects of the discussion and opens the door for more open exchanges between participants.

Based on the Catalogue of Catastrophe and discussion our editor has had with more than 300 people who have been involved in both successful and failed projects a picture of the common causes of project failure emerges. Figure 3 helps categorize those causes and helps bring some structure to the conversation.

As shown in Figure 3, the most common causes of failure can be divided into 8 primary categories. The following list outlines the meaning of each group and provides links to samples that illustrate each one.

Market and strategy failures – When a project builds a product or solves a problem you better make sure you are building the right product or solving the right problem. Where a project sets out to build something that no one needs or wants the entire project can be an expensive failure. Example: The Sinclair C5

Organizational and planning failures – Projects often involve a lot of detail and require the efforts of a lot of people to be coordinated. In such a situation work needs to be properly organized if effective progress is to be made. Where the level of organization is insufficient the project team can quickly loose control. Conversely, where the controls put in place are more than are needed (or inappropriate for the type of project being run) the project can be weighed down by unnecessary inefficiencies. Example: FBI Virtual case file

Leadership and governance failures – Projects needed to be “owned” by someone and they need people who have the leadership skills to make things happen. Where there is ineffective leadership, or where the governance processes management use to track and control the project are insufficient, management can loose control. Example: US Census Bureau Field Data Collection Automation project

Underestimation and analysis failures – Projects can be complex undertakings. However that complexity is often not immediately apparent when a project first begins. Instead, the team needs to carefully analyze the project and discover the complexities involved. Those complexities need to be understood before commitments to schedule and budget are confirmed. If commitments are given before the full complexity has been appreciated a project can easily end up making unrealistic commitments that ultimately create a pressurized environment in which the project can only fail. Example: Denver baggage system

Quality failures – At the end of the day the deliverables produced by the project need to work. Sadly quality is often the dimension that gets too little attention. Where quality corners are cut or insufficient testing is completed, serious flaws can escape the project and cause havoc once the deliverables have been deployed. Example: Her Majesty’s Revenue and Customs UK

Risk failures – Predicting the future is a risky activity and because projects are all about creating the future, projects inherently involve risk. Where a project is blind to those risks they are likely to run into serious difficulties that they failed to anticipate. Those difficulties are sometimes serious enough to derail not just the project, but even the organization as a whole. Example: Fox-Meyer Drug

Skills, knowledge and competency failures – If there is one ingredient that most effectively increases the chance of project success, it is expertise. Where a project lacks the knowledge and skills needed to do the work properly, quality levels and productivity are lower and the risk of serious errors or omissions rises fast. Examples: The Vasa

Engagement, teamwork and communications failures – Projects are done by people and most projects are done for people. Where a project fails to understand who their stakeholders are, or fails to engage and communicate with them effectively, the project is working in a vacuum. Similarly if the team themselves are not collaborating effectively individuals can end up working in silos that prevent communications flowing effectively. Example: Qantas Jetsmart

Within these various categories there are many possible mistakes that can be made. Our page on 101 common causes provides a broader picture of the types of mistakes organizations make and our classic mistakes page lists the top ten award winners.

Interested in learning more? Try the following;

1. What is project success? – A look at how we define success and failure
2. Facts and figures – A compilation of recent studies into project failure
3. Featured articles – Articles and case studies relating to the management of projects and the causes of project failure
4. FAQ – Commonly asked questions

R. Goatham – Editor. If you would like to discuss further please feel free to Contact us.