denver international airport project management case study

• Professional Services
• Creative & Design
• See all teams
• Project Management
• Workflow Management
• Task Management
• Resource Management
• See all use cases

Apps & Integrations

• Microsoft Teams
• See all integrations

Explore Wrike

• Book a Demo
• Take a Product Tour
• Start With Templates
• Customer Stories
• ROI Calculator
• Find a Reseller
• Mobile & Desktop Apps
• Cross-Tagging
• Kanban Boards
• Project Resource Planning
• Gantt Charts
• Custom Item Types
• Dynamic Request Forms
• Integrations
• See all features

Learn and connect

• Resource Hub
• Educational Guides

Become Wrike Pro

• Submit A Ticket
• Help Center
• Premium Support
• Community Topics
• Training Courses
• Facilitated Services

Lessons Learned from Project Failure at Denver International Airport: Why Checking Bags is Still a Pain

October 30, 2021 - 7 min read

We regularly review major projects to  extract valuable lessons and pass on the knowledge so that everyone can benefit. One failed project we recently took an interest in is Denver International Airport's luggage handling system.

I was compelled to study this project because checking bags at the airport is still one of my biggest fears. My eye twitches just thinking about it. You can never predict how long check-in lines will be, suitcases are lost daily, and human baggage handlers have a tendency to manhandle their wards. We have probably all wondered why airports haven't come up with a better system by now.

The Failed Project of Denver International Airport

It's not that airports haven't tried to fix the baggage system. When construction started on the new Denver International Airport, it was supposed to come with a brand-new automated system for handling luggage travel and transfers. The goal was to replace the standard reliance on manual labor with a fully-automated baggage system that would also integrate all three terminals. It would reduce aircraft turn-around time for faster service to travelers.

But the project went 16 months past its hard deadline, cost the city $560 million over budget, and performed just a fraction of its original automation goals. Instead of integrating the three concourses and all airlines, it was only used at one concourse, for one airline, for outbound flights only. The project team had to resort to building a second, manual labor system for all other baggage operations. And after valiantly attempting to use the system for 10 years, the only airline that actually adopted the system finally bowed out due to high maintenance costs.

The project ended in spectacular failure — and from their mistakes,  we stand to learn a lot about project communication, scope creep , and poor project definition .

Want a tool to improve your project management ? Start your free Wrike trial today!

3 Lessons We Should Learn from Denver

1. Listen when people say, "This isn't going to work."

Warning #1: After airport construction started, the City of Denver hired Breier Neidle Patrone Associates to evaluate if the proposed baggage system project was feasible. The company flat-out stated that  the plan was too complex . The city decided to pursue the possibility anyway.

Warning #2: A similar, simpler project in Munich took a full two years to be completed, followed by six months of 24/7 testing prior to the actual launch. The larger, much more complex Denver International Airport system was due to open in a little over two years. Which means that Denver International Airport was trying to  cram a very complicated project into a very short timeline . The Munich airport advised that it was a project set up to fail. Despite the worrying outlook, the City of Denver decided to proceed without altering their schedule.

Warning #3: When the airport began accepting bids on the new luggage system project, only three companies submitted proposals. Of those proposals, none of them predicted they'd be able to finish the project within the allotted timeframe. The city rejected all three bids, and instead approached a fourth company, BAE Systems, to convince them to take on the superhuman project; again,  without changing the proposed timeline .

Warning #4: Senior managers at BAE Systems expressed initial misgivings about the project's complexity. They estimated a 4-year timeline instead of 2 years, but the  concern was ignored and the project went on with its 2-year deadline still in place.

Four ignored warnings later, nothing had changed. If the City of Denver or the project team had heeded any of these caution flares regarding project complexity and tight deadlines, they would have changed their timeline or scaled back their goals. Instead they barreled ahead, and as a result their project went far past deadline, cost millions of extra dollars, with the final product a disappointing shadow of its original design.

 If the project failure of Denver International Airport teaches you only one thing, it's this:  pay attention to the flashing red lights . Listening to project advice keeps us from dedicating ourselves to impossible projects.

2. Don't wait to involve all parties affected by the project

While BAE Systems and the airport's larger project management team were the steamrollers on the project, they were ultimately not the parties affected by the outcome. Airlines renting space in the airport would be most impacted by the outcome of the automated baggage system. Yet they were not brought into the planning discussions. These  key stakeholders were excluded from the initial decision-making — an open invitation for failure.

Once the airlines were finally asked for their opinions,  they required major changes from the project team: adding ski equipment racks, different handling for oversized luggage, and separate maintenance tracks for broken carts. The requests required major redesign on portions of the project — some of which had already been "completed." But these requests were not optional features for the airlines, and the project team was forced to redo their work.

By waiting to approach stakeholders, the project team  wasted time and money . Had they approached the airlines right away, they would have been able to incorporate these requests into early project plans. They would have shaved off months of extra labor if they didn't have to redo completed work; not overshooting their deadline by 16 months would have saved them a good chunk of the extra $560 million spent. 

It is essential that we include stakeholders from Day 1 to avoid wasting time and money. Don't make the same mistake of waiting until halfway through a project to collect vital requirements.

3. Beware of "Big Bang" projects meant to change the world

Another project complication was the decision to go with an  all-at-once "Big Bang" rollout to all three concourses, as opposed to slower, incremental rollout. In an  article dissecting the problems with Denver International Airport's baggage system project plan , Webster & Associates LLC, an IT consulting company, said that this was one of the biggest project flaws. BAE Systems  should have tested the new automated system in sections to make sure it would work before implementing it throughout the rest of the airport.

This project was the first attempt at an automated system of this size and complexity, and was meant to change the way that airports handled baggage. They wanted instant, large-scale success. Instead, the final product fell short of everyone's expectations.

The best way to get big results is to first ensure you can  create a successful minimal viable product . Once your MVP works well, repeat the process on a larger playing ground, slowly scaling efforts until you reach the end goal.

Project Failure is Not Fatal

Although the automated baggage system failed, today the Denver International Airport is fully functional. I've even taken my skis through their airport without issue. And as long as we learn valuable lessons from their mistakes, we shouldn't consider this project a complete failure — just a painful boo-boo.

Next time you're working on a project, remember these three lessons and avoid facing the same fate as Denver International Airport:

1. Watch for red flags, and heed the warnings of experts. 2. Involve all project stakeholders from Day 1. 3. Take small steps to successfully reach the end goal.

 Good luck on your next projects and next flights!

Related Articles:

•  10 Reasons Projects Fail: Lessons from the Death Star •  3 Kinds of Data to Help Avoid Project Management Failure

Sources: http://calleam.com/WTPF/?page_id=2086 ,  http://calleam.com/WTPF/content/uploads/articles/DIABaggage.pdf ,  http://www.computerworld.com/article/2556725/it-project-management/united-axes-troubled-baggage-system-at-denver-airport.html ,  http://archive.gao.gov/t2pbat1/154219.pdf ,  http://www.eis.mdx.ac.uk/research/SFC/Reports/TR2002-01.pdf

Ashley Coolman

Ashley is a former Content Marketing Manager of Wrike. She specializes in social media, dry humor, and Oxford commas.

Related articles

The Cure for Project Failure (Infographic)

Are your projects thriving? Or are they suffering from swelling budgets, sluggish progress, and strained deadlines? If your hard work is constantly in danger of flatlining, know this: you’re certainly not alone. There’s an epidemic of failed projects afflicting businesses of all sizes, with organizations hemorrhaging hundreds of millions of dollars in lost funds. In the infographic below, we lay out the leading causes, tell-tale symptoms, and proven cures for project failure. Share our prescription for project success on social media, or post it to your own site with this embed code: Infographic brought to you by WrikeFor more insights into project management facts and figures, check out our Complete Collection of Project Management Statistics - 2015.

How 5 PM Experts Create a Fail-Safe Project Management Plan

Poor planning can doom your project before work even begins. Changing expectations, shrinking budgets, and frustrating miscommunications can derail even the simplest project—and make life stressful for everyone involved.  A thorough project plan can prevent scope creep, overblown budgets, and missed goals. But actually sitting down and planning a project can be an overwhelming task. How do you accurately predict how long tasks will take? How do you translate stakeholder expectations into concrete deliverables? What if something goes wrong? We’ve collected advice from 5 seasoned project management experts who understand exactly what's needed to create a successful project management plan.  Essential Components of a Project Management Plan  What should be included in your project management plan? For award-winning project management blogger Elizabeth Harrin, a thorough project plan includes these elements: Project Definition Statement: This is the ‘what’ and 'why' of your project: a short statement summarizing the purpose, goals, and final deliverable(s).  Execution Strategy: Explain the 'how' of your project. What methodology will you use? Will delivery happen in a single launch, or released in stages?  Scope: What is (and isn't) included in your project? Include your work breakdown structure and key deliverables.  Schedule: Depending on how well defined your project is, this can be either a high-level overview of when specific items will be completed, or it can include your detailed Gantt chart complete with milestones and delivery dates.  Organization Chart: An overview of the hierarchy of your project team, roles, and responsibilities. If your project involves multiple teams or departments, this should cover how those teams will work together, who the stakeholders are, and who’s leading each deliverable.   RACI Chart: This chart helps you determine specifically who will do what for your project. It's a matrix of all a project’s activities, paired with all the roles involved, including who's Responsible (assigned to complete the work), Accountable (has yes/no/veto power), Consulted (needs to approve or contribute), and Informed (needs to know about the action or decision). At each intersection of activity and role, a specific person is assigned for each role. Find out everything you need to know about RACI charts here.  Image Credit: racichart.org Risk Management Plan & Risk Log: Even if you budget every penny while learning how to calculate earned value and map out each milestone, no project, no matter how small, is free from risk. Create a plan for identifying and mitigating risk from the very beginning. Find a step-by-step guide to assessing and managing risk here.  Budget Details: Include projected overtime hours, training courses, consulting fees, equipment and supplies, software purchases, travel expenses, etc. Some of these figures can be tricky to nail down ahead of time but try to be as precise as possible, remind everyone that your budget is an estimate, and know how to calculate earned value to tell if you’re behind schedule or over budget on your project. Communications Plan & Reporting Schedule: Include details on who you’ll be communicating with, what you’ll share, how often, and in what form.  Procurement Plan: If you need to buy something as part of the project (software, materials, etc.) this is where you explain how you’ll research and choose a vendor and manage the contract. It's important to learn and implement good project procurement management strategies for this. Information Management Plan: Detail how you’ll store and share project information, control documentation, and keep your project data safe.  Quality Management Plan: Explain how you’ll manage quality on the project, what your quality standards are, and how you plan to maintain these standards, as well as your proposed schedule for quality audits or checkpoints.  This can seem like a lot of information to cover, but remember that this is just a project management plan example. A good project plan doesn’t necessarily include everything on this list.  As Harrin notes, “A longer document does not make you look more clever or organised. It just raises the likelihood that no one will read it except you.” A simple project plan that's easy to follow is best.  Start with a SOW According to Brad Egeland, experienced IT project manager, author, and consultant, the foundation of a successful project plan is a Statement of Work. Why? Because it gets everyone on the same page at the start. Later on, when new requirements pop up and scope creep sets in, you can go back to the SOW document to see what exactly the project was supposed to do at its inception. It is also important to be aware of scope creep and gold plating. Your SOW should include a general statement of purpose/business value, description of project deliverables, definition of milestones, estimation of effort, timeline, and cost, and a high-level description of team roles and responsibilities.  Set a Timer Max Wideman, famed project manager and co-author of the original PMBOK, advocates a streamlined method for project planning. His SCOPE-PAK Approach will help you knock out a project plan in 60 minutes or less (Wideman encourages you to actually set a timer). Assemble key stakeholders and team members to determine what you want to accomplish and how you’ll go about it.      Step 1: Stakeholders. Write down who should be contacted for help, information, or approvals, and define the project sponsor. If the list gets long, sort it into major and minor players.  Step 2: Components. This is your WBS. List all significant work items and suggestions (save evaluating them for later— just record them for now). Limit to 30 items, and if your team is starting to sound like they’re searching for items to add, stop this step and move on.  Step 3: Objectives & Outputs. Write down the project’s objective, then define what the output or results should be. Check your work by asking, “If we did all of the work items listed in Step 2, would we accomplish our objectives?" Step 4: Possible Alternatives. What alternatives would also satisfy the project’s objective? Is there a more effective way to accomplish your goals?  Step 5: Economics & Issues. What’s the project’s funding strategy? How is it prioritized among other projects? What resources will you need? What issues will you encounter?  Step 6: Plan of Attack. Look at your list of work items and decide which should be done first. Label that A. Then continue with B, C, D, etc. Then ask what can be done concurrently with A, or B, and so on. This is how you’ll establish the task schedule.  Step 7: Assumptions & Risks. What problems could occur with each task? How can you mitigate risks, or create workarounds?  Step 8: Key Success Indicators. Identify the 3-4 most important stakeholders, and ask, “What is most likely to make them happy?” These are the indicators for project success. Decide how each can be measured when the project is finished.  You can (and should) do further work to clarify the project work plan, but in just an hour you’ve established a solid plan of attack: identified stakeholders, clarified objectives, and defined outputs. Don't Overplan For Ricardo Vargas, an internationally renown project management specialist, a sense of urgency is the most important ingredient of a successful project. Project managers need to be able to respond to customer and stakeholder requests quickly, and that means executing, not sitting around a conference table hashing out timelines and budgets.  Your project isn't doing anyone any good on paper, so streamline the planning process as much as possible. Only include what's essential in your project plan, and then just get going!  Vargas uses a consolidated version of the planning guide outlined in the PMBoK, and you can learn more about the specifics of each aspect of his planning process on his blog.  Keep It Simple Project plans can get unwieldy fast, especially once stakeholders and project sponsors start weighing in. To ensure you're not over-complicating things, project management blogger Kiron Bondale suggests starting with the 5 Ws to provide context and perspective for the details of your project plan.  Why: What are the fundamental business benefits of undertaking this project?  What: What is included in the project scope?  Who: What are the critical roles required to deliver the What?  When: When must the What be delivered, in order to achieve the Why?  Where: Where is the best place for the work to be performed? Where will the What be used by customers and end users?  Only after you’ve stopped to answer these questions should you move on to the "How" of the project.  Project Management Planning Best Practices As you can see, even among project management experts there are a few different approaches to creating a project plan. There's no one right way, but one best practice experienced PMs agree on: take the time to define and agree on the main objectives with the project's stakeholders before you start executing.  Another best practice to follow: hold a project kickoff meeting. Take the opportunity to align your team around project goals, clarify roles and responsibilities, establish standards for success, and choose your project management methodology and tools. Get our tips for hosting the perfect project kickoff that will set the right tone for your team.  Finally: document as much as possible. Recording your project’s progress will help you analyze your performance and make more informed decisions.  More Project Planning Resources Project Management Basics: 6 Steps to a Foolproof Project Plan Essential Elements of the Perfect Project Plan (Infographic) 10 Steps to a Kickass Project Kickoff: A Checklist for Project Managers Project Management Basics: Beginner’s Guide to Gantt Charts Project Management Plan Template

7 Mission Critical Things to Consider When Building Your Project Plan

You’ve just been put in charge of a big project. Before it starts to spiral into chaos, you need to introduce some structure and order — fast. What you need is a project plan.

Get weekly updates in your inbox!

You are now subscribed to wrike news and updates.

Let us know what marketing emails you are interested in by updating your email preferences here .

Sorry, this content is unavailable due to your privacy settings. To view this content, click the “Cookie Preferences” button and accept Advertising Cookies there.

Denver's International Airport: A Case Study in Large Scale Infrastructure Development (A)

• Advocacy and Lobbying
• Government - State And Local
• Negotiation

Educator Access

A review copy of this case is available free of charge to educators and trainers. Please create an account or sign in to gain access to this material.

Permission to Reprint

Each purchase of this product entitles the buyer to one digital file and use. If you intend to distribute, teach, or share this item, you must purchase permission for each individual who will be given access. Learn more about purchasing permission to reprint .

Abstract: This case examines the political negotiations which paved the way for the construction of the first major new airport to be built in the United States in the past 20 years. The A case describes the negotiations which led to a memorandum of understanding between the affected governments; Part B carries the story through two annexation elections which finally succeeded in freeing the airport site for development. Learning Objective: By tracing the course of relations between Denver and its suburban communities as they worked to produce agreements allowing the airport to be built, the case is designed to facilitate discussion of the dynamics of city-suburban negotiations and strategies for forging compromise.

Other Details

Related cases.

Denver's International Airport: A Case Study in Large Scale Infrastructure Development (B)

Browse Course Material

Course info, instructors.

• Prof. Olivier de Weck
• Dr. James Lyneis
• Prof. Dan Braha

Departments

• Engineering Systems Division

As Taught In

• Project Management

Learning Resource Types

System project management, case studies.

HBS Case: 9–396–311, BAE Automated Systems (A): Denver International Airport Baggage-Handling System describes the events surrounding the construction of the BAE baggage-handling system at the Denver International Airport. It looks specifically at project management, including decisions regarding budget, scheduling, and the overall management structure. Also examines the airport’s attempt to work with a great number of outside contractors, including BAE, and coordinate them into a productive whole, while under considerable political pressures. Approaches the project from the point of view of BAE’s management, which struggles to fulfill its contract, work well with project management and other contractors, and deal with supply, scheduling, and engineering difficulties. Setting: Denver, CO; Construction industry; Engineering; 365 employees; 1989–1994.

Alternatively, we will discuss a “live” case based on BP’s emerging wind energy portfolio in North America.

HBS Case: 9–601–040, The Rise and Fall of Iridium Examines the history of Iridium Communications, a provider of mobile satellite services. Discusses the genesis of Iridium’s technical design, and then follows the venture through various stages of development. Describes Iridium’s attempts to build a subscriber base after the launch of commercial service, ending with the company’s filing for Chapter 11 in 1999.

HBS Case: 9–602–086, Microsoft.NET Set in the summer of 2000, following the unveiling of Microsoft’s .NET initiative to the public. Three of the key figures in .NET’s development are considering the next steps they would have to take to keep the initiative moving forward. Specifically, the challenges they face include the retirement of a key executive sponsor and the need to make major changes across many of Microsoft’s core products. The protagonists must come up with a process and an organizational structure to keep the initiative moving forward. Setting: Global; Software industry; $22.9 billion revenues; 14,000 employees; 2000. (Alternatively: Microsoft Office 2000 case)

You are leaving MIT OpenCourseWare

• Harvard Business School →
• Faculty & Research →
• April 1996 (Revised November 1996)
• HBS Case Collection

BAE Automated Systems (A): Denver International Airport Baggage-Handling System

• Format: Print
• | Language: English
• | Pages: 15

About The Author

Lynda M. Applegate

Related work.

• May 1996 (Revised October 2001)
• Faculty Research

BAE Automated Systems (B): Implementing the Denver International Airport Baggage-Handling System

• BAE Automated Systems (B): Implementing the Denver International Airport Baggage-Handling System  By: Lynda M. Applegate, H. James Nelson, Ramiro Montealegre and Carin-Isabel Knoop

Start typing and press Enter to search

• FREE WEBINARS
• FREE WEBINAR SCHEDULE
• HOW IT WORKS
• PRESENT A WEBINAR
• UNLIMITED COURSES
• SEARCH FOR COURSES
• WRITE A COURSE
• FOR ENGINEERING FIRMS
• FOR INDUSTRIAL MARKETERS
• STATE PDH REQUIREMENTS
• ZERO RISK GUARANTEE
• LIVE CREDIT REQUIREMENTS
• PDH KNOWLEDGE BASE
• NOONPI VS OTHERS
• INDUSTRIAL MARKETERS HOME

Lessons Learned: The Denver International Airport Automated Baggage-Handling System

The Denver International Airport (DIA) is renowned for its iconic tent-like structure, but it is also infamous in engineering and project management circles for its ambitious yet flawed automated baggage-handling system. This system, which was intended to revolutionize the airport industry, instead became a case study in the pitfalls of over-ambitious engineering and poor project management.

The automated baggage-handling system was designed in the early 1990s to be the jewel in DIA’s crown. It promised to use cutting-edge technology to transport luggage from check-in to aircraft with minimal human intervention, thereby increasing efficiency, reducing mishandled luggage, and improving passenger experience. However, the system never fully functioned as intended, leading to significant delays in the airport’s opening and substantial financial losses. There were many factors that led to the failure of the system.

Causal Factors

• Unproven Technology: The system was based on unproven technology that had never been used on such a large scale. The use of automated carts to transport luggage was a novel idea, but the technology was not mature enough to handle the complexity and volume of luggage at DIA. The carts often malfunctioned, leading to delays and lost luggage.
• Complexity: The system’s complexity was a major technical challenge. It was designed to handle 60,000 bags per day, with a network of 21 miles of conveyor belts and track, and hundreds of autonomous carts. The system was intended to use barcodes and radio frequency identification (RFID) tags to track and sort bags. However, the system often misread or failed to read the barcodes, leading to misrouted bags.
• System Integration: The system was designed to integrate with the airport’s other systems, such as check-in and flight scheduling. However, this integration was poorly executed, leading to further technical issues. For example, if a flight was delayed or rescheduled, the system often failed to update the baggage routing information, leading to bags being sent to the wrong planes.
• Capacity: The system was not designed to handle peak volumes of luggage. During peak times, the system was overwhelmed, leading to jams and delays. This was a fundamental design flaw that could not be easily fixed.
• Reliability: The system was plagued by reliability issues. The autonomous carts often collided or derailed, and the conveyor belts frequently jammed. These reliability issues led to frequent system shutdowns and contributed to the airport’s inability to open on schedule.
• Software Issues: The software controlling the system was also problematic. It was supposed to coordinate the movements of hundreds of carts and thousands of bags, but it often failed, leading to system-wide shutdowns. The software was also unable to effectively manage the system’s complexity and volume, leading to further technical issues.

The City of Denver had warning signs early on that were not heeded.

• Upon commencing airport construction, the city enlisted Breier Neidle Patrone Associates to assess the feasibility of the proposed baggage system project. The firm outright stated that the plan was overly complex. Nevertheless, the city chose to pursue the project despite the cautionary advice.
• Drawing from the experience of a similar, but simpler project in Munich, which took a full two years for completion and six months of rigorous 24/7 testing before launch, it became evident that the much larger and more intricate Denver International Airport system was being squeezed into an extremely tight two-year timeline. The Munich airport authorities warned that this approach was destined to fail. Despite these concerns, the City of Denver decided to press ahead without adjusting their schedule.
• When the airport invited bids for the new luggage system project, only three companies submitted proposals. None of these proposals projected completion within the given timeframe. Undeterred, the city rejected all three bids and approached a fourth company, BAE Systems, urging them to take on this nearly impossible project without extending the proposed timeline.

From a project management perspective, the baggage-handling system was a textbook example of scope creep and poor risk management. The project’s scope was expanded mid-way through construction to include all airlines, not just United, which dramatically increased its complexity. This decision was made without a thorough risk assessment or consideration of the additional resources and time required.

The failure led to significant financial losses. The airport opened in February, 1995, 16 months behind schedule with cost overruns estimated at $560 million, much of which was attributed to the baggage system. The system was eventually decommissioned in 2005, and a traditional manual system was installed in its place.

However, the failure also led to some positive changes in the industry—it highlighted the importance of thorough testing and risk management in large-scale projects, and spurred innovation in baggage handling technology, with a greater focus on reliability and scalability.

In conclusion, the failure of DIA’s automated baggage-handling system was a significant event in the history of airport engineering and project management. It serves as a stark reminder of the risks of over-ambitious engineering and poor project management. However, it also provides valuable lessons that can help prevent similar failures in the future. The key takeaways are the importance of thorough risk assessment, realistic project scope, adequate testing, and the careful implementation of new technology.

Related Posts

The Charles de Gaulle Airport Collapse

The Hindenburg Disaster

The Sinking of The Titanic

The one thing you missed is that the Scope Creep was likely do to upper-level people who were only looking for the praise that would come with as system that could do it all. Missing who the stockholders are is the fastest way to have a project fail. Often those who are told to make it happen, are not listened to. Failures of this type happen because those making the decisions are lacking the technical experience to make those decisions. This leads to Scope Creep and eventual project failure.

It was a political/politics/politicians failure.

It is not the first and will not be the last engineering failure event

Very interesting case. A system like this should have been installed in a smaller airport first. I think that governments should always spend capital money based on high level of assurances and not ambitions.

Reading the article I see that there were overruns in the area of $560 million dollars, however I wonder what were the direct costs attributed to the baggage handling system itself. As noted by Kamal above it sounds like the system should have been installed at a smaller airport first. Another option would have been going with known technology & having provisions for a cutting edge system to be installed / incorporated at a future date.

Yet Amazon probably does this on a larger scale on a daily basis in its distribution centers. Better design & planning? Using a system integrator who knows what they’re doing?

Unfortunately, politics and engineering make poor bedfellows…..

Leave A Comment

•      Tomball, TX 77375

Terms of Use | Privacy Policy

© Copyright 2022 - Gracone, LLC dba Professional Development Options, All Rights Reserved | NoonPi® is a registered service mark of Gracone, LLC | Continuing education courses and webinars offered on NoonPi.com are administered by and credits issued by Professional Development Options. More information

Why Do Projects Fail?

Denver airport baggage system case study.

Read the full case study – Denver International Airport Baggage Handling System case study – or read the abstract below.

Denver International

Originally billed as the most advanced system in the world, the baggage handling system at the new Denver International Airport was to become one of the most notorious examples of project failure.  Originally planned to automate the handling of baggage through the entire airport, the system proved to be far more complex than some had original believed.  The problems building the system resulted in the newly complete airport sitting idle for 16 months while engineers worked on getting the baggage system to work.

Denver Baggage Handling System

The delay added approximately $560M USD to the cost of the airport and became a feature article in Scientific American titled the Software’s Chronic Crisis.  At the end of the day, the system that was finally implemented was a shadow of what was originally planned.  Rather than integrating all three concourses into a single system, the system supported outbound flights on a single concourse only.  All other baggage was handled by a manual tug and trolley system that was hurriedly built when it became clear the automated system would never meet its goals.

Conveyor Belts

Even the portion of the system that was implemented never functioned properly and in Aug 2005 the system was scrapped altogether.  The $1M monthly cost to maintain the system was outweighing the value the remaining parts of the system offered and using a manual system actually cut costs.

Contributing factors as reported in the press : Underestimation of complexity.  Complex architecture.  Changes in requirements.  Underestimation of schedule and budget.  Dismissal of advice from experts.  Failure to build in backup or recovery process to handle situations in which part of the system failed.  The tendency of the system to enjoy eating people’s baggage.

Full case study : For more information read the following in-depth analysis – Denver International Airport Baggage Handling System case study

Related story : In Apr 2008 British Airways & British Airports Authority encountered serious problems when Heathrow’s Terminal 5 opened.  Again Baggage system glitches were a major contributor to the problem.

Reference links :

• MSNBC on Denver’s Automated Baggage System

Other case studies :

• US Census Bureau – Field Data Collection Automation project

• Testimonials
• Useful PM Blog
• Recent Projects
• Case Studies
• Agile Resources

• Packaged Services
• Initiation & Scheduling
• Agile Methods
• Project Recovery
• Courseware Development

The Denver International Airport Story or Everything You Ever Wanted To Know About How Not To Run A Project (final)

Project Management Expertise

As previously mentioned, the person in charge was in fact not a project manager at all but a Chief Engineer. Now, this is not to say that a technical person cannot manage a project. But I would argue that this is a classic case of the “accidental project manager,” or someone who is put into a PM position due to his or her success in a technical field. The problem very often is that the party gets no training whatsoever in project management other than “Here, read this book and good luck.” And I will aver that just because one is an engineer or a biochemist (or, like me, an IT guy), it does not automatically follow that one will have project management skills. And very often when people are put into this position they either are not offered help or, just as often, don’t ask for it. This may be because they don’t want to be seen as failing. And so onward they soldier, into the abyss.

Stakeholder Management

Clearly the airlines were key stakeholders in this process. And just as clearly they – or at least United – were inimical to the direction the project was taking. (The now-defunct Continental Airlines was downsizing and United was picking up their business. The literature isn’t clear on this but it appears that United was satisfied to stay at Stapleton. Part of the reason was in the newly deregulated environment, they did not want to increase costs). Classic PM theory says that you try to not only discover who the resistant stakeholders are but also find a way to bring them inside the tent. As noted in the Calleam case study, “BAE and the airport Project Management team made another major mistake during the negotiations. Although the airlines were key stakeholders in the system they were excluded from the discussions.” 3 I think it may be just as true to say that the airlines simply excluded themselves.

Regardless of how it happened, the airlines were not part of the decision making process. And then other stakeholders later cropped up such as hotel developers, FedEx, UPS all of whom had conflicting objectives. (It is the job of the project manager, team and – if there is one – sponsor to adjudicate these).

A partial list of other reasons for this fiasco might include: lack of risk management, embarrassment at not being able to complete a state-of-the-art public project; lack of true change management. And as noted, ineffective decision-making.

Reaction by the City of Denver

The City of Denver, in a letter to the General Accounting Office later said, “The airlines’ ( stakeholder ) resistance … to a large degree accounts for why so many changes occurred relatively late in the design construction process. The airline industry was reluctant to provide detailed facility requirements … while publicly opposing the project. ( Hostile stakeholder ). Due to lack of input, the city elected to move forward with “generic” solutions during the design development phase. …The result of this course of action was a number of late requests for changes made by the airlines once they realized the inevitability of the project.” 4 In other words, let’s start building it and then everyone will fall in line. No actually, if you ignore your stakeholders, they will come back and bite you twice as hard.

As mentioned above, DIA is open and has been for twenty years. And so was the project a success? Well, I guess that all depends on how you define it. If on-time, on-schedule were the criteria, then no. If getting it done ‘whenever’ and “for whatever it costs” are your criteria, then sure. ( I believe these were the criteria to build the pyramids ).

Oh, and the automated baggage handling system? Hung on for a number of years. And then in 2005, United announced it would abandon the system completely. And today – just like every other airport – they use a conveyor belt system.

• 1 . Case Study – Denver International Airport Baggage Handling System – An illustration of ineffectual decision making. Calleam Consulting Ltd
• Project Management, A Systems Approach, Harold Kerzner. P 648
• Denver Airport, Calleam Consulting Report
• United States General Accounting Office Report, Denver International Airport, September 1995, pp. 22 – 23

Comments are closed.

Connect with Us

Subscribe to blog, blog categories.

• Change management (3)
• Project Communications (5)
• Project Maturity (5)
• Project Risk Management (6)
• Project Scope (1)
• Stakeholder Management (1)
• Troubled Project Recovery (6)
• Why Projects Fail (14)
• Leadership & Interpersonal Skills (12)
• Sustainability (2)
• Project Scheduling (4)
• Training (3)
• Uncategorized (1)
• Updates (2)

Recent Blog Posts

• What makes a PMO successful? (Part Two)
• What makes a PMO successful? (Part One)
• Agile for Executives
• Initiation & Schedule Development
• Project Competency

Agile Collaborative

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

Enter the email address you signed up with and we'll email you a reset link.

• We're Hiring!
• Help Center

CASE STUDY ANALYSIS BAE Automated Systems (A): Denver International Airport Baggage-Handling System

Related Papers

Emmanuel Tyongbea

Jonathan Conway

Ramiro Montealegre , Mark Keil

Management Information Systems Quarterly

Ramiro Montealegre

huu quan hoang

Proceedings of the Information Systems …

Jacob L Cybulski

Journal of Air Transport Management

Richard Neufville

It & People

Jonny Holmstrom

martin de jesus paredes lucio