The pre-mortem: find the risk before it finds you

A post-mortem tells you why the project died. A pre-mortem does the same analysis while the patient is still alive and you can still save it.

Every team knows how to run a post-mortem. Something goes wrong, the project misses, and afterward everyone sits in a room and explains, with total clarity, exactly why it was always going to fail. The dependency nobody owned. The scope that kept creeping. The stakeholder everyone knew was going to change their mind. In hindsight, it's all so obvious.

Here's the maddening part. Most of that clarity existed before the project started. Someone in the room had a bad feeling about the dependency in week one. Someone suspected the scope was soft. They just didn't say it, or they said it once, quietly, and let it drop. So the post-mortem is really a list of things people could have flagged at the start and didn't. Which raises an obvious question: why do we only do this brilliant analysis after it's too late to matter?

The answer is a technique called a pre-mortem, and it's one of the highest-leverage things a delivery person can run. It takes about an hour, it costs nothing, and it's backed by some genuinely good research. If you take one practical tool from anything I write, this might be the one.

A post-mortem asks why it died. A pre-mortem asks the same question while you can still change the answer.

Why imagining failure works better than fearing it

The pre-mortem was popularized by research scientist Gary Klein, and the mechanism underneath it is the interesting part {Klein, HBR, 2007}. When you ask a team "what could go wrong with this project," you get a thin, careful list. People hedge. They don't want to sound negative, or doubt the plan in front of the person who made it. But when you change the question from "what might go wrong" to "imagine it's failed, now tell me why," something shifts in people's heads, and it's measurable.

There's a cognitive quirk called prospective hindsight: imagining that an event has already happened, rather than that it might happen, increases your ability to correctly identify the reasons for that outcome by about 30% {Mitchell, Russo & Pennington, 1989, via Klein, HBR, 2007}. Read that again, because it's the whole engine. Just switching from "could fail" to "has failed" makes people roughly a third better at naming the real causes. Certainty unlocks the brain in a way that possibility doesn't. The pre-mortem is simply a way to point that boosted power at your own project, at the one moment you can still do something about what it finds.

The research finding that makes the whole technique work. Assume it already failed, and people get about 30% better at naming why.

The second thing it fixes: the silence

There's a social problem the pre-mortem quietly solves, and it might matter even more than the cognitive one. Klein points out that projects fail so often partly because people are reluctant to voice their reservations during planning {Klein, HBR, 2007}. The junior engineer who can see the technical risk doesn't want to look like they're not a team player. The person who thinks the timeline is fantasy doesn't want to be the office pessimist in front of the sponsor who set it. So the doubts stay in people's heads, and everyone nods, and the plan sails out of the room with its worst flaws intact and unspoken.

A pre-mortem flips the social script completely. Now the assignment is to explain the failure. Naming risks isn't disloyalty anymore, it's literally the task everyone was asked to do. You've made it safe, even fun, to say the scary thing, because "here's why it died" is a game everyone's playing together instead of a criticism one person is bravely lodging. The quiet doubter with the most valuable information in the room finally has permission to put it on the table. That permission, more than anything, is what you're buying with the hour.

How to actually run one

It's simple, which is part of why it works. You do it once, at the start, before the plan is locked, while changing things is still cheap. Here's the whole thing.

The entire method. An hour before kickoff buys you the post-mortem you'd otherwise have written in six months, at a fraction of the price.

The two details that make or break it are worth calling out. First, the framing has to be certain, not conditional. Don't say "what might go wrong." Say "it's six months from now, this project has failed, it was a disaster, now tell me the story of how." The past tense is not a gimmick, it's the whole prospective-hindsight effect you just read about. Weaken it to "might" and you lose the thing that makes it work. Second, have people write their reasons down silently first, alone, before anyone speaks. This stops the highest-status or loudest person from anchoring the whole room, and it gets you the independent doubts instead of five people agreeing with the first thing said.

Then you go around the room, one reason each, and you keep going until every worry is out. You'll be surprised how fast the list gets real and specific. And then the part that actually matters: you take the top few most likely, most damaging failure modes, and you change the plan now to defend against them. A pre-mortem that just generates a scary list and gets filed is theatre. The point is that you turn the scariest reasons into concrete changes to how you're about to work, before you've spent a dollar or a day.

Where it earns its keep for a delivery person

For a Scrum Master, delivery lead, or PM, this is close to a superpower, and it's underused. You're often the person who can feel a project's risk but doesn't have the authority to just override the plan. The pre-mortem gives you a legitimate, structured, research-backed way to surface that risk without being the lone voice of doom. You're not saying "I think this will fail." You're facilitating an exercise that lets the whole team say it, together, which is far more powerful and far safer for you. It's leadership that looks like facilitation, which is exactly the kind of value that's easy to overlook and hard to replace.

It's also a fantastic interview story, if you've run one for real. "Tell me about a time you managed risk" is a common question, and most people answer it with a risk register nobody looked at. Answering it with "I ran a pre-mortem before a critical project, the team surfaced a dependency risk nobody had flagged in normal planning, and we restructured the first sprint around it and avoided a slip" sounds like someone senior, because it is what senior people do. If you've never run one, that's your homework: run a pre-mortem on the next real thing you're part of, even a small one, even a personal project. It's a genuine rep you can then speak to honestly.

The deepest reason to do it is a mindset one. Optimism is lovely and it's useless as a planning tool. The teams that deliver aren't the ones that believe hardest that everything will go fine. They're the ones that look, on purpose and early, at exactly how it could go wrong, and then quietly remove those failure modes one by one before they ever get the chance to happen. You don't have to be a pessimist to do this. You just have to be willing to spend one honest hour imagining the failure, so you don't have to spend six months living it. Find the risk before it finds you. It's cheaper every single time.