Pre-Mortem: Gary Klein's Technique for Spotting Project Failure Early

By Tara Minh · Updated Oct 10, 2026

A pre-mortem is a risk exercise run before a project starts. The team assumes the project has already failed, then each person writes down the reasons it went wrong. Psychologist Gary Klein described the method in Harvard Business Review in 2007. It surfaces doubts that people usually keep to themselves.

Key Facts

• Gary Klein described the premortem in "Performing a Project Premortem", Harvard Business Review, September 2007: team members assume the project has just failed, then generate plausible reasons why.
• The idea rests on "prospective hindsight," studied by Mitchell, Russo and Pennington in 1989. Their study found that imagining an event has already happened increased the number of reasons people generated for the outcome by about 30%, according to this review of the research.
• A 2010 study of 178 university students (Veinott and colleagues) found that imagining a plan had already failed reduced confidence in it more than pros-and-cons methods did, per the same review.
• A pre-mortem works best after the plan exists and before money, people, and public commitments are locked in. One session usually takes 30 to 60 minutes.

What is a pre-mortem?

Most risk sessions ask, "What could go wrong?" The pre-mortem asks something different: "It's twelve months from now. The project failed badly. What happened?" That small change in framing matters. People stop defending the plan and start explaining a failure that, in the exercise, is already a fact.

The name plays on the medical post-mortem, which examines why a patient died after the fact. A pre-mortem does the autopsy in advance, while there's still time to change the outcome.

Klein's HBR article describes the setup plainly: the team members assume the project they're planning has just failed, and then generate plausible reasons for that failure. He also argued that the exercise makes it safe for knowledgeable people to voice concerns that would otherwise feel like disloyalty. If you've ever sat in a kickoff where everyone nodded and three people privately doubted the date, you know the gap this closes.

Why prospective hindsight works

Researchers call the underlying effect prospective hindsight: picturing a future event as if it has already happened. When an outcome is treated as certain, the mind stops asking "if" and starts building the story of "how."

The 1989 paper by Deborah Mitchell, Jay Russo and Nancy Pennington is the research usually cited for this. A review of that work reports that treating an event as already having occurred raised the number of reasons people generated by about 30%. It also notes the authors didn't assess how good those reasons were. So the safe takeaway is "more reasons, faster," not "30% more accurate." That's still valuable, because the risk you never name is the one you can't plan for.

There are two other forces at work:

• Social permission. In a normal planning meeting, raising a flaw can sound like criticism of the person who wrote the plan. In a pre-mortem, finding flaws is the assignment.
• Reduced overconfidence. The 2010 study mentioned above found that imagining failure lowered confidence in a plan more than listing pros and cons did. Lower, more realistic confidence is the goal, since it's what pushes teams to add buffers and contingencies.

Pre-mortem vs. other project risk techniques

The pre-mortem doesn't replace your other tools. It feeds them. Here's how it compares with the techniques it's most often confused with.

A good rule: use the pre-mortem to discover risks, the risk matrix to rank them, and the risk register to track them. For the wider discipline these tools belong to, see project risk management.

When to run a pre-mortem

Run one when a plan is detailed enough to critique but still cheap to change. Common moments:

• Right after the project charter is approved and before the kickoff
• At the project kickoff meeting, as a standing agenda item
• Before a go/no-go decision on a large purchase, migration, or launch
• At the start of a new phase when the plan has changed materially

Skip it for tiny tasks. And don't run one after the decision is irreversible, because the team will treat it as a formality.

How to run a pre-mortem: step by step

A 45-minute session works for most teams of 5 to 12 people. Larger groups can split into smaller tables and merge the lists.

Step 1: Brief the team on the plan

Share the plan, scope, timeline, and success definition. Everyone must be critiquing the same thing. Keep this to 5 or 10 minutes, and don't defend the plan while presenting it.

Step 2: Set the failure scenario

Pick a specific date and a vivid result. "It's March 2027. The launch missed its date by four months, the budget is gone, and the sponsor has pulled support." Specific beats vague. The more concrete the failure, the more concrete the causes people produce.

Step 3: Write reasons silently and alone

Give everyone five to ten minutes to write down why the project failed, with no talking. Individual writing matters because group discussion pulls people toward the loudest voice or the most senior opinion. Ask for one cause per sticky note or line.

Step 4: Share the reasons round-robin

Go around the room and have each person read out one reason at a time until the lists are exhausted. Don't debate yet. Capture everything on a shared board. Juniors and newcomers often name the risks everyone else has stopped noticing.

Step 5: Group and vote

Cluster similar causes: people, scope, technology, budget, dependencies, external factors. Then have each person vote on the causes they think are most likely or most damaging. Dot voting takes five minutes and keeps the loudest risk from winning by default.

Step 6: Turn top risks into actions

For the top five to eight clusters, decide what you'll do now. Each one needs one of four responses:

1. Prevent it by changing the plan
2. Reduce it with a buffer, a test, or a second supplier
3. Prepare a contingency trigger ("if the vendor misses the first milestone, we switch")
4. Accept it knowingly, with a named owner

Step 7: Log and revisit

Move the risks into your risk register or a RAID log with owners and dates. Put a 15-minute pre-mortem check on the calendar at the project's midpoint. Risks from the first session often change shape once work is underway.

Pre-mortem template

Copy this into a doc or spreadsheet. Fill the first block before the session and the table during it.

Session header

Failure causes and responses

Follow-up

Pre-mortem examples by business function

The technique isn't limited to project managers. Here's how the failure statements look across functions.

Each row starts with a plain, one-sentence failure. The causes aren't exotic. They're the ordinary problems people notice in hallway conversations and never raise in the meeting.

Pre-mortem do's and don'ts

Do

• Do state the failure as a fact. "The project failed" works. "The project might fail" brings back the defensive mindset.
• Do have people write alone first. Silent writing protects against anchoring on the first speaker.
• Do invite people outside the core team, such as someone from support, finance, or a customer-facing role. They see dependencies the project team can't.
• Do assign owners to the top risks before the session ends. A list without owners is a complaint list.
• Do thank people who name uncomfortable risks. The next session depends on how the first one is treated.

Don't

• Don't let the sponsor or manager speak first. Their view will shape everyone else's.
• Don't argue with causes during the sharing round. Debate comes after the list is complete.
• Don't run it as a ritual. If the plan can't change, the exercise only builds cynicism.
• Don't stop at the list. Unprocessed risks add worry without adding protection.
• Don't confuse it with blame. The point is to find weak spots in the plan, not weak people on the team.

Common mistakes

Facilitators trip on the same few things. One is running the session with a plan so vague that every cause is "it wasn't defined." Another is running it so late that nothing can change. A third is collecting forty causes and acting on none. Keep the output short: five to eight risks, each with an owner, beats a long list nobody reads.

Teams also sometimes use the pre-mortem to rehash old grudges about previous projects. A good facilitator steers back: "Which of those could happen to this plan?" That keeps the exercise forward-looking and tied to decisions you can still make. Agile teams can run a lighter version at the start of a release or major epic and fold the actions into backlog items.

Conclusion

A pre-mortem is a cheap way to hear what your team already suspects. Klein's insight was that the framing does the work: once failure is assumed, people can discuss it without feeling disloyal. Run it after the plan is written, keep it short, and convert the top risks into owned actions. Then track them in your risk register, and revisit them at the midpoint.