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.

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