The Denver Airport Case Study

The city of Denver, Colorado, set out in 1988 to build a new airport to replace the existing one, Stapleton Airport. Costs would be reduced, pollution and air-traffic delays would be eliminated, and growth would be assured. The new Denver International Airport (DIA) was scheduled to open on October 31, 1993. Finally it was partial opened in 1995, after 500 million dollars of cost overrun. What happened?


On the due date, every other part of the vast airport complex was ready to go. But the software wasn’t ready, so the airport couldn’t open. Specifically, what wasn’t ready on time was the Automated Baggage Handling System (ABHS). An article in Scientific American put responsibility for the DIA disappointment squarely on the software industry and its lax standards and practices. This was a process problem: The delays at DIA might very well have been avoided if only the project had improved its process to include higher CMM level. But an improved software process wouldn’t eliminate uncertainty from projects. A deeper analysis would have discovered other reasons. Let’s imagine the following fictional interrogation to the project management team:

• Question: Why couldn’t the airport open without the baggage-handling software?
• Answer: The baggage-handling software was on the overall project’s critical path for the airport’s opening. Passengers couldn’t be moved through the airport, even for a single day, without that system.
• Question: Why was the ABHS on the critical path?
• Answer: There was no other way to move the baggage. The system of tele-carts and bar-code readers and scanning devices and switch points and cart unloaders was the only way to get baggage to and from the planes.
• Question: Are there no alternative ways to move baggage?
• Answer: There is, for example, the time-honored method of having big burly guys haul the stuff. There is also the conventional airport approach of small trucks pulling hand-loaded carts, daisy-chained together.
• Question: When the ABHS wasn’t ready on time, why couldn’t DIA open with one of these alternative methods of moving baggage?
• Answer: The tunnels that were meant to serve the automated tele-cart system were too low for people and couldn’t accommodate the trucks.
• Question: Couldn’t the tunnels have been redesigned so that trucks and hauled carts could go through them?
• Answer: Yes, but there wasn’t time. By the time it was discovered that the ABHS software would be late, the tunnels were already built. And the time to revamp them was judged to be longer than the time required perfecting the software.
• Question: Couldn’t the revamping of the tunnels have started earlier?
• Answer: Yes, but that wasn’t judged appropriate. Money and time spent on the tunnels would have been wasted had the software actually been delivered on time, as upper management was then assuring it would be.
• Question: Wasn’t lateness of the ABHS software seen as a potential risk?
• Answer: Only after it happened. Before that, the software was placed on an aggressive schedule and manager for success.
• Question: Haven’t software projects been late before?
• Answer: Yes, but this one was supposed to be different.
• Question: Was there any history of prior projects building similar systems?
• Answer: The Franz Josef Strauss Airport in Munich had installed a pilot ABHS, designed along the lines of the DIA version.
• Question: Did the DIA team visit the Munich project, and if so, what did it learn?
• Answer: Members of DIA’s ABHS project did visit Munich. The Munich software team had allowed a full two years for testing and six months of 24-hour operation to tune the system before cut-over. They told the DIA folk to allow that much or more.
• Question: Did DIA management follow this advice?
• Answer: Since there wasn’t time for such extensive testing and tuning, they elected not to.
• Question: Did the project team give sufficient warning of impending lateness?
• Answer: When the DIA board of governors first put the ABHS out to bid, nobody was willing to submit a bid for the scheduled delivery date. Eventually, the airport engaged BAE Automated Systems to take on the project on a best-effort basis. During the project, the contractor asserted early and often than the delivery date was in jeopardy and that the project was slipping further behind with each month and each newly introduced change. All parties were made aware that they were trying to do a four-year project in two years. All of this evidence was ignored.

Conclusion:

This was a failure of risk management far more than of software process:

• Even the most perfunctory risk management effort would have listed a delay in the software delivery as a significant risk.
• An exposure analysis of this risk would have shown that since the baggage-handling software was on the critical path, any delay would postpone the airport’s opening, resulting in financial penalties of $33 million per month.
• From there, it would have been an obvious conclusion that moving the software off the critical path was a key mitigation strategy. A few million dollars spent early in the effort to make an alternative baggage-handling scheme feasible would have saved half a billion dollars from taxpayers.

Who blew it? Don’t blame the contractor. Responsibility for risk management accrues to whichever party will have to pay the price for risks that are ignored. In this case, all such costs were eventually paid for by the contracting agency, Denver Airport System.

Effective Project Managers don’t want to be blamed for ignoring risks. If risks are ignored in their project they manage expiation by making crystal clear they are not the ones ignoring those risks.

I wonder sometimes: How would end up that Project Manager from BAE Automated Systems? It is easy to imagine not very good. He surely would bear much of the blame. I hope, at least, he kept an updated risk register explaining specifically the details of one risk: the late delivery of ABHS software. I would be happy if I could find this information about it:

• Risk impact valued as of $33 million per month.
• Recommended risk response: Mitigate by redesigning the tunnels.
• And the most important: The project management team member who decided to passively accept that risk,  thinking that he had the right to believe that risk was not going to happen. That is: who decided best response was crossing fingers.

This text is based on the book: 

Waltzing with Bears: Managing Risk on Software Projects 

Ed: Dorset House Publishing, 2003

Click here to read the Spanish version of this article

Click the label English to see the other articles written in English