How to Run a Pre-Mortem: Finding Failure Before It Happens

Tell a project team that its plan has already failed, then ask why. That reversal is the pre-mortem, which the psychologist Gary Klein described in the Harvard Business Review in 2007 as a way of making it safe for the people who know the work to raise their worries while the plan can still change.¹ A pre mortem (also written premortem) needs about 45 minutes, paper, a timer and a facilitator. It belongs early in the planning side of project management and runs in seven steps:

1. Share the plan and set a failure date.
2. Announce that the project has failed.
3. Have everyone write reasons alone.
4. Share the reasons one at a time, round the table.
5. Rank the reasons that matter most.
6. Give each top reason an action and an owner.
7. Move the actions into the risk log and revisit them.

What is a pre-mortem in project management?

A pre-mortem in project management is a planning exercise in which the team imagines that the project has failed at a set point in the future, then works backward to the causes and turns the strongest into changes to the plan. Wikipedia’s entry presents it as a tool for breaking groupthink and for countering overconfidenceoverconfidence: Being more sure of your knowledge, skill or forecasts than the results justify, for example rating yourself above average or giving too narrow a range for an estimate. It is broader than the Dunning-Kruger effect, which is about how the error varies with skill.Full entry in the glossary and the planning fallacyplanning fallacy: The tendency to underestimate how long your own tasks will take, even when you know similar tasks ran late before. Estimating from your track record on past tasks, rather than from the plan, tends to correct it.Full entry in the glossary.²

The framing does the work. An ordinary risk review asks what might go wrong, and people answer cautiously, because each doubt sounds like criticism of the plan’s author. A pre-mortem asks what did go wrong, a contrast Klein draws with the image of a patient who has already died.¹ Once failure is a given, a worry stops sounding disloyal. Klein’s colleagues describe a healthy competition in which people show they are sharp by finding novel, insightful reasons for the fiasco.³

too many people are reluctant to speak up about their reservations during the all-important planning phase

The method has one main controlled test. In a 2010 lab experiment run by Klein’s own firm with university students, a pre-mortem cut confidence in a flawed plan more than three common review methods.³ No study has yet checked whether projects that run one succeed more often, so it is best used as a low-cost way to bring risks into the open.

At a kickoff, a software team nods at the launch timeline. In the pre-mortem, the developer who has seen the payment provider’s test system go down twice writes that on a card. Run it when the plan is concrete enough to criticize and still cheap to change; the 2010 study authors suggest the kickoff meeting.³

How long should a pre-mortem take? A 45-minute agenda

In our judgment, a pre-mortem takes 30 to 60 minutes for most teams, and 45 minutes suits a group of five to eight people. The writing itself is short: the 2010 experiment gave people two minutes,³ and the health-service sessions described below allowed about ten.⁴ Our suggested agenda protects the second half of the meeting for ranking and owners.

1. 0-5 minWalk through the plan; set the failure date
2. 5-7 minAnnounce the failure
3. 7-12 minSilent writing, alone
4. 12-24 minRound-robin sharing
5. 24-32 minGroup and rank
6. 32-42 minActions and owners
7. 42-45 minInto the risk log; set a review date

With more than about eight people, split into smaller tables, as some facilitators in US veterans’ health care did, and merge the ranked lists.⁴

How to run a pre-mortem meeting, step by step

These steps follow the sequence Klein’s team set out in 2010, with a ranking step and a risk-log step added.³ The script lines are our own wording.

1. Share the plan and set a failure date

Walk through the plan’s goal, scope and main dates. Then name a date when failure would be obvious, such as six months out, the horizon in Klein’s team’s example. Invite those doing the work and anyone who has seen similar projects break.

“Before we commit, we’re going to spend 45 minutes finding out how this plan dies.”

2. Announce that the project has failed

State the failure flatly and close off debate about whether it could happen. Klein’s team frames it as a crystal ball that shows the plan was a fiasco but not why.

“It’s the end of June. The project has failed badly. We’re not here to argue about whether. Your job is to explain why.”

3. Have everyone write reasons alone

Give five minutes of silence and ask for one reason per card or sticky note. Writing first stops the loudest voice from setting the frame. Brian Mullen and colleagues, pooling lab studies in a 1991 meta-analysismeta-analysis: A study that combines the results of earlier studies on the same question into one overall estimate. Pooling makes the estimate more precise, but it cannot repair the studies it pools: a meta-analysis of surveys is still survey evidence.Full entry in the glossary, found that brainstorming groups were less productive than individuals working separately with their ideas pooled, and that losses were larger in bigger groups.⁵ The same result runs through the research on how well group brainstorming holds up.

“Write down every cause you can come up with: the plan, the team, the people we depend on, the world outside. No names, only causes.”

In a team where people fear blame, collect cards without names; building psychological safety in a team is slower work than one meeting.

4. Share the reasons one at a time, round the table

Go around the room, one reason per person per turn, writing each on the board until the cards run out. Klein’s version starts with the team leader, which shows that criticizing the plan is welcome. If your team tends to echo the boss, have the leader go last instead.

Allow questions of fact only, no debate. Expect some venting; facilitators in the health-service sessions found some participants used the time to air complaints about their organization.⁴ Note those on a separate sheet and move on.

“One reason each. Pass if yours is already up there.”

5. Rank the reasons that matter most

Group the duplicates, then give each person three votes for the reasons that are both plausible and damaging. Some reasons will be dramatic but unlikely, and Wikipedia’s entry warns that the method may identify weaknesses that are not real.² Keep the top three to five; the rest go on a watch list.

“Vote for the ones that worry you, not the ones that make a good story.”

6. Give each top reason an action and an owner

For each top reason, ask what in the plan changes: a new step, an earlier test, a moved date or less scope. In the 2010 procedure, each person scans the list and suggests one action to make the failure less likely. Put one name and one date on every action, and ask out loud whether any reason calls for scaling the project back.

“If this reason came true, what would we wish we had done this month?”

7. Move the actions into the risk log and revisit them

Before people leave, enter each top reason as a risk with its trigger, response, owner and review date in the team’s RAID log, where risks sit beside assumptions, issues and dependencies. Klein’s team also recommends returning to the pre-mortem list from time to time to see whether any of its items are starting to appear.

Your pre-mortem

• Book 45 minutes before the plan is signed off
• Invite the people who will carry out the plan
• Name a failure date
• Give five silent minutes for writing
• Share one reason per person per turn
• Rank and keep the top three to five
• Put an owner and a date on every action
• Enter each top reason in the risk log

A small worked pre-mortem: a clinic booking system

The clinic chain below is invented to show the method. A team of six at a chain of dental clinics plans to move bookings online by March. The facilitator sets the failure date at the end of June; after the round-robin the board holds about thirty cards, and three win the vote.

1. Double bookings. Reception staff kept taking phone bookings on paper, so the online calendar filled slots that were already taken. Action: from day one, phone bookings go straight into the same system. Owner: operations lead.
2. Low uptake. Many older patients never used the site. Action: keep the phone line, send a booking link by text message, and track the share of online bookings each month. Owner: patient services manager.
3. Late payment link. The connection to the payment provider was not ready. Action: test against the provider’s test system in week two. Trigger: no working test payment by the end of January means launching without online deposits. Owner: lead developer.

The card that read “the clinics close” went on the watch list. All three actions went into the RAID log for review at the weekly project meeting. The third came from the developer who had seen the test system fail, a reason nobody raised at the kickoff.

Why imagining failure brings out more problems

Treating failure as certain works against two habits that hide risks: overconfidence in a plan you helped write, and a group’s pull toward the views it already shares. The idea behind it, prospective hindsight, comes from 1989 experiments by Deborah Mitchell, Edward Russo and Nancy Pennington, who asked people to explain events framed as certain or uncertain, and set in the past or the future.⁶

Certainty mattered and timing did not. According to the paper’s abstract, explanations of events presented as sure were longer and more often told as a chain of specific happenings.⁶ Told that the project failed, people stop weighing whether it might and start building a story of how, with concrete details: the supplier, the holiday week, the colleague who left.

Myth

Prospective hindsight makes people about 30% better at predicting what will go wrong.

Fact

The 1989 experiments studied the explanations people wrote. Klein's team later summed up the gain as about 30% more reasons. More reasons do not mean more accurate predictions.

Klein’s team gives the figure in its 2010 paper as roughly 30 percent more reasons.³ More reasons give a team more to check, but they are still guesses.

Planning research adds a second reason. In a 1994 set of studies, Roger Buehler and colleagues found that people who underestimated their own completion times, the pattern called the planning fallacy, focused on plan-based scenarios rather than on relevant past experiences.⁷ A pre-mortem forces the failure scenario onto the table, which suits anyone who has seen how overconfidence distorts plans.

The group side matters as much. In a 1985 lab study, Garold Stasser and William Titus found that discussion was dominated by information members already held in common and by information that supported their existing preferences, so groups missed the better choice.⁸ The one person who knows about the shaky payment system is easy to talk over, which is how a team slides into groupthink about a plan everyone likes.

1. Today: the plan exists and still looks fine to the people who wrote it
2. The failure date: the facilitator states that the project has failed, as a fact with a date
3. Looking back: each person writes reasons for the failure alone, then shares them one at a time
4. The risk log: the top reasons come back to the present as actions, each with an owner and a review date

Guard the silent writing minutes most closely when one person holds knowledge nobody else has, since open discussion talks that person over.

Does a pre-mortem work? What the studies measured

The evidence for pre-mortems is small: one 2010 lab experiment from Klein’s own firm, a master’s thesis, a field report from US veterans’ health care and a study of game development teams. None measured whether projects that ran a pre-mortem succeeded more often.

The study

Limited evidence

Five ways to review a flawed flu plan (Veinott, Klein and Wiggins, 2010)

178 university students, working in groups of five or six, read a deliberately flawed plan for a campus flu lockdown and were randomly assigned to one of five conditions. After two minutes of writing, average confidence on a 0 to 100 scale fell by about 25 points in the pre-mortem groups, against about 14 for pros and cons and about 12 for listing cons only, with little or no change after a critique or a filler task. Once groups proposed fixes, confidence rose most in the pre-mortem condition.³

Lower confidence in a flawed plan is intended, but it is a stand-in measure: the paper reports confidence and understanding, not whether the revised plans were better. The students reviewed a ready-made plan they would never carry out, and the paper names neither their university nor its country. The research was funded through a US Army research programme and run by the method’s creator with two colleagues at his firm.³

The rest of the evidence is mixed. A 2017 master’s thesis at Michigan Technological University found that teams of US Army cadets made fewer fouls on an obstacle course after a pre-mortem than after a standard military plan review. Against a worst-case-scenario method, the pre-mortem showed no clear difference in the number of reasons in one experiment and produced more in another.⁹ In a field report from the US Veterans Health Administration, ten written pre-mortem sessions produced 217 distinct barriers to a new nursing program, and participants said they felt safe sharing ideas; there was no comparison group.⁴

The most useful warning comes from a 2023 US study of ten game development teams. They found many reasons for failure and many fixes, yet surprisingly few teams revised their plans to scale back the game’s complexity.¹⁰

Pre-mortem vs post-mortem: what is the difference?

A post-mortem looks back after a project has ended to learn lessons for next time; a pre-mortem runs the same analysis before the work begins, while the findings can still help this project. Writing for UK hospital doctors in 2017, Jonathan Mills and Judy McKimm describe the post-mortem as an attempt to understand what contributed to a failure so the same mistakes are not repeated.¹¹ Klein’s colleagues say the pre-mortem moves the autopsy forward.³

Because pre-mortem reasons are imagined, the meeting ranks them before acting on any. Bring your last project’s review findings into this one’s pre-mortem as prompts; running that blameless review after a project closes deserves its own guide.

The bottom line

A pre-mortem is cheap: 45 minutes, some cards and a willingness to hear bad news early. Before your next plan is signed off, set a failure date, give everyone five silent minutes to write, and keep the meeting going until the top three reasons have owners and sit in your risk log.