The Pre-Mortem Technique for Better Planning

Every engineering team does post-mortems. Something breaks, you gather the team, you figure out what went wrong, you write action items, and you promise to do better. Then something else breaks.

What if you ran the post-mortem before the project started?

That's a pre-mortem. And after using it for three years, I believe it's the single most valuable planning technique available to engineering teams.

How It Works

The technique was developed by psychologist Gary Klein. The setup is deceptively simple:

1. Gather the team at the start of a project.
2. Say: "Imagine it's six months from now. This project was a complete disaster. What happened?"
3. Everyone writes down their answers independently (critical -- no groupthink).
4. Share and discuss.
5. For each plausible failure mode, decide: prevent, mitigate, or accept the risk.

That's it. Thirty minutes. The results are consistently better than any formal risk assessment I've seen.

Why It Works Better Than "What Could Go Wrong?"

You might think a pre-mortem is just asking "what could go wrong?" in fancier language. It's not. The framing difference is psychologically significant.

When you ask "what could go wrong?", people are in advocacy mode. The project has been proposed, maybe approved. Raising concerns feels like opposition. People self-censor. They hedge: "Well, maybe, possibly, there's a small chance..."

When you say "this project already failed", the dynamic flips. You're not predicting failure -- you're explaining it. People become forensic investigators rather than pessimists. The answers are more specific, more honest, and more actionable.

Klein's research found that pre-mortems increase the ability to identify reasons for future outcomes by 30%. In my experience, the improvement is even larger because the technique surfaces the things people were too polite or too cautious to say.

A Real Example

Last year, my team was planning a migration from a monolithic API to a set of microservices. Ambitious timeline: four months. I ran a pre-mortem at the kickoff.

Answers that came back:

• "We underestimated how many undocumented dependencies exist between modules. The first service we extracted broke three other services in ways we didn't predict."
• "The team got pulled onto an urgent customer project for six weeks in the middle of the migration, and we lost momentum."
• "We didn't have a clear rollback plan. When the new services had performance issues, we couldn't go back to the monolith because we'd already started decommissioning it."
• "Authentication and authorization were handled differently in each service, and we didn't realize this until integration testing."
• "The senior engineer who understood the monolith best left the company in month two."

Every one of these was plausible. Several had happened on previous projects. And here's the key: none of them showed up in our original project plan. The plan focused on what we would build. The pre-mortem revealed how we would fail.

What We Did With the Results

Each failure mode got one of three treatments:

Prevent: We spent two weeks documenting all cross-module dependencies before extracting anything. This added time upfront but prevented the "undocumented dependencies" failure mode.

Mitigate: We couldn't prevent people from leaving or urgent projects from appearing. But we could mitigate by having two engineers paired on every service extraction (knowledge redundancy) and by building a complete rollback path before starting each phase.

Accept: We accepted that the timeline would likely slip and communicated this to stakeholders proactively, with the pre-mortem findings as justification.

The migration took five months instead of four. Without the pre-mortem, I'm confident it would have taken eight or more -- if it succeeded at all.

Running a Good Pre-Mortem

Timing: At the very beginning of a project, before plans are finalized. If plans are already locked, people will be less candid about flaws.

Independence: Give people 5-10 minutes to write answers silently before sharing. This prevents anchoring bias where the first speaker's answer shapes everyone else's thinking.

Inclusion: Everyone on the team participates, regardless of seniority. Junior engineers often spot risks that senior engineers have become blind to. QA, design, and product people catch things engineers miss.

Specificity: "Something might go wrong with the database" is not useful. "We'll underestimate the data migration time because the legacy schema has undocumented nullable fields that break our new validation" is useful. Push for specifics.

No judgment: The point is to surface concerns, not to evaluate them. "That won't happen" kills the exercise. Write everything down first, then evaluate likelihood and impact.

Beyond Project Planning

I've started using pre-mortems for all kinds of decisions:

Before joining a company: "It's two years from now, and joining this company was a terrible decision. What happened?"

Before a difficult conversation: "This conversation went badly. What did I say wrong?"

Before a product launch: "The launch was a disaster. Customers hated it. Why?"

Before a hiring decision: "This hire didn't work out. What did we miss?"

The technique works for any decision with meaningful consequences and genuine uncertainty. I've found it pairs well with the scenario-thinking approaches collected at KeepRule's scenarios section, which provides structured frameworks for stress-testing decisions against different possible futures.

Common Mistakes

Running it too late: If the plan is already approved and the budget allocated, the pre-mortem becomes performative. People won't name risks that could derail an already-committed project.

Not acting on the findings: A pre-mortem that produces a list of risks that nobody acts on is worse than no pre-mortem at all. It signals that risk identification is theater.

Doing it alone: A pre-mortem in your own head is useful but limited. The power comes from diverse perspectives seeing different failure modes.

Conflating with brainstorming: A pre-mortem is not "let's think of everything that could go wrong." It's a specific cognitive exercise: imagine failure has already happened and explain it. The distinction matters for the quality of output.

The Meta-Benefit

Beyond the specific risks it identifies, the pre-mortem creates a shared mental model of what failure looks like. This is surprisingly valuable during execution. When someone sees an early signal that matches a pre-mortem scenario, they speak up faster because the team has already acknowledged that failure mode as plausible.

It changes the project's immune system. Instead of ignoring early warning signs, the team is primed to detect them.

Thirty minutes at the start of a project. That's the investment. The returns compound for the entire duration.