Want to Cancel a Project Early?
There are times when it simply makes sense to cancel a project early. It may be that the organization’s priorities have changed or the project has become unfeasible. Or, it could be that the project is no longer contributing any business value to the organization’s project portfolio. Many dollars have been lost on projects that should never have been initiated, have not gone well in the planning stage, or performed so poorly that canceling early would have been less costly. In this blog, I discuss four lessons from the legendary Denver Airport baggage handling system project.
This project was undertaken in late 1989 to build an integrated baggage handling system for a brand-new airport in Denver, Colorado. The airport opened sixteen months late with only a fraction of the new system working. In mid-2005, the entire system was scrapped in favor of a manual system, after spending more than $600M. Many people have written about this project. I’ll use it as a case study on when to cancel a project early. A project team is never in a position to actually cancel a project, but it can make those recommendations.
Executives with strong emotional commitments to a project can often be biased. Those around them, including the project team, may need to make compelling arguments in favor of cancellation. Here are four lessons from the Denver project specifically related to when to cancel a project early.
1. Seriously consider cancelling when the experts are repeatedly telling you that it can’t be done.
A highly specialized consulting group, Breier Neidle Patrone Associates, was hired about three years before the projected airport opening to do a feasibility analysis on building an integrated baggage system. At this point, work had been underway for a year. As experts in this field, BNP said that the system could not be successfully built. Yet, leadership ignored the experts and continued.
A year later, with less than two years remaining before the airport was scheduled to open, leadership contracted with BAE to build an integrated system. This was done, despite the knowledge that a much simpler system took officials in Munich two and a half years to build and test. Again, now two years into the project, the team is still ignoring expert advice.
Of note is this major problem in building an integrated baggage system. How do you predict customer usage so that luggage carts were where they were most needed when they were needed? Understanding complexity in the planning process is essential. This problem combined the difficulty of analyzing the structural build process with predicting human behavior. The team ignored expert advice that this project was too complex.
2. When significant strategy changes are made by executives well into a project, consider whether you should move forward.
The original goal of the airport project was to build one of the most efficient airports in the world. Under this overarching goal, the question was always how to build an efficient baggage handling system. But from the outset the team failed to properly address the question of who was going to own the baggage handling system. Was it the airport or the airlines?
And two years into the project, the strategy was changed, and ownership was moved to the airport so that an integrated system could be built. This may have been the correct strategy but the change, so late in the game, positioned this project for failure.
3. Consider cancelling when you realize well into a project that you missed a major assumption which turned out to be flawed or when the timeline is clearly impossible.
First, on the assumption: historically, baggage systems had been developed by individual airlines. The project management team assumed that would continue. Several airlines began building their own systems long before this project was really up and running. It took almost two years for the project management team to recognize that their assumption was flawed. Project teams need to document assumptions and test them. Part of the problem is that understanding assumptions requires that people really sit back and think.
Remember the need to identify assumptions during project initiation and test them before proceeding.
And now, on the timeline: consider that by the time the contract with BAE had been hammered out, the projected opening was eighteen months away. Everyone knew, or should have known, that the timeline was impossible. And since the airport could not open without a baggage handling system, that became the key item on the critical path. And yet, the project continued.
Remember the need to identify assumptions during project initiation and test them before proceeding.
4. Be very cautious when massively expensive executive decisions are made unilaterally.
In the Denver case, one of the biggest decisions was made by Walter Slinger, the airport’s Chief Engineer. He was also in charge of all airport operations and so, was not devoted to this project full-time. Slinger was very experienced in airport engineering. According to reports, he was a hands-on manager who liked to solve his own problems. But he had no experience with an integrated baggage system. No one did. It was the first one of its kind. And when complexities surfaced, no one was able to fully grasp the impact.
Slinger was the point man for all discussions with BAE. But important stakeholders, such as the airlines, were often left out of these discussions. Slinger’s contact at BAE was obviously interested in selling this system and then, being able to sell it to other major airports. And Slinger badly wanted to successfully launch the first-ever integrated baggage handling system, that had been his baby from the beginning. So, when BAE built a prototype, Slinger’s confidence grew and he ignored the clearly impossible timeline.
After Slinger’s death, his replacement didn’t have his depth of knowledge. Soon, electrical supply issues and resulting part insufficiencies caused testing delays. Finally, an impromptu and disastrous media demonstration brought the Mayor into the equation and an outside consultant was hired. But this was six months after the airport was to have initially opened — too little and too late.
On a project of this size, independent reviews should be completed throughout the project. Certainly, an outside team should have reviewed the proposal and prototype before Slinger unilaterally decided to move forward.
So, why is it so hard to cancel a project early?
There is no question that once a contract has been signed, other complications arise that make it more difficult to cancel a project. But these lessons were all pretty obvious before the BAE contract was signed. So why did it go forward?
According to a 2017 article by Michael O’Brochta, titled Why Bad Projects are So Hard to Kill, many IT projects are kept alive long after they should have been cancelled. Among the contributing factors were groupthink, sunk costs, and a natural inclination to feel accountable and responsible. There is little question that Slinger felt that responsibility. Research done by T. Liang & N. Yen (2016) “suggests that these behaviors are rooted deep within the neural science of our brains.” So, as project managers, sponsors, and teams, we need to understand these natural biases and call out these behaviors.
If you or your team are too close to a project that is falling behind and need an outside opinion, schedule a call.
[Note: The primary reference for this blog was the 2008 Denver Airport Baggage Handling System Case Study by Calleam Consulting, LLC.]
