Success or Failure
The success or failure of an individual project is not always clear.
Complete success or total failure are readily understood. Most projects, however, fall somewhere on the continuum of partial success or partial failure. From a project management perspective, project success is formally defined as completing project requirements within the triple constraints of time, cost, and scope.
Thus, strictly speaking, project failure is not meeting a project’s requirements within these constraints. However, such a narrow definition of project failure does not provide a complete understanding of the qualitative health of the project and whether or not it can be considered successful.
The formal definitions of project success and failure go back to the early days of project management, with the U.S. Department of Defense (DOD.)
Having to manage thousands of contractors, the DOD needed to standardize project performance reporting. The result was the earned value measurement system (EVMS.) For EVMS to be effective, metrics had to be developed to track project performance and measure project success. At the time, the understanding of metrics was relatively unsophisticated and this resulted in adopting metrics which were easy to measure. The two easy measurements of time and cost became the focus of the EVMS.
Over time, DOD contracts with the aerospace and defense industry became increasingly performance based, as engineers leading the projects focused on scope and technical achievements rather than time or cost. As long as DOD would pay for cost overruns and schedule slippages, project success could be measured in terms of technical performance. Cost overruns could exceed several hundred percent. To make matters worse, many engineers viewed “project success” as the ability to exceed, rather than just meet specifications, and doing it using DOD funding.
This brief outline of how project success has historically been measured shows that evaluating a project’s success requires balancing numerous factors. Project success can be defined in different ways, as the constraints are not equally important. For some projects, the focus may be on cost; for other projects meeting a tight delivery date is critical.
It eventually became clear that the DOD framework for evaluating project success, using the primary constraints of time, cost, and scope, was insufficient to clearly define project success, even with constraints prioritized. Other constraints were often more important than time, cost, and scope. These “other” constraints were referred to as secondary constraints and include such factors as:
- Financial success/profit maximization
- Achieving technical superiority/sustainable competitive advantage
- Alignment with strategic objectives
- Maintaining environmental standards
- Enhancing corporate reputation
- Providing opportunities for advancement for employees
Given the framework of primary and secondary constraints, companies still placed more weight on the traditional triple constraints of time, cost and scope as the primary means for defining success. The impact of secondary constraints was addressed by analyzing the effect they had on the primary constraints, whether the secondary constraints elongated or compressed any of the primary constraints. For example, developing technical superiority will generally result in increased costs (and, likely, time.)
Management experts have outlined some insights relating to project failure:
- There is no clear and simple definition of project failure
- Few projects fail by themselves; rather, it is the people that fail, due to the poor decisions they make
- The line between success and failure is not always clear; it is a grey area
- There is no “magic bullet” to guarantee success or prevent failure
- A project can be considered a failure even with the successful execution of a project plan, due to an unforeseen change in market conditions. (See Iridium Project)
- It is possible to have R&D success and marketing launch failure, “success” and “failure” in the same project
- Even the most reliable IT systems will eventually fail during implementation; it’s just a matter of time for the bugs to appear
The list of reasons why projects fail is quite long. (see end note for exhaustive list of 46 reasons projects fail.) Yet most organizations either do not recognize the early symptoms of failure or disregard these symptoms when they begin to appear. Even if they do recognize the symptoms, they often do not know what actions to take. In the end, project failure is not always the result of actions taken by the project manager.
An all too common scenario…
Procurement selects the lowest bidder without verifying the bidders know what the work entails and whether the bid is realistic. After the project starts, numerous scope changes result in cost overruns and schedule delays. Although any single cause can induce failure, it is more likely the actual failure is caused by a combination of factors.
- Infamous and well-known – to the displeasure of those involved
- Illustrative and (mostly) long forgotten – how not to introduce a new product
- Significant and still evolving – the final analysis, total cost, and lasting reputational damage still to be determined
1. Infamous and Well-known
How does one convert a $1.2 billion project into a $5.0 billion project?
It’s easy. Just build a new airport in Denver.
Dysfunctional decision making is the poison that kills technology projects. The DIA Baggage System project is a classic example. In its simplest form, the DIA project failed because those making key decision underestimated the complexity involved. After spending close to $5 billion over 14 years to get the automated baggage handling system to work, DIA officials finally pulled the plug on the project in August 2005.
Denver International Airport (DIA), was approved by City of Denver officials in 1985 to replace Stapleton International Airport; initial budget was $1.2 billion. The business case was solid. Denver needed the new airport to handle the projected volume of more than 66 million passengers per year. In 1989 voters approved the project, estimated cost grew to $1.7 billion. Construction of the airport began in November 1989. When working through the details of a lease agreement with United Airlines for the new airport, DIA’s decision makers (City of Denver Project Management Team, or PMT) did not fully understand the complexity of the scope changes that United demanded. The parties eventually reached agreement in June 1991.
In October 1990 a consultant, Breier Neidle Patrone, was hired to evaluate one of the scope changes, the feasibility of an automated baggage-handling system to be used only for the United Airlines concourse. The consultant concluded that the request by United Airlines for an automated baggage-handling system was not feasible. Rather than accept the consultant’s guidance, the DIA Project Team decided to expand the scope of the automated baggage-handling system to cover the entire airport!In early 1992 BAE Systems was selected to design and build the baggage handling system. As planned, the system would be the most complex baggage system ever attempted. The airport had already been under constructions for three years; BAE had essentially agreed to do eight years of work in two years to meet the October 1993 opening date. A series of delays ensued, with opening dates repeatedly delayed. DIA finally opened on February 28, 1995, with a largely manual trolley-based baggage handling system. The concern that a manual system would be too slow to service an airport the size of DIA proved to be unfounded.
Due to the problems with the baggage system, the airport’s opening was delayed by 16 months. Expenditure to maintain the empty airport and interest on the construction bonds cost the city of Denver $1.1 million per day during the delay. The embarrassing missteps along the way included a disastrous impromptu demonstration of the system to the media during which the system crushed bags, disgorged content, and crashed carts together at high speeds. DIA was widely ridiculed. Many mocked the project, claiming that “DIA” stood for “Delayed Indefinitely Again,” “Debacle in Aviation,” and “Denver’s Ignominious Atrocity.” See YouTube video: https://youtu.be/X9UjHTy4F6E
The DIA debacle can serve as a template for failure as seen in many other projects. Factors that contributed to the failure include:
- Underestimation of complexity
- A lack of planning resulting in subsequent changes in strategy
- Excessive schedule pressure
- Lack of due diligence
- Making firm commitments in the face of massive risks and uncertainty
- Poor stakeholder management
While these points all contributed to the failure, poor decision making was the primary problem that triggered the fiasco. Successful projects require leaders with the knowledge and experience that enables them to make effective decisions. DIA’s project management team and BAE’s Managers lacked the necessary experience for developing a system of this scale. As automated baggage systems were relatively new, even BAE’s senior management team had a limited understanding of what was involved. This lack of knowledge, combined with the fact that expert advice was routinely ignored, is at the core of this failure.
DIA Baggage System: Project Failure Risk Factor Analysis (1-5 *, 5 best/highest)
- Leadership Capabilities * very poor
- Technological Risk ***** very high
- Stakeholder Management * very poor
- Project Management * very poor
- Business Case Risk ** low
Don’t miss future editions of the Transformance Communiqué, the newsletter designed for those serious about crafting sustainable organizations.click here to create your own account.
XXX by ZZZ