Case Study:
The
Sky High Price of Technical Baggage at Denver Airport
The
opening of the Denver International Airport was delayed by sixteen months
because of technical difficulties experienced in the baggage handling system (de
Neufville, 1994). The project exceeded $5 billion to build, and the delays in
opening the airport resulting from the baggage handling system was estimated to
cost the taxpayers $271 million per year. This figure did not include the
investment costs to stakeholders like United Airlines at $261 million,
Continental $73 million, and opportunity costs to the airlines of around $50
million.
Conspiracy
theorists deem that the failed baggage system is merely a government cover-up
of underground bunkers created for the protection of the Illuminati inside the
depths of the Rocky Mountains (Hoeller, 2015). In the case study of the failure
of the project, there is far more to the catastrophe than a conspiracy. This
paper will examine the project from the software development perspective. This
paper will investigate how the baggage handling system failed, how those
failures could have been prevented with proper development techniques, and will
cultivate lessons from it so that one can prevent those types of failures from
happening in the future.
BAE
Systems was responsible for the implementation of this massive state-of-the art
project at the Denver International Airport. There were many stakeholders in
the Denver Airport Baggage Handling System Project. Some of the key
stakeholders included: The City of Denver and the taxpayers who funded the
city, the airlines, hotel developers, UPS, FedEx, and the millions of
passengers wishing to travel to and from Denver (Unknown, 2015).
The first sign of
a problem was that the airlines were not on board with the project, and so the
City of Denver forced their hands by asking BAE Systems to construct a baggage
delivery system using generic technology. This meant that BAE Systems was
charged with a task to complete a project without the support or approval of
the airline stakeholders. The City of Denver reasoned that by continuing on
with the project, that the reluctant airlines would eventually have to
acquiesce to whatever baggage handling system they were given.
Without being able
to work with the airlines to identify user needs, BAE Systems was charged with
the insurmountable task of designing a system blind. The elicitation process
was eliminated, because the actual users would not contribute to the project.
BAE Systems then had to use feedback they had from other clients, whose needs
may or may not even align with the users from the existing project.
The next mistake
made was that the project was mismanaged. Walter Slinger was the Chief Engineer
who was responsible for the construction of the airport (Calleum 2008). As he
is a Civil Engineer, he was concerned more with the construction of the building
than the baggage handling system inside it, however, he charged himself with
making leadership decisions with BAE Systems because he was aware that the
project was on a tight schedule. He did not waste time getting advice from
third party experts, he made decisions and asked BAE Systems to implement them.
Another failure of
the project was that the enormity of the project scope was not considered in
context with the schedule. An independent contractor was hired to determine the
feasibility of the project, and they advised against it. Still, BAE Systems
continued with the project because they wanted company growth and the prospect
of future work with other airports. It was the Peter-Principal in full effect:
the company was promoted to their level of incompetency (Peter 1969). BAE
Systems had compelling reasons to want this massive project – money, notoriety,
and brand recognition – but what they failed to enforce was the basics of
technological project management. They failed to define the scope of the
project in the context of the available time and money allocated to them.
By the time the
airlines decided to participate in the design of the system, much of the
programming had already been done, resulting in numerous change orders being
submitted to try to get the project back on track with what the airlines
needed. It’s very difficult to address user needs and requirements after the
software architecture has been designed. This created a situation where BAE
Systems was having to rewrite the programming again, making changes, and
finding the bugs to the changes as they surfaced. This greatly affected the
scope, cost, and schedule of the entire airport project.
Another key
element was the failure of BAE Systems to consult with physical engineers. The
baggage handling system could not handle the sharp turns, velocity, and other
mechanical problems. Couple the physical limitations of the system with the
technical glitches of trying to scan the barcodes of non-stationary items (the
bag tags) in the 26-mile stretch of track the bags were carried upon, BAE
Systems really did not stand a chance. When the luggage was forced through the
baggage system, the baggage was ejected from the cart, busted open, and
sometimes completely blocked the path for the remaining bags. There wasn’t a
secondary plan in place to deal with the physical limitations of the extracted
luggage. There wasn’t a plan in place to even deal with the stoppage of the
carts.
At last, the
Denver International Airport opened and attempted to use the baggage system,
but later stopped using it because it was costing more money to operate than it
would to use the traditional conveyor system methods. If I would have been in
charge of the project, I would have told the City of Denver at the outset that
their time restraint goals and budget were too lofty for the tasks at hand.
Further, I would have stated that the project could not be undertaken without
the full consent and support of the airlines that would use it. Additionally, I
would have required an independent study of civil and mechanical engineers’
opinion of the suggested baggage handling system. Without the input of the
stakeholders, the project could not succeed, even with the city taxpayer’s
financial support.
I believe the project was outsourced
because the project manager was well aware that the baggage handling system
would be a major undertaking, and because he knew he didn’t have time to build
the airport and also design the baggage handling system. One of the most
important things a successful person needs to realize is when to retreat. This
project was to be the largest, most complex, most innovative baggage delivery
system known to man. BAE Systems rushed to be the provider extraordinaire,
ignoring the warning signs, the independent study, and the reluctance of the
airlines. Their hunger for the project was ferocious, their ambition felt
limitless, and they wanted this more than anything else. They had admirable
goals, but their ambitions were destined for failure.
The project caused airport opening delays,
massive cost increases, inconvenience to potential travelers, and a media
frenzy. It was supposed to be one of the most successful technological moves of
the era – but ended up being one of technology’s costliest lessons in what not
to do. The massive project failed.
In a final move, the airport decided to
open with limited use of the baggage handling system, and ultimately United
Airlines decided to forego the system entirely. The operational costs were just
too high, and the standard baggage handling methods were more effective and
less costly. The New York Times described the end, “…in an anticlimactic moment marked and mourned by
just about nobody, the only airline that ever used any part of the system will
pull the plug…” (Johnson, 2005). He continued with quoting United, “Workers
with hand-held scanners, checking baggage bar codes at every juncture of
transit, will give managers far better information and control than could have
been imagined when the automated system was designed…” (Johnson, 2005).
Overall,
the project was a huge disappointment. All the time and money in the world
couldn’t overcome the failures that started at the outset of the design and
plagued the system to the death. The lesson learned is that thorough
requirements elicitation, scope control, and project planning are some of the
most important pieces of any software project planning.
References
Calleum,
C. (2008). DIA Baggage. Retrieved April 26, 2016, from
http://www5.in.tum.de/~huckle/DIABaggage.pdf
De Neufville, R. (1994, December). The Baggage
System at Denver: Prospects and Lessons. Retrieved April 3, 2016, from
http://ardent.mit.edu/airports/ASP_papers/Bag System at Denver.PDF
Hoeller,
S. (2015, October 16). People have all sorts of conspiracy theories about
Denver's airport - here's why. Retrieved April 03, 2016, from http://www.businessinsider.com/denver-airport-conspiracy-theories-2015-10
Johnson,
K. (2005, August 27). Denver Saw the Future. It Didn't Work. Retrieved April
27, 2016, from http://www.nytimes.com/2005/08/27/us/denver-airport-saw-the-future-it-didnt-work.html?_r=0
Peter,
L. J., & Hull, R. (1969). The Peter principle. New York: W. Morrow.
Unknown, J. (2015, September 26). The
Denver International Airport Story or Everything You Ever Wanted to Know About
How Not to Run a Project (final) -. Retrieved April 26, 2016, from
http://www.jpstewartassociates.com/the-denver-international-airport-story-or-everything-you-ever-wanted-to-know-about-how-not-to-run-a-project-final/
Comments
Post a Comment