Generating Lessons From Project Failure

Failure is inevitable. No one is perfect, no method is foolproof, and nobody achieves a perfect success rate. Most people are afraid of failing. But failure is important. Failure is the ultimate feedback, the definitive “you need to do that differently,” and the best lesson towards achieving success you can get. Project failure is no different. Whether you are focused on your project management career, or achieving the goal of the project, failing is an important part of learning how to succeed. They key is to generate the right lessons to learn from your project failure. How do you do that?

Break Down The Project Failure

Start at the beginning. What failed? How? Why?


You’d be surprised how many answers this can have! In your postmortem meeting with the team, bring this question up. See how many different answers people provide.

Sometimes the failure is easy to identify – the funding was too small to achieve the project aims. Or the project sponsor wasn’t serious about getting to delivery. Or perhaps the vendor suddenly went bankrupt and you had no warning or time to change plans.

Don’t settle for simple explanations, though. Even when they’re correct. Maybe there’s more than one reason the project failed. Perhaps the simple reason you’ve identified as the cause for project failure is itself caused by something else. A proper postmortem meeting is thorough. It combs through everything, analyzing and sifting the data until the causes are clear.

Take the final example above: Could a proper risk management plan have foreseen the vendor bankruptcy? How was the risk plan put together? Maybe the more accurate cause of project failure isn’t the vendor bankruptcy, but your risk plan.

How To Analyze Causes of Project Failure

In order to identify the right causes of project failure, you need to make sure the cause you’re identifying is the right one. Ask yourself, and your team – “Could this have been prevented?” If the answer is yes, it’s a good sign the actual cause of failure is not the data point you’re looking at, but whatever was not done behind it to prevent the problem from occurring. If the answer is no, you need to ask “Why couldn’t this have been prevented?” Explore the counterfactuals. Ask “what if?” constantly. When you can’t ask those questions anymore, you just may have found your culprit.

team analyzing
Having your team help with breaking down project failure is crucial to avoid making excuses

This kind of critical analysis can often lead to false positives, so beware. Once you have your suspect, you need to test if it is actually the root cause of project failure. “If this one variable was different, how would that have changed the project?” This is a hard question to answer. So much of it is conjecture. Having the team take part in this is crucial, or you might just talk yourself into an excuse. You might feel better about your project failure, but you aren’t going to learn the right lesson.

What Would I Do Differently?

Okay, you’ve identified the cause of the project failure. How does this inform your project management strategy for the future? What did you learn from this mistake? This is not an easy question to answer, and the answer can change over time. Your experience is like a library – sometimes re-reading a book gives you a deeper insight into something. Sometimes thinking about your past experiences opens up new vistas into your current condition, too. Experiencing a project failure, and breaking down its causes, gives you actionable insight – provided you ask yourself the right questions.

The first one is, “What would I do differently, in hindsight?” Now that you know what you know, what would you differently? The second question is “Why?” The answer to “why” is the lesson you learned. But which “why” is important.

Use Occam’s Razor here, liberally. Keep asking “why.” If your original answer to what you’d do differently is “task the vendor selection to someone else,” ask why. If the answer to that is “because Harold was thoroughly unsuited for the task,” ask why. If the answer to that is “Harold had no previous experience with vendor selection,” you’re on the right path – “why is previous experience important?” Eventually, you will get to a concrete, actionable, sound bite sized lesson.

Occam's Razor
Occam’s Razor – Is there something left to cut?

In our example, it might be “You can’t build the right risk model for vendor selection without knowing the possibilities for what may go wrong.” Or “delegating tasks effectively includes tailoring tasks to the team member assigned to them” – and that is the key insight you’re looking for, for the future.

Your Little Book of Rules

In the hit TV show “NCIS,” the main character, Gibbs, has a list of rules he lives by. He has learned these rules from his experiences. It is a calling card of the show. You should keep track of your rules you learn from project failure (and successes!). Your lessons you’ve learned are yours to keep, after all. Ignoring them will only make you repeat the same mistakes.

Ultimately, when it comes to your list of rules, Gibbs’ Rule #51 is a good one to remember – sometimes you’re wrong. Remember the library metaphor above – revisit your lessons and conclusions constantly. You might discover what you thought wasn’t accurate. And there are better lessons to learn.