Death March –

Case Studies in Predictable Project Failure

by Jonathan Conway

Systems Development – Project Management

ITC505 Assignment 1

August 23, 2011

Table of Contents
Introduction 3
Case 1 – Denver Airport Baggage Handling System 4
Background 4
Project Results 5
Completion date 7
Scope 7
Quality 7
Cost 7
Issues 5
Inadequate planning 5
Scope creep 6
Chaotic communications 6
Stakeholders not engaged 6
Ideas for Improvement 7
Identify the stakeholders 7
Manage risk 7
Define and control project scope 8
Facilitate communications 8
Case 2 – Mars Climate Orbiter 10
Background 10
Project Results 11
Issues 11
Inadequate training and communication 11
Inadequate risk management Error! Bookmark not defined.
Ideas for improvement 12
Create a communications plan 12
Identify and analyse risks 12
Concluding notes 12
References 15
Introduction
What is a death march project?

According to software industry veteran Edward Yourdon (2004), a death march

project is any project “where the schedule, budget, staff, or resources are 50–100
percent less than what they should be.”

Yourdon goes on to characterize such a project as follows:

“A death march project is one for which an unbiased, objective risk

assessment (which includes an assessment of technical risks, personnel risks,
legal risks, political risks, etc.) determines that the likelihood of failure is >50
percent.” (Yourdon, 2004)

Thus, a death march isn’t merely a project which experiences failure, but one whose
failure could have been anticipated from the outset, given proper planning. In this
sense, it is a “march” toward almost certain failure.

This is not to say that death march projects have never succeeded. The 1965 Apollo
mission was successful in the stated goal of setting a man on the moon within a
decade. But projects like this are the exception, not the rule.

If we want to execute projects in such a way that luck and/or long hours will not have
to be relied upon, we need to avoid the death march scenario altogether by effectively
planning the project, from the start, to achieve its goals within a margin of success.

Through the application of project management skills, such as communications

management, risk management and scope management, death marches can be averted.

A critical analysis of a proposal might lead to a lessening of the scope, an increasing

of the resources and/or budget and/or time for the project, or a complete rejection of
the project, in favour of a smaller project which would be more achievable while
providing worthwhile value.

In the following two case studies, we will examine the background and issues leading
to the death march scenario and look at project management techniques which could
have set each project on a better course.
Case 1 – Denver Airport Baggage Handling
System
Background
Observing the need for greater airport capacity and the opportunity to position Denver
as a major air transportation hub, the City and Country of Denver planned to build a
massive new airport, the New Denver International Airport. (Calleam Consulting,
2008, p. 1)

The airport was to contain 12 major runways and cover an area of approx. 53 square
miles. It would serve over 50 million customers per year. (de Neufville, 1994, p. 2)

The size and scale of such an airport raised a crucial question: how to move baggage
from the various airlines around the airport, in the most time-efficient way?

The proposed solution was dubbed the “Integrated Automated Baggage Handling
System”. It would service the entire airport, automatically distributing baggage
(including transfers) between check-in, the aircraft (on 3 concourses) and pick-up on
arrival. (de Neufville, 1994, p. 2)

It would allow any baggage item to be moved anywhere in the airport within 10
minutes, with a maximum delivery time of 30 minutes per aircraft. (de Neufville,
1994, p. 4)

Airport construction commenced in September 1989, with an initial outlay of $60

million from federal officials. The airport was expected to open on October 31, 1993.
(“Denver International Airport”, 2010).

A project management team was put together, consisting of Denver city officials and
a joint-venture engineering, architecture and airport-design firm. (Gryszkowiec, 1995,
pp. 2-3)

Over the course of 1991, Continental Airlines and United Airlines signed on. United
Airlines engaged BAE Systems, (who had established a track record of building major
baggage systems for other airports) to build the baggage system for Concourse A.
(Calleam Consulting, 2008, p. 2)

In late 1991, the Project Management Team ascertained the need for an airport-wide
automated baggage system, and requested bids from 16 companies. Only 3 responded,
and their proposals indicated that they would be unable to complete the system in time
for the October 1993 opening. (Calleam Consulting, 2008, pp. 2-5)

In April 1992, the Project Management Team approached BAE directly for a bid, and
a $175.6 million contract to build the entire system was “hammered out” in 3 intense
working sessions. (Donaldson, 2002, p. 3)
The remainder of 1992 saw further changes in direction and scope. United Airlines
cut out plans for having the system transfer baggage between aircraft and both United
and Continental requested that the system should support oversized baggage and ski
equipment. (Donaldson, 2002, p. 3)

As late as January 1993, change requests were issued, to increase the size of the ski
equipment claiming area, and add maintenance tracks to the carts to be serviced
without being removed from the rails. (Donaldson, 2002, p. 4)

In February, Mayor Webb delayed the scheduled October 1993 opening to mid-
December. Further delays pushed the opening forward to March 9 1994, May 15
1995, then postponed indefinitely. (Donaldson, 2002, pp. 4-5; Schloh, 1996, pp. 17-
18)

During 1994-1995, several more major changes were made – United altered its odd-
size baggage inputs, electronic systems (including circuitry and thousands of motors)
were unsuitable and had to be modified. (Donaldson, 2002, p. 4-5)

Denver had the system assessed by German firm “Logplan” and, based on their
advice, decided to install a manual “tug-and-cart system”. (Schloh, 1996, pp. 12-13)

The airport was finally opened in February 1995. The automated baggage system had
been all but scrapped. Instead, United went with a simplified automatic system,
Continental with a manual “tug-and-cart” system, and the other airlines with
conventional, labour-intensive systems. (Calleam Consulting, 2008, pp. 8-10)

Issues
While many technical issues were encountered, examining decisions made at a
management level gives us insight into the underlying causes of those issues, and of
the project’s failure.

Insufficient attention to risk

The several published reports on this subject readily agree on one point: in planning
the project, the management team vastly underestimated the complexity of the
baggage system.

For example, “line balancing” – the problem of distributing empty carts to the 100
pickup points throughout the airport which required them, turned out to have an
exponentially rising difficulty level, according to the number of lines requiring
service. (de Neufville, 1994, p. 7)

Independent feasibility studies indicated that a system of this scale could not be built
and tested by October 1993. (Gryszkowiec, 1993, p. 3)

Only 3 companies were willing to bid on the proposals, and all 3 bids were rejected.
When the project management team finally put the bid to BAE, they spent only a
short amount of time coming up with an estimate.
Ignorance of the complexity, in turn, led to an underestimation of the time and
resources that would be required for its completion.

The baggage system became the critical path of the entire project, an unmitigated risk
which the management team apparently ignored when they went ahead with
execution.

Poor project planning

Construction of the airport building was underway before the plan for the baggage
system had been finalized.

At later stages of the project, the building proved unsuitable: the underground tunnels
were too narrow and had sharp turns, causing difficulties in building the baggage
system’s tracks. (Schloh, 1996, p. 9)

This was a result of poor planning. The airport construction was not identified as
being dependent on the design of the integrated baggage system.

Scope creep
Changes to the project scope were made throughout the planning phase, and even into
the execution phase. These led to technical difficulties which hampered progress.

BAE, the company contracted to build the system, were given a fixed-fee contract.
But once BAE had begun work, Denver officials altered plans and timetables without
consulting either the airlines or BAE. (Schloh, 1996, p. 9)

Later on, the airline companies (which had not been sufficiently engaged from the
start) requested new changes, which also impacted the plan. For example,
Gryszkowiec notes that, in response to changes requested by Continental Airlines,
“the City moved the international gates away from the north side of the main terminal
to its Concourse A and built a passenger bridge from Concourse A to the main
terminal, duplicating the function of a below-ground “people-mover” system”.
(Gryszkowiec, 1993, p. 3)

Failure to lock down the scope early led to an inability to deliver the requirements
according to scope.

Chaotic communications
Communications between the Denver officials, the project management team, BAE
and the airlines were never clearly defined.

Each party had their own task tracking systems and there was a lot of redundancy.
Efforts to organize this information into a central database were not effective.
(Bainum, Ji, Kheny, 2005, para. 19)

Stakeholders not engaged

The airlines were indeed key stakeholders in the project, having a vested interest in
the way the airport would be constructed, as well as providing significant investment.
Yet, they were excluded from early discussions, including bid solicitation and
development of the contract with BAE. (Gryszkowiec, 1993)

Both the airlines and BEA were not consulted when Denver officials began making
changes to the scope.

Project Results
Completion date
The opening of the airport, originally slated for October 1993, was pushed to
February 1995, a delay of 16 months.

Scope
The original plan for an airport-wide automated baggage system was abandoned;
instead the airport operated with several different systems, some of them semi-
automated, others manual.

Quality
Design changes made late into the project, cost the system some efficiency and
capacity. “Only half of the 84 airport's gates were served, and at only 12 percent of
the system's capacity. Instead of handling originating, terminating, and transfer
baggage, the automated system handled only baggage originating in Denver.”
(Schloh, 1996, p. 17)

Cost
The cost of the baggage system increased from the $193 million estimate to $311
million. The total cost of the airport, originally $1.7 billion, increased to $4.5 billion.
(Schloh, 1996, p. 17-19; c)

Ideas for Improvement

This section outlines some actions that could have been taken to avoid the problems
mentioned above.

Identify the stakeholders

The airlines, key stakeholders of the project, were neither involved in initial planning
of the airport, nor in contract negotiations with BAE. (Calleam Consulting, 2008, p. 6)

They should have been identified and consulted from the start, and had a role in
determining requirements and deliverables, and negotiating the contract for building
the baggage system.

They would then have had sufficient opportunity to raise requirements such as the
ability to handle ski gear early on, rather than doing so during the 1991-1993 period.

Manage risk
Building an integrated, automated baggage handling system was clearly a risk, since it
involved the use of new technologies in highly complex ways.
The upside, of course, was that if successful, it would have been the first system of its
kind, and would deliver world-first performance among airport baggage systems.

During scheduling, the management team could have put together a list of risks
assumptions and constraints, incorporating feedback from the airlines and BAE.

A simple risk identification process would have identified the baggage system as a
key risk, and allowed the impact of its failure to be assessed and strategies planned.

Instead of the “all-or-nothing” approach of attempting to deliver a complex, world-

first baggage system, a backup plan could have been arranged.

For example DeMarco and Lister (2003) pointed out that constructing the airport with
larger tunnels would have allowed them revert to a tug-and-pull system if the
automatic system turned out to be unfeasible. (p. 70)

This backup system could have been used as a mitigation strategy.

Possibly, the baggage system could be taken off the critical path by opening the
airport with a smaller, simpler system and later phasing in the more advanced system.

Define and control project scope

A scope definition, based on input from all of the stakeholders, would have limited
the amount of work to be done and made stakeholders agree on a common, basic set
of requirements for the system.

A formal change request process would require changes to scope to be assessed for
their impact on time, cost and risk.

For example, the requests made by Continental Airlines resulted in far-reaching

changes to many mechanical and electrical systems at a high cost.

These changes should have been critically evaluated and passed by the contractor,
BAE, before going ahead.

Schedule blow-out could have been avoided by requesting that change-sets be either
revised to have less impact, or delayed until after the opening of the airport.

Facilitate communications
Communications channels could be created between Denver officials, the project
management team, BAE and the airlines. They could be formalized by means of a
communications plan.

A project communications matrix could be created, defining who should

communicate with whom and how frequently.

With a communications plan in place, the airlines and BAE would have sufficient
opportunity to voice their concerns early on, rather than at the last minute, and the
project management team could more quickly respond to this feedback and
incorporate it into the project plan.
BAE could raise concerns regarding change requests.

Improved communications would likely have prevented the embarrassing media event
of April 1994.
Case 2 – Mars Climate Orbiter
Background
In 1993, NASA started the Mars Surveyor Program with the objective of conducting
ongoing missions to explore the planet Mars. Two projects were to come out of the
program: the Mars Climate Orbiter and the Mars Polar Lander. (Stephenson, et al.,
2000, p. 10)

NASA wanted to first send the Mars Climate Orbiter (or MCO) into orbit around
Mars. It would contain a number of instruments for measuring temperature,
atmospheric conditions, etc and would transmit this data back to Earth. (Stephenson,
et al., 2000, p. 10)

In addition, it would act as a communication relay between Earth and the Mars Polar
Lander (or MPL) which would touch down on the Martian surface, where further data
could be obtained. (Clark & Canizares, 1999, para. 25)

Preparations for both projects occurred between 1995 and 1998. (“Mars Climate
Orbiter”, 2011)

The Mars Climate Orbiter was launched on December 11, 1998, from Cape
Canaveral. (“Mars Climate Orbiter”, 2011)

On September 8, 1999, a Trajectory Correction Maneuver (TCM) was computed. This

maneuver was expected to adjust the trajectory (or planned path) of the spacecraft so
that soon after it was injected into orbit, it would be at a safe distance from Mars –
226 kilometres. This correction, known as TCM-4, was subsequently executed on
September 15, 1999. (Stephenson, et al., 2000, p. 70)

During the following week, it was determined by the operations navigation team that
the distance after orbit insertion would be lower than previously expected – in the
range of 150-170 kilometres. During the final 24 hours prior to the September 23, the
Orbiter detected the strong effects of Mars’ gravitational field. About one hour prior
to orbital injection, it was determined that the altitude would in fact be 110 kilometres
– perilously close to the 80 kilometre altitude considered the minimum safe distance.
(Stephenson, et al., 2000, p. 70)

Nine and a half months after the launch, on September 23, 2009, the spacecraft
reached Mars, and was directed to perform a manoeuvre – the firing of its main
engine – which would put it into orbit around Mars. The spacecraft passed behind
Mars at 09:06 UT, and was expected to re-emerge and establish radio contact with
Earth at 09:27 UT, 10 minutes later. Unfortunately, no signal was received from the
spacecraft. (Stephenson, et al., 2000, p. 70)

Despite attempts to communicate with the MCO over the following 13 hours, no
contact was possible, and in the end, the spacecraft was abandoned. (Stephenson, et
al., 2000, p. 70)
Finally, after-the-fact navigation estimates indicated that the Orbiter had in fact been
57 kilometres from the surface of Mars –too low for spacecraft survival. (Stephenson,
et al., 2000, p. 71)

The root cause of the spacecraft’s wrong altitude was the incorrect coding of a “small
forces” data file in English units (pound-seconds), rather than metric units (Newton-
seconds). This resulted in an erroneous trajectory, and thus, the low altitude of the
spacecraft. (Stephenson, et al., 2000, p. 16)

Project Results
The Climate Orbiter was lost for good, likely burned up in the atmosphere of Mars.

Costs were estimated at $193.1 million for development of both spacecraft, $125
million for the Climate Orbiter, $91.7 million for the launch, and $42.8 million for
mission operations. (“Mars Climate Orbiter”, 2011)

Issues
Though the software error cited above was clearly a primary cause of the project
failure, the failure to identify the error and correct it, months after launch, reveals
further issues in the way the project was managed.

Inadequate training and communication

The Operations Navigation team, who took over of the mission from the Spacecraft
Development team shortly before launch, were found to be inexperienced and
inadequately trained. They lacked knowledge of “essential spacecraft design
characteristics”. (Brace, R. et al., 1999, p. 22)

The team didn’t include experienced NASA specialists, who might have offered
mentoring and picked up on errors or confusion. (Stephenson, et al., 2000, p. 18)

Members of the Navigation team were not invited to design reviews – meetings in
which the design of the aircraft and ground systems would be assessed. Neither were
they involved in preliminary testing of the spacecraft. (Stephenson, et al., 2000, p. 75)

An example of the communications breakdown can be seen in the handling of

“barbecue” mode – a daily 180 degree flip implemented by the Spacecraft
Development team for previous projects, to counteract the effects of solar pressure on
the momentum of the spacecraft. On this particular project, the Spacecraft team
decided not to implement this mode. This was never communicated to the Operations
Navigation team, who assumed it was being implemented, and this was part of the
reason they underestimated the altitude. (Stephenson, et al., 2000, p. 77)

On the other hand, the Spacecraft Development team didn’t have sufficient
knowledge of how spacecraft design parameters would relate to navigation issues.
(Brace, R. et al., 1999, p. 28)
There was also a lack of much needed managerial involvement in both overseeing the
work and coordinating between the two teams. (Stephenson, et al., 2000, p. 78-79)
Lack of verification and testing
NASA had processes for analysis, verification and testing. What was missing on this
project was a commitment to following these procedures as a way of dealing with
risk.

For example, in the case of Trajectory Correction Manoeuvres, there were no

systematic measures to verify the correctness of the trajectory models used by the
Navigation team, either within the team, or by independent peer-review. (Brace, R. et
al., 1999, p. 11, 26)

Software risks also went unidentified. The correct format for the trajectory data had
already been defined by the MSOP Project Software Interface Specification (SIS). But
there was no formal process in place to verify that the software conformed to
specifications. (Stephenson, et al., 2000, p. 81)

Ideas for improvement

Identify and analyse risks
A brainstorming session at the start of the project could have identified risks in
navigation systems, navigation operations and software.

Then a root-cause analysis on each of the risks could have helped identify important
potential causes of failure, such as the Trajectory Correction Manouvers, or the hand-
over of the spacecraft to the Navigations team.

Avoidance and mitigation measures could have included:

• Thorough briefing of the navigation team.
• Adding highly experienced specialists to the navigation team, who at the time
were relatively inexperienced. (Stephenson, et al., 2000, p. 18)
• Verifying that the software was functioning and producing correct results prior
to launch.
• Independent peer-review of all navigation procedures.
• A structured process of problem reporting and resolution. One procedure
which the Jet Propulsion Laboratory had used in past projects, the “Incident,
Surprise, Anomaly” process, could have been brought in to the team.
(Stephenson, et al., 2000, p. 81)

Create a communications plan

A communications plan could have been created, aimed at involving the Spaceship
Development team, Navigation Operations team and management in frequent, timely
discussions.

During the development phase, the Navigation team could have met with the
Spacecraft Development team, to give their input into the navigation system, and
jointly review it.

Hand-over of the spacecraft to the Navigation team prior to launch could include a
full briefing on the workings of the navigation system, and frequent meetings in
which questions could be raised.
And prior to and during the critical post-launch activities, such as the Trajectory
Correction Manoeuvres, daily meetings could be held, involving the entire project
team, as well as senior management and external SMEs.

During these meetings, management could ensure that risk-mitigation strategies were
being followed, and navigational models could be independently peer-reviewed.

With proper assistance and oversight, it’s more likely that the Navigation team would
have identified the trajectory error and taken action to correct it.
Concluding notes
John Boddie, author of Crunch Mode points out:

“The combination of excellent technical staff, superb management, outstanding

designers, and intelligent, committed customers is not enough to guarantee success for
a crunch-mode project.” (Boddie, 1987)

Indeed, in both of the projects discussed, talented individuals were hired and given
sophisticated technological challenges.

However, problems quickly ensued when management failed to define and control
scope, identify and communicate with stakeholders, facilitate communications within
the organization and anticipate and manage risk.

It was not absolutely necessary to sacrifice technological innovation in order to

achieve project success. What was necessary was to quantify the risk that technology
would bring, and ensure that strategies were in place to deal with the risk.

A degree of success was achieved in both the Denver Airport and the Mars Orbiter
undertakings. The potential for success exists in many projects – good project
management helps teams to realize it.
References
Bainum J., Ji, H., Kheny, P. (2005), The Denver International Airport Automated
Baggage Group Project. Retrieved from the Technische Universität München
(TUM) Informatics Department website:
http://www5.in.tum.de/persons/huckle/Drexel_DIA.htm

Boddie, J. (1987), Crunch Mode. (Prenrice-Hall/Yourdon Press, 1987), p. 124.

Brace, R., Casani, J., Farquhar, R., Haynes, N., Jordan, F., Kohilase, C., ... Tolson, R.
(1999) Report on the Loss of the Mars Climate Orbiter Misson (JPL D-18441)
Retrieved from http://trs-new.jpl.nasa.gov/dspace/bitstream/2014/38186/1/D-
18441.pdf

Calleum Consulting Ltd. (2008). Case Study – Denver International Airport Baggage
Handling System – An illustration of ineffectual decision making [Brochure].
Retrieved from http://calleam.com/WTPF/wp-
content/uploads/articles/DIABaggage.pdf

Clark G., Canizares, A. (1999) Navigation Team Was Unfamiliar with Mars Climate
Orbiter. Retrieved from:
http://cnre.vt.edu/gep/pdffiles/Metadata_PDF's/2.3Mars_Orbiter_Failure-
Section2.pdf

de Neufville, R. (1994). The Baggage System at Denver: Prospects and Lessons.

Journal of Air Transport Management, 1(4), 229-236

DeMarco, T., & Lister, T. (2003), Walzing with Bears: Managing Risk on Software
Projects. Dorsett House. ISBN: 0-932633-60-9

Denver International Airport. (n.d.). In Wikipedia. Retrieved August 17, 2011, from
http://en.wikipedia.org/wiki/Denver_international_airport

Donaldson, A.J.M. (2002), Software Forensics Centre Technical Report TR 2002-01

A Case Narrative of the Project Problems with the Denver Airport. Retrieved
from the Engineering and Information Sciences Middlesex University website:
http://www.eis.mdx.ac.uk/research/SFC/Reports/TR2002-01.pdf

Gryszkowiec, M. (1995). Denver International Airport [microform] : statement of

Michael Gryszkowiec, Director, Planning and Reporting, Resources,
Community and Economic Development Division, before the Subcommittee on
Aviation, Committee on Transportation and Infrastructure, House of
Representatives / United States General Accounting Office. Retrieved from the
U.S. Government Accountability website: http://
archive.gao.gov/t2pbat1/154219.pdf

Mars Climate Orbiter. (n.d.). In Wikipedia. Retrieved August 19, 2011, from
http://en.wikipedia.org/wiki/Mars_Climate_Orbiter
Schloh, M., & Stearns, D. (1996), Analysis of the Denver International Airport
baggage system. Retrieved from the Technische Universität München (TUM)
Informatics Department website: www5.in.tum.de/~huckle/schloh_DIA.pdf

Stephenson, A., LaPiana, L., Mulville, D., Rutledge, P., Bauer. F., Folta, D., ...
Gregory, F. (2000) Report on Project Management in NASA by the Mars
Climate Orbiter Mishap Investigation Board. Retrieved from NASA -
Kennedy Space Center Home Page:
http://www.ksc.nasa.gov/mars/msp98/misc/MCO_MIB_Report.pdf

Yordon, E. (2004) What is a Death March Project and Why Do They Happen?
Retrieved from:
http://www.informit.com/articles/article.aspx?p=169512&seqNum=1