The other day, I was on a flight to an airport whose approach is known to be unpredictable. After we circled for a while (at least the scenery was nice), we had a smooth landing and taxied toward the gate. A few yards away from the gate, the engines flamed out, a sure sign that the fuel had run out. “Hmmm…,” I thought, but the plane rolled on its momentum and I felt the pilot slightly tap the brakes to stop precisely at the gate.
As I stood up to collect my luggage, the pilot excitedly announced over the intercom, “I just got this new app for my iPhone. It considers weather patterns, traffic patterns and dozens of other factors that I updated just before the flight. Then it calculates the exact amount of fuel needed for a trip. As you probably noticed, the app worked perfectly. We had just the right amount of fuel for the trip. Do you have any idea how much money we can save by not flying around with excess fuel? Is this not great?”
My “Hmmm…” suddenly morphed into a “Yikes!” With that kind of optimization, I wondered, just exactly how many more airport circlings had been left in the tank?
As potentially scary as that scenario sounds, that’s often how we manage our IT projects. We often don’t want to know about risks or consider unpleasant surprises or contingencies. In times of tight budgets and short timelines, anything that increases the estimated budget can make the difference between go or no-go for a project. We pressure the people proposing a project for the bare-minimum numbers, which increases not only stress but also the likelihood of failure. Failed projects seldom provide a footnote referencing unreasonable demands placed on people or technology, and subsequent projects often suffer from legacy expectations that roll forward.
Even worse, this is how we approach our vendors: “We’re hiring you because you claim you know what you’re doing. So don’t talk to me about risk.” Actually, selecting the right vendor can make a huge difference in mitigating risk. It’s not as much about certainty as about awareness that the more the vendor knows, the more they know about what can go wrong—and we all know that Murphy was an optimist.
Proper risk management requires a project manager who has been there and done that. A good project manager provides a realistic perspective when determining what’s required to bring a project in for a safe landing, including examining hidden issues that might be uncomfortable to discuss. Only by carefully collecting and considering as many factors as possible that can affect success can the project manager recommend a strategy to mitigate risk. And so far, there’s no app for that.
Latest posts by Thomas Koehler (see all)
- How to Avoid Project Failure of Titanic Proportions - February 27, 2014
- What is a Deliverable-Oriented Work Breakdown Structure? - January 30, 2014
- Project Parachutes: Risk Management Can Save Your Life - January 17, 2014