In Parts 1 and 2 of this series, we covered why projects fail and how to investigate these catastrophes, all under the guise of being an air crash investigator. In this final installment of the series (inspired by my binge viewing of all 16 seasons of “Mayday: Air Crash Investigation“), we will look at ways to move forward from failure and prepare a takeoff to project success.
The worse thing that can happen to any project manager, even more than a flat-out failure of any given project, is to not understand what caused the failure in the first place and to be left without a plan to do better the next time around. Take, for example, Malaysia Airlines Flight 370, a flight that went missing soon after departure from Kuala Lumpur, and whose demise is still not known after almost two years of investigation and speculation.
How horrible for the families and friends of passengers and crew — and how frustrating for those responsible for the flight safety of the hundreds of other Boeing 777s flying around the globe today. Not knowing what went wrong is probably the worst possible outcome.
Read Part 1 of “Mayday! Project Crash Investigation,” here.
Read Part 2 of “Mayday! Project Crash Investigation,” here.
As a project manager with a few failures under his belt, I can confirm that not knowing precisely why a project failed makes it that much harder to work confidently on the next; and, conversely, understanding precisely the problems a failed project had makes working on the next like-project much more enjoyable.
One could say that just knowing that large projects do fail (at an average of one in three, industry-wide), and that hard data can be used to prevent the same mistakes from happening again — that’s liberating in itself, at least from a psychological perspective!
In part 1 of this series, I covered a few tools — lessons learned, risk management — commonly used to turn past mistakes into future success stories. But in my experiences as a project manager, I’ve seen all too often how in the heat of the moment, any lessons learned from the past are thrown to the wind in order to bring a project in on time and under budget. Likewise, I’ve seen risk management plans that may have been created in a vacuum, ignored until the last minute, until it was too late. For example, just last year here in Nepal, an earthquake that registered 7.9 on the Richter scale threw most projects into a tizzy, with some never to recover.
I’ll never forget how many disaster recovery plans were in place (many of which I helped draft), with not a one of them having a personal tent in-plan, but all having a go-bag with a toothbrush and clean underwear included. And in my case, my go-bag was trapped in rubble, while I slept outside under a shared and leaking tarp in the rain. Well, there are some lessons learned that you can never forget…
Outside of traditional tools — and terrifying experiences — what can we do to further ensure project success as we move forward?
Prepare for Success by Studying Failure
One idea is to study project failures with preparedness in mind. As mentioned in Part 2 of this series, there’s a great website devoted to just that philosophy. I recommend that every project manager give the International Project Power Skills Academy a good read. The pages on “Classic Mistakes” is, well, classic. There are 10 classic mistakes listed (with each of the mistakes illustrated by a failed project or two):
- The underestimation of complexity, cost and/or schedule;
- Failure to establish appropriate control over requirements and/or scope;
- Lack of communications;
- Failure to engage stakeholders;
- Failure to address culture change issues;
- Lack of oversight/poor project management;
- Poor quality workmanship;
- Lack of risk management;
- Failure to understand or address system performance requirements; and
- Poorly planned/managed transitions.
In the “catalogue of catastrophes” found on that site, my favorite, if it can be called that, is the St Helena Airport project, funded by United Kingdom’s Department for International Development to the tune of $373 million USD. An airport was built where the intended aircraft (large jumbos) couldn’t land. The reason? The wind. The result: a project near useless for its intended purpose.
Wind shear is so strong on this remote island, no airline would dare risk flying their passengers in. To make matters worse, the strong wind shear was a well-known factor, but unheeded by the project developers, who ignored expert advice and failed to catalog the windy terrain as a risk — so the airport was built, but now stands unused by any large commercial jets.
One could say that the above classic mistakes 3, 4, 8 and 9 were made. From personal experience, I can also say that number 5 was also partially to blame, as the Department has a somewhat rigid culture of “We know best.”
Try Something New…
I’ve come to the conclusion that traditional tools and mythologies for learning from the past or planning for future risks is just not working out for us. Something new must be considered.
Consider the success of the airline industry, where, if a project failure is defined as “a flight with at least one death,” the industry’s failure rate stands at just 0.00003 percent — in other words, a near-perfect success rate. Compare that to the project failure rate of 33 percent.
Why don’t we do what the airline industry has done? Let’s set up a project safety board (akin to the National Transportation Safety Board) that catalogs all project failures after a thorough investigation. Ha! I can hear you groaning now. Who would be first in line to make all of their failures public? No one, of course, but each organization could at least have its own board of experienced investigators, backed up by hard data that shows cause for everything that has ever gone wrong, right?
Other variations on this project safety board theme:
- Hire a consultant to dig out the causes of past project failure and make that data available in a private, secure, enterprise-wide database.
- Have a lead project manager or monitoring & evaluation person be responsible.
- Take it upon yourself — wherever you are in the hierarchy of your organization — to do the same and get the effort started.
Building a database of project crashes and causes won’t be that hard, especially for those using Microsoft Project and other tools that collect project metrics (see the “Project Manager’s Flight Data Recorder” discussion in Part 2 of this series). I suspect there is even a programmer or two out there in our project management universe that could build an analytics tool to help us do just that.
Sure, none of us likes to delve into our blunders, mistakes and failures. But we have to remember what Henry Ford and others like him have said a hundred times over: “Even a mistake may turn out to be the one thing necessary to a worthwhile achievement.”
