3 Kinds of Project Failure: The Teleport, The Winner’s Curse and The Camel

Project can fail for any number of reasons, but when you start looking at major delays and extreme cost overruns, three culprits emerge:

1. The Teleport

No one disputes that teleporting is a phenomenal idea. Yet, no one has any idea how to implement it. A lot of failed projects are like this. These sorts of projects often arise when the stakeholders get more excited with the ideas than considering the budgets and feasibility. Resource based forecasting isn’t possible because there’s no precedent and the feasibility of the idea is only understood very late in the execution phase of the project.

Examples: Sydney Opera House, Denver Airport’s Baggage System

2. The Winner’s Curse

A bidding process would seem like a sensible way to find the lowest cost provider for a project. In practice it doesn’t always work that way and the winner’s curse means you may often end up selecting not the cheapest vendor, but the one with the least reliable estimates. They appear cheapest, but only because they haven’t effectively gauged what it will actually cost to do the work. Once they are selected as a vendor, they then have leverage to increase costs and things unravel from there.

Examples: Scottish Parliament, Wembley Stadium

 

3. The Camel

Just as a camel is a horse designed by committee, so camel projects lack one person in command, and typically have large groups of people calling the shots. All projects have large numbers of requirements, but because of the large number of stakeholders these requirements cannot be scoped down to a level that will enable the project to be completed within expected time and budget:

Examples: Taurus, Eurofighter and FBI’s Virtual Case File

 

LinkedInShare
  • http://twitter.com/BruceWBenson Bruce Benson

    Capers Jones relates that, in his experience as an expert witness in court cases on failed IT/software projects, he notes 4 primary reasons behind project failures:

    1. Poor estimates before the projects start
    2. Poor quality control and a lack of pre-test inspections and static analysis
    3. Poor change control (requirements creep at more than 1% per month)
    4. Poor or even fraudulent status tracking that conceals problems instead of dealing with them.

    Your #1 & #2 I would say falls into reason #1 above. For whatever reason (unknowns, why low bids are low) the estimate is just not right.

    Your #3 lack of a true leader I’ve seen, but you then show the consequence to be requirements creep, which matches reason #3 above.

    While I’ve personally seen all of these (your’s and Caper’s) through my career, I take some exception to both lists. My own hands on experience over too many decades of running projects and fixing project organizations is that most of these often have the same root cause and both of you hint at it: poor estimates.

    The key insight is that when we finally got our estimates right (primarily the overall schedule duration) then while we still had some of the problems during the project (scope creep, etc.) the projects then delivered on time with good quality. The quick explanation is that a too compressed schedule can and will break most other processes (requirements management, QA, tracking, etc.). We just don’t see the connection in the chaos of the failing project. (For more detail, see http://pmtoolsthatwork.com/its-the-project-management-schedule-stupid/)

    Good subject.

    Bruce

    • http://www.strategicppm.wordpress.com Simon

      I’d agree that poor estimates are the root cause of most project failure, however there I think it’s helpful to