The folks that designed Denver International Airport’s infamous baggage handling system can breathe a bit easier now. While the much publicized start-up disasters at Denver have faded into the past, apparently the project management lessons learned did not transfer across the pond to the teams responsible for the new Terminal 5 at London’s Heathrow Airport.
In an article by Bloomberg in the Chicago Tribune (Heathrow Delays Foretold in Tests), it is reported that delayed baggage and employee confusion and lack of training have resulted in the cancellation of more than 600 flights and the stranding of thousands of passengers since the terminal opened on March 27.
As the scope and complexity of fixing the problems at Terminal 5 grows, additional reports show the sacking of two BAA executives, estimates of lost revenue currently at 16 million pounds and early indications that the total fix may cost upwards of $299 million U.S. Last but not least, all of the other airlines planning to move into vacated BAA terminal slots starting in April are now delayed indefinitely. It is expected that those airlines will seek compensation from BAA.
While I have no detailed insight into where this project went awry, from some of the comments coming out from the growing list of stranded passengers, we can surmise that some combination of system complexity and lack of proper staff training are primary culprits. The Bloomberg article quotes one of the early test passengers as follows; "They just weren’t ready to deal with the number of passengers. It seemed the staff didn’t really know what was going on."
The Chief Executive of British Airways, Willie Walsh, blamed the situation on a series of "simple and silly things," including parking lot delays and just four days of staff training. Art’s comment: Hmmm. Hey Willie, it’s your job to not let "simple and silly things" get in the way of delivering the bare minimum to your clients: safe, reliable and timely transportation of people and baggage. That’s your business. Your team failed. You failed. It’s not simple or silly.
Regardless of the specifics, the fact is that the Project Management system and approach failed to anticipate and mitigate these industry-shaking, company impacting problems. Somewhere in the drive to hit a date, corners were cut, sacrifices were made and hope was employed as a key part of the project strategy.
Here are a few thoughts on my own lessons learned from too much time in and around companies creating their own project disasters.
- Beware the irrational optimism of top management asserting dates and expecting the project realities to bend to their force of will. While there is a time and place for setting stretch goals, when the Project Managers are saying "It’s not possible" and the executives refuse to hear them, expect trouble.
- It is foolish to minimize or trivialize the human component in fielding a new system. Designers and engineers convince themselves that their invention will work as planned, but often forget that the people using their creation are not fellow engineers. When deploying a new customer-focused system, it is foolhardy to skimp on training, testing and dry-runs. Restaurant chains rolling out new technology to accelerate order-taking and accuracy have this down to a science. Perhaps the Executives at BAA should spend some time at McDonald’s.
- Risk analysis and mitigation? You can hardly over-plan for what might go wrong, especially when your business and corporate credibility are on the line.
- The Project Sponsor is responsible. We’ll likely never know what role politics played in the Terminal 5 fiasco, but the Project Sponsor should not have let the terminal open without being confident in the outcome. And while no one would have been happy with a delay, the discomfort of an announcement and some minor bad press pales in comparison to the impact of going live prematurely. Who didn’t speak up? Or worse yet, who didn’t listen? (A sad example of politics and not listening is the space shuttle Challenger disaster. )
- A client does not want to hear about "Simple and Silly" from the top executive of the company that just grossly inconvenienced them. It’s time for Willie to look up empathy and learn how to talk with customers and take some PR lessons from the executives at Johnson & Johnson.
- Build in quality to the project plan? As evidenced by most experiences on airlines recently, "quality" is not a word that jumps to mind. Nonetheless, hope springs eternal. Building in quality is of course table-stakes for good project planning.
The bottom-line:
I have no doubt that the Terminal 5 project is ambitious, pioneering and complex. Nonetheless, that does not excuse the poor outcome. Perhaps over time this terminal will be a global showcase for best practices in customer and baggage handling, but from this vantage point, it looks like a big debacle that could have been mitigated by some effective Project Management work. Based on the early reports, the Terminal 5 Case will be something that Project Managers and Public Relations professionals will be studying for years to come.
Art, I’d love to know what the “four days of staff training” included. My suspicion is that a lot of it was someone telling people about the new system. Which is fine, if the objective is “tell people” rather than “have people handle baggage successfully with the new system.”
You say, “when deploying a new customer-focused system, it is foolhardy to skimp on training, testing and dry-runs.” I couldn’t agree more — but how many large software systems have you seen that included a robust training mode?
For example, Amtrak’s ARROW reservation system included a series of “training trains” — fictional trains (based on actual routes) allowing any user of the system to practice any commands his access allowed. A separate training ID meant that someone practicing how to reserve space wouldn’t accidentally tie up real accommodations, but would be able to experiment, rehearse, and create practice reservations identical in every way to live ones.
Time and again, though, I’ve seen large, critical projects that had “too much to do” to allow for this invaluable kind of support. Thus a banking system used by tellers and branch officers provided no way to practice such things as opening an account — you had to open an actual one, then cancel it. Not only counter-intuitive, but the cancellation data entered the stream of (theoretically) current transactions.
No doubt at headquarters, someone decided the branches needed “training” in how to avoid cancelling so many new accounts.
Have a read of Michael Krigsman’s analysis of the failure: http://blogs.zdnet.com/projectfailures/?p=681