Facts and Figures

A number of studies have been completed that look into the success / failure rates of projects.  These studies indicate that serious problems exist across a broad cross-section of industries.  Below is a summary of some recent reports.

Source : McKinsey & Company in conjunction with the University of Oxford
Type of survey : Study on large scale IT Projects
Date : 2012

A study of 5,400 large scale IT projects (projects with initial budgets greater than $15M) finds that the well known problems with IT Project Management are persisting. Among the key findings quoted from the report:

1. 17 percent of large IT projects go so badly that they can threaten the very existence of the company
2. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted

Source material - Delivering large-scale IT projects on time, on budget, and on value

Source : Geneca
Type of survey : Interview based study of software projects
Date : 2010 – 2011

Interviews with 600 people closely involved in software development projects finds that even at the start of a project many people expect their projects to fail!

1. “Fuzzy business objectives, out-of-sync stakeholders, and excessive rework” mean that 75% of project participants lack confidence that their projects will succeed.
2. A truly stunning 78% of respondents reported that the “Business is usually or always out of sync with project requirements”

Source material - Why a Majority of Business and IT Teams Anticipate Their Software Development Projects Will Fail

Source : KPMG (New Zealand)
Type of survey : Survey of 100 businesses across a broad cross section of industries
Date : Dec 2010

KPMG survey of Project Management practices in New Zealand finds some truly startling results;

1. Survey shows an incredible 70% of organizations have suffered at least one project failure in the prior 12 months!
2. 50% of respondents also indicated that their project failed to consistently achieve what they set out to achieve!

Reference article - Most Business Experience Project Failure

Source material – KPMG Project Management Survey 2010

Source : IBM
Type of survey : Survey of 1,500 change management executives
Date : Oct 2008

IBM survey in the success / failure rates of “change” projects finds;

1. Only 40% of projects met schedule, budget and quality goals
2. Best organizations are 10 times more successful than worst organizations
3. Biggest barriers to success listed as people factors: Changing mindsets and attitudes – 58%. Corporate culture – 49%.  Lack of senior management support – 32%.
4. Underestimation of complexity listed as a factor in 35% of projects

For source data read – Making change work

Source : Logica Management Consulting
Type of survey : Survey of 380 senior executives in western Europe
Date : Oct 2008

Logica Management Consulting and the Economist Intelligence Unit studied success rates for business process change projects (most of which have significant technology components). A cross section of different industries were included in the survey.

Findings showed;

1. 35% of organizations abandoned a major project in the last 3 years
2. 37% of business process change projects fail to deliver benefits

For source data read – Failing business process change projects substantially impact financial performance of UK business

Source : United States Government Accountability Office
Type of survey : Review of federally funded technology projects
Date : 31 Jul 2008

Study finds 413 of 840 (49%) federally funded IT projects are either poorly planned, poorly performing or both.

Project Railhead provides a good example of the types of problems involved.  In the Railhead case the complete $500M investment is in jeopardy.

For source data read – GAO-08-1051T

Source : Information Systems Audit and Control Association (ISACA)
Scope : 400 respondents
Date : May 2008

Key findings

• 43% of organizations have suffered a recent project failure

• At a typical enterprise 20% of technology investments are not fully realized

Source – IT Magazine

Source : Guardian Newspaper (UK)
Scope : Investigation into government waste in the UK since year 2000
Date : 5 Jan 2008

1. Study of government projects reveals $4billion in wasted efforts as a result of failed projects
2. “Only 30% of our projects and programs are successful” -Joe Harley, programme and systems delivery officer at the Department for Work and Pensions

For source article read – Not fit for purpose

Source : Dr Dobbs Journal
Scope : 586 respondents to email survey (Dr Dobbs subscriber list)
Date : Aug 2007 and Oct 2011

1. 70% of respondents had been involved in a project they knew would fail right from the start
2. Success rates for Agile projects 72%, success rate for traditional approaches 63%

For source data read – IT Project Success Rates Survey (2007 version).  Updated version 2011 – 2011 Project Success Rates

Source : KPMG – Global IT Project Management Survey
Scope : Survey of 600 organizations globally
Date : 2005

1. In just a 12 month period 49% of organizations had suffered a recent project failure
2. In the same period only 2% of organizations reported that all of their projects achieved the desired benefits
3. 86% of organizations reported a shortfall of at least 25% of targetted benefits across their portfolio of projects
4. Many organizations fail to measure benefits so they are unaware of their true status in terms of benefits realization

For source data read – Global IT Project Management Survey

The very first project I had an opportunity to observe at close quarters ran into very serious trouble. What should have been a relatively simple software development project (it was planned as 6 months in duration with a team of 6 people), turned into an 18-month slog in which much of the original design had to be scrapped and the code rewritten because it didn’t work properly. Although the project did eventually end (after an extended period of post production release bug fixing) the problems encountered were all fully avoidable had an effective leadership structure been put in place.

As a fresh graduate recruit more than 20 years ago, that project was a real eye opener to me. The problems the project encountered sparked in me an interest in the causes of project failure and what it takes to make a project a success. That interest has stayed with me throughout my career and is what led me a few years ago into switching from being a 20+ year veteran of Project Management into becoming an educator and researcher.

Since that first project, I’ve found that project failure is far more common than I thought when I first joined British Airways as a graduate recruit. As my career developed I’ve witnessed a number of failures up close and have meet hundreds of people who have had the same experiences. In fact in class when I ask how many people have witnessed or participated in a troubled project, pretty much everyone with any significant work experiences puts up their hand.

Each one of those hands represents money wasted, time lost and opportunity squandered. Add that up globally and we are talking about hundreds of billions of dollars annually. Just a small improvement in success rates could be a very major contributor to the global economy.

As a contribution to improving the situation I use this website as a support reference for the training I provide my students. Open to the public as well, the site is intended to act as a platform for discussion and a vehicle for raising awareness of the causes of project failure. I hope you will find it useful and am open to feedback.

If you would like to stay in touch, please feel free to send me a Linkedin request (please denote that you found me via this website). If you are an academic institution interested in joining the group of universities who license my online classes please review the brochure for my latest online course offering. If you are simply browsing, have a read through and I hope you find some ideas that will help you improve the chances that your projects will be a success. If you would like to read my bio, click here.

Thanks

Robert Goatham

Contributing editor

This website is maintained by Robert Goatham of Calleam Consulting Ltd. Contact Robert via the form below or visit the Calleam Consulting website for more information.

When failure occurs it is sometimes due to a single mistakes made in planning or executing the project. More often than not however, failure is the cumulative result of many mistakes. In such situations the mistakes are themselves often born out of a dysfunctional environment that sets the stage upon which mistakes can be made and that acts as a barrier to detecting and correcting the mistakes. The following links provide examples of the types of behavioural patterns that create these dysfunctional environments. By understanding these “patterns” the mechanisms behind project failure can be better understood.

components-in-failure1

Figure 1 – Layers in project failure (click to enlarge)

Each pattern embodies a broad set of behaviours that negatively influences the way individuals, teams, groups and even whole organizations, make project related decisions and how people work together.  The resulting problems interact with individual trigger events (mistakes) and the combined effects are the drivers of project failure (figure 1).

The following page lists some of the more common patterns. If you’re new to the site, try reading our introductory article on the topic “Disaster DNA – Decoding the DNA of failed technology projects” before reading the samples below.

The following entries are examples of some of the most common patterns;

1. First option adoption
   Team fails to generate alternate ideas for how to meet the project objectives resulting in them settling for the first option they thought of rather than the best available option
2. Silos
   Barriers between organizations and group lead to a breakdown in collaboration
3. The pressure wave
   The build up of schedule pressure due to inaction in the face of an impending fixed deadline
4. Disconnect failure
   Project creates its intended deliverables, but those deliverables fail to deliver the intended business value
5. Top led failure
   Mistakes made by Senior Executives early in the project set the project on a course to disaster
6. Focal imbalance failure
   One or more critical aspects of the project receives insufficient attention leading to failure
7. Bottom fed failure
   Poor quality at the implementation level results in project failure
8. Alignment failure
   Different parties are focused on different goals (often unstated goals) resulting in conflicts and misalinged efforts
9. Schedule pressure failure
   Excessive schedule pressure results in critical mistakes that otherwise would not have been made
10. Commitment failures
    Project team makes unachievable commitments to schedule, budget and scope
11. Navigational failures
    Team lacks leadership and oversight in one or more dimensions
12. Intellectual disintegration failure
    Failure to communicate results in individuals and groups having different understandings and heading off in different directions
13. Transitional failures
    Deliverables are created, but the value the project hoped to create is lost due to an ineffective transition into the operational world and failure to track outcomes
14. The fast-forward freeze-out
    The failure to consult stakeholders during the planning process in order to expedite progress.
15. Green shifting
    The tendency to report project status in positive terms despite growing indications that serious problems exist
16. Left shifting
    Key strategic, architectural and organizational decisions are down played in favour of diving into the hard core development activities
17. Quality kaboom
    Quality and testing activities are pushed to the end of the development cycle rather than being seen as an ongoing activity
18. Techcentric myopia
    Technology aspects of the project become primary focus while business and organizational issues are handled superficially
19. Gravitation
    The tendency to be drawn to back to our comfort zone
20. Poly-project blindness
    Failure to recognise that a new project has different characteristics from prior experiences and hence needs to be managed differently

To suggest a pattern that is not documented above, use the following link – Suggest a pattern

There are many causes of project failure and every failed project will have its own set of issues. Sometimes it is a single trigger event that leads to failure, but more often than not, it is a complex entwined set of problems that combine and cumulatively result in failure. Generally these issues fall into two categories. Things the team did do (but did poorly) or things the team failed to do.

Based on reviews of the projects in the Catalogue of Catastrophe and discussion with more than 500 people involved in real life projects, the following list documents 101 of the most common mistakes that lead to, or contribute to, the failure of projects:

1. Failure to understand the why behind the what results in a project delivering something that fails to meet the real needs of the organization (i.e. failure to ask or answer the question “what are we really trying to achieve?”)
2. Failure to document the “why” into a succinct and clear vision that can be used to communicate the project’s goal to the organization and as a focal point for planning
3. Project objectives are misaligned with the overall business goals and strategy of the organization as a whole (e.g. Sponsor has their own private agenda that is not aligned with the organization’s stated goals)
4. Project defines its vision and goals, but the document is put on a shelf and never used as a guide for subsequent decision making
5. Lack of coordination between multiple projects spread throughout the organization results in different projects being misaligned or potentially in conflict with each other.

1. Failure to establish a governance structure appropriate to the needs of the project (classic mistake award winner)
2. Appointing a Sponsor who fails to take ownership of the project seriously or who feels that the Project Manager is the only person responsible for making the project a success
3. Appointing a Sponsor who lacks the experience, seniority, time or training to perform the role effectively
4. Failure to establish effective leadership in one or more of the three leadership domains i.e. business, technical and organizational
5. The Project Manager lacks the interpersonal or organizational skills to bring people together and make things happen
6. Failure to find the right level of project oversight (e.g. either the Project Manager micromanages the project causing the team to become de-motivated or they fail to track things sufficiently closely allowing the project to run out of control).

1. Failure to identify or engage the stakeholders (classic mistake award winner)
2. Failing to view the project through the eyes of the stakeholders results in a failure to appreciate how the project will impact the stakeholders or how they will react to the project
3. Imposing a solution or decision on stakeholders and failing to get their buy-in
4. Allowing one stakeholder group to dominate the project while ignoring the needs of other less vocal groups
5. Failure to include appropriate “change management” type activities into the scope of the project to ensure stakeholders are able to transition from old ways of working to the new ways introduced by the project
6. Failure to establish effective communications between individuals, groups or organizations involved in the project (classic mistake award winner).

1. Lack of clear roles and responsibilities result in confusion, errors and omissions
2. There are insufficient team members to complete the work that has been committed to
3. Projects are done “off the side of the desk” (i.e. team members are expected to perform full time operational jobs while also meeting project milestones)
4. The team lacks the Subject Matter Expertise needed to complete the project successfully
5. Selecting the first available person to fill a role rather than waiting for the person who is best qualified
6. Failure to provide team with appropriate training in either the technology in use, the processes the team will be using or the business domain in which the system will function
7. Lack of feedback processes allows discontent in the team to simmer under the surface
8. The Project Manager’s failure to address poor team dynamics or obvious non-performance of an individual team member results in the rest of the team becoming disengaged
9. Practices that undermine team motivation
10. Pushing a team that is already exhausted into doing even more overtime
11. Adding more resources to an already late project causes addition strain on the leadership team resulting in even lower team performance (Brooks law).

1. Lack of formality in the scope definition process results in vagueness and different people having different understandings of what is in and what is out of scope
2. Vague or open ended requirements (such as requirements that end with “etc”)
3. Failure to address excessive scope volatility or uncontrolled scope creep (classic mistake award winner)
4. Failure to fully understand the operational context in which the product being produced needs to function once the project is over (classic mistake award winner)
5. Requirements are defined by an intermediary without directly consulting or involving those who will eventually use the product being produced (see also lack of stakeholder engagement above)
6. Individual requirements are never vetted against the project’s overall objectives to ensure each requirement supports the project’s objective and has a reasonable Return on Investment (ROI)
7. The project requirements are written based on the assumption that everything will work as planned. Requirements to handle potential problems or more challenging situations that might occur are never considered
8. Failure to broker agreement between stakeholders with differing perspectives or requirements.

1. Those who will actually perform the work are excluded from the estimating process
2. Estimates are arbitrarily cut in order to secure a contract or make a project more attractive
3. Allowing a manager, sales agent or customer to bully the team into making unrealistic commitments
4. Estimates are provided without a corresponding statement of scope
5. Estimation is done based on insufficient information or analysis (rapid off-the-cuff estimates become firm commitments)
6. Commitments are made to firm estimates, rather than using a range of values that encapsulate the unknowns in the estimate
7. The assumptions used for estimating are never documented, discussed or validated
8. Big ticket items are estimated, but because they are less visible, the smaller scale activities (the peanut list) are omitted
9. Estimation is done without referring back to a repository of performance data culled from prior projects
10. Failure to build in contingency to handle unknowns
11. Assuming a new tool, process or system being used by the team will deliver instant productivity improvements.

1. Failure to plan – diving into the performance and execution of work without first slowing down to think
2. The underestimation of complexity (classic mistake award winner)
3. Working under constant and excessive schedule pressure
4. Assuming effort estimates can be directly equated to elapsed task durations without any buffers or room for non-productive time
5. Failure to manage management or customer expectations
6. Planning is seen as the Project Manager’s responsibility rather than a team activity
7. Failure to break a large scale master plan into more manageable pieces that can be delivered incrementally
8. Team commitments themselves to a schedule without first getting corresponding commitments from other groups and stakeholders who also have to commit to the schedule (aka schedule suicide)
9. Unclear roles and responsibilities led to confusion and gaps
10. Some team members are allowed to become overloaded resulting in degraded performance in critical areas of the project while others are underutilized
11. Requirements are never prioritized resulting in team focusing energies on lower priority items instead of high priority work
12. Failure to include appropriate culture change activities as part of the project plan (classic mistake award winner)
13. Failure to provide sufficient user training when deploying the product produced by the project into its operational environment (classic mistake award winner)
14. Failure to build training or ramp up time into the plan
15. Change requests are handled informally without assessing their implications or agreeing to changes in schedule and budget.

1. Failure to think ahead and to foresee and address potential problems (Classic mistake award winner)
2. Risk management is seen as an independent activity rather than an integral part of the planning process
3. Risk, problems and issues become confused as a result team isn’t really doing risk management. 

1. Allowing a pet idea to become the chosen solution without considering if other solutions might better meet the project’s overall goal
2. Teams starts developing individual components without first thinking through an overall architecture or how the different components will be integrated together. That lack of architecture then results in duplication of effort, gaps, unexpected integration costs and other inefficiencies
3. Failure to take into account non-functional requirements when designing a product, system or process (especially performance requirements) results in a deliverable that is operationally unusable
4. Poor architecture results in a system that is difficult to debug and maintain
5. Being seduced into using leading edge technology where it is not needed or inappropriate
6. Developer “gold plating” (developers implement the Rolls Royce version of a product when a Chevy was all that was needed)
7. Trying to solve all problems with a specific tool simply because it is well understood rather than because it is well suited to the job in hand
8. New tools are used by the project team without providing the team with adequate training or arranging for appropriate vendor support. 

1. Failure to maintain control over document or component versions results in confusion over which is current, compatibility problems and other issues that disrupt progress
2. Failure to put in place appropriate tools for organizing and managing information results in a loss of key information and/or a loss of control.

1. Quality requirements are never discussed, thereby allowing different people to have different expectations of what is being produced and the standards to be achieved
2. Failure to plan into the project appropriate reviews, tests or checkpoints at which quality can be verified
3. Reviews of documents and design papers focus on spelling and grammar rather than on substantive issues
4. Quality is viewed simply in terms of testing rather than a culture of working
5. The team developing the project’s deliverables sees quality as the responsibility of the Quality Assurance group rather than a shared responsibility (the so called “throw it over the wall” mentality)
6. Testing focuses on the simple test cases while ignore the more complex situations such as error and recovery handling when things go wrong
7. Integration and testing of the individual components created in the project is left until all development activities are complete rather than doing ongoing incremental ingratiation and verification to find and fix problems early
8. Testing in a test environment that is configured differently from the target production, or operational environment in which the project’s deliverables will be used.

1. Believing that although the team is behind schedule, they will catch up later
2. The project plan is published but there is insufficient follow up or tracking to allow issues to be surfaced and addressed early. Those failures result in delays and other knock-on problems
3. Bad news is glossed over when presenting to customers, managers and stakeholders (aka “Green Shifting“)
4. Dismissing information that might show that the project is running into difficulties (i.e. falling prey to the “confirmation bias”)
5. Schedule and budget become the driving force, as a result corners are cut and quality is compromised (pressure to mark a task as complete results in quality problems remaining undetected or being ignored)
6. Project is tracked based on large work items rather than smaller increments
7. Failure to monitor sub-contractor or vendor performance on a regular basis
8. Believing that a task reported by a team member as 90% done really is 90% done (note often that last 10% takes as long in calendar time as the first 90%)
9. Believing that because a person was told something once (weeks or months ago), they will remember what they were asked to do and when they were supposed to do it (failure to put in place a system that ensures people are reminded of upcoming activities and commitments).

1. Key decisions (strategic, structural or architectural type decisions) are made by people who lack the subject matter expertise to be making the decision
2. When making critical decisions expert advice is either ignored or simply never solicited
3. Lack of “situational awareness” results in ineffective decisions being made
4. Failure to bring closure to a critical decision results in wheel-spin and inaction over extended periods of time
5. Team avoids the difficult decisions because some stakeholders maybe unhappy with the outcome
6. Group decisions are made at the lowest common denominator rather than facilitating group decision making towards the best possible answer
7. Key decisions are made without identifying or considering alternatives (aka “First Option Adoption“)
8. Decision fragments are left unanswered (parts of the who, why, when, where and how components of a decision are made, but others are never finalized) resulting in confusion
9. Failure to establish clear ownership of decisions or the process by which key decisions will be made results in indecision and confusion.

The following entries record some of the more noteworthy troubled projects from around the word (read our FAQ for more information).  If you are aware of other major troubled projects please click here to submit a report.

Jump to prior years 2012, 2011, 2010, 2009, 2008, 2007, 2006, Recent classics, Historical classics,

For an analysis of the most common mistakes made in the projects listed below read the “Classic Mistakes” page.

Organization : British Broadcasting Corporation – UK
Project : Digital Media Initiative
Outline : Digital media production system project fails to deliver
Date : May 2013 Cost : £100M
… read more

1. J.C. Penny – USA - $1B
   … read more 
2. New Zealand – Ministry of Education – $30M
   … read more
3. State of California – $254M
   … read more
4. Marin County – $33M
   … read more 
5. Boeing Commercial Aeroplanes – up to $18B
   … read more

1. Northern Rock Asset Management – $400M
   … read more
2. U.S. Air Force – $1B
   … read more 
3. Mitt Romney 2012 Presidential Campaign
   … read more
4. Department of Transport – UK - £40M to £100M (estimated)
   … read more
5. Knight Capital – $400M
6. … read more
7. Sanctuary of Mercy Church – Borja, Spain
   … read more 
8. G4S Security – £60M
   … read more 
9. Victoria Health Authority – $566M
   …read more
10. US Army – $5B
    … read more
11. British Home Office – UK - £105M
    … read more
12. Dept. Homeland Security – USA – $45M
    … read more

1. Victoria Police Department – Australia - $100M
   … read more
2. J.P Morgan Chase – $6B
   … read more 
3. Department of Defence – Australia – $40M
   … read more

1. BSkyB/EDS - £200M GBP
   … read more
2. City of New York – USA – $540M cost overrun
   … read more
3. UK Fire Services - £650 GBP
   … read more
4. Queensland Health – Australia – $64.5M
   … read more
5. Dept. Homeland Security – USA – $1B
   … read more
6. Microsoft – USA – Undisclosed
   … read more
7. Department of Primary Industry – Australia – $2.25B AUD
   … read more
8. National Health Service – UK – $24B
   … read more

1. Sydney Water – Australia – $70 AUD
   … read more
2. Canadian Payments Association – Canada – $300M
   … read more
3. Westjet – Canada – Update from 2007 failure story
   …read more
4. London Stock Exchange – UK – $68M
   … read more
5. Veterans Affairs – USA – $41M
   …read more
6. Foundation for student life – Norway – $14M + some very smelly students
   … read more
7. US Navy – USA – $13B
   … read more
8. National Offender Management Services – UK – $375M
   … read more
9. MI5 – MI 6 – UK – Reported to be tens of millions of pounds
   … read more
10. City of Vancouver – Canada – $250M cost overrun
    … read more
11. Air Canada – Canada – $67M cost overrun
    … read more

1. Department of Homeland Security – USA – $500M
   … read more
2. Edinburgh Fringe Festival (World’s largest arts festival) – Scotland – Ticketing system
   … read more
3. HM Revenue Collection – UK – Child tax credit systems – $5,600M
   … read more
4. Rate Collection Agency – Northern Island – Local tax collection system
   … read more
5. Ministry of Defense – UK – Helicopter upgrade – $1,000M
   … read more
6. Justice Dept – Australia – Court proceedings management system – $54M
   … read more
7. Transport Ticketing Authority – Australia – Smart card system – $350M
   … read more
8. Department of Transport – UK – $160M
   …read more
9. Census Bureau – USA – $3,000M
   …read more
10. British Airways PLC – Move to T5 – $32M
    … read more
11. Waste Management Inc – ERP System – $100M
    … read more
12. Qantas – Australia – $40M
    … read more

1. New South Wales Government – Australia – $370M
   …read more
2. Service Personnel and Veterans Agency (SPVA) – UK – $100M
   …read more
3. Lhufthansa Systems – Germany
   …read more
4. Social Insurance Agency – Japan
   …read more
5. Junior Doctors Recruitment System – UK – $12M
   …read more
6. American LaFrance – USA
   …read more
7. General Register Office – UK – $12M
   …read more
8. State of Wisconsin – USA – $23M
   … read more
9. Centrica PLC (British Gas) - UK – $687M
   …read more
10. Los Angeles Unified School District (LAUSD) – USA – $95M
    …read more
11. West Jet – Canada – $34M
    …read more

1. Department of Homeland Security – USA – $20M
   …read more
2. Airbus A380 – $6.5B
   …read more 
3. Justice Department – Canada – $1,000M
   … read more
4. University of Wisconsin – $28M
   …read more
5. Defense Department – Australia – Helicopter upgrade – $1,000M
   … read more
6. Department for Environment, Food and Rural Affairs – UK – $610M
   …read more

1. FBI – Virtual Case File – USA – $170M
   …read more
2. Denver Airport Baggage Handling System (2005 was the end of a very long story) – $560M
   … read the full case study
3. British Columbia – Fast Ferry Fiasco – $460M
   …read more 
4. The Millennium Experience and the Millennium Dome
   …read more 
5. Fox-Meyer Drug
   …read more 
6. London Stock Exchange – Taurus – Up to £475M
   …read more 

1. Advanced Passenger Train (APT) – UK - £150M (2012 adjusted cost)
   …read more 
2. Sinclair Vehicles (C5) – UK - £30M (2012 adjusted cost)
   …read more 
3. Bristol Aeroplane Company – UK – 1949 – £350M (2012 adjusted cost)
   …read more
4. de Havilland Aircraft Company – UK – 1949 – Full cost unknown
   …read more 
5. Tacoma Narrows – USA – 1940 – $105 (2012 adjusted cost)
   …read more 
6. Swedish Navy – The Vasa – 1628 – Cost unknown
   …read more 

R. Goatham - Editor

If you would like to discuss further please feel free to Contact us.

Calleam Consulting provides feature articles that deal with subjects related to the successful management of technology projects. Currently featured articles are listed below;

1. Disaster DNA – Decoding the DNA of failed projects
   Ineffective decision making, dysfunctional decision making and the problems that inhibit effective communications are the common problems that cause projects to fail.  In this featured article some of the common ailments that affect the decision making within the team are reviewed … read more
2. The learning journey – From novice to expert
   Expertise is the fuel that powers project success. Where a project has people with the necessary knowledge and capabilities the chances of success rises fast. The process of developing expertise is however very poorly understood. Anyone can say on their resume that they are an expert, but how many really are? In this article we’ll look at what expertise is and the processes through which learning occurs. More complex than it first appears the learning process is a journey through which we learn to perceive, interpret and process information … read more
3. US Census Bureau – Field Data Collection Automation project – Case study
   With responsibility for counting every man, woman and child in the USA every 10 years the US Census Bureau faces a monumental administrative task. For the 2010 Census the department decided that to improve efficiency and accuracy automation needed to play a bigger role. Despite the best of intentions and a valid concept, lack of management controls caused the project to unravel … read more
4. Denver International Airport Baggage System Revisited – A look at the critical decisions – Case study
   The problems with the automated baggage handling system that delayed the opening of the Denver International Airport (DIA) in 1995 are a well documented example of project failure. In an article that looks at the case from a different perspective, the critical decisions that led to failure are isolated and the context in which those decisions were made is explored. Although the DIA failure can be looked at in many ways, the article focuses on the failure to listen to expert advice as the central theme that led to failure. A theme that is unfortunately still alive and well today … read more
5. Intellectual Infrastructure
   Being manager of a software development organization can be a stressful role. Failure rates among technology projects are higher than any other type of mainstream project. In an article that looks at the practices of some of the most effective software development organizations, the role of management in building a base from which success is built is considered … read more
6. The Story Behind the High Failure Rates in the IT Sector
   It’s an age old question, are technology projects (especially those with significant software development activities), somehow different from other types of project? People have argued both sides of this one, but the following article gives an interesting new perspective that may answer the question once and for all … read more

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 (if not a trillion dollars). 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?”

Figure 1 – Layers in project failure
(click for larger version)

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
5. The Why Projects Fail workshop

R. Goatham – Editor

If you would like to discuss further please feel free to Contact us.