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.
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.