Pre-mortem

Origin

Gary Klein (pre-mortem); Deborah Mitchell, J. Edward Russo and Nancy Pennington (prospective hindsight), 2007; 1989

Level

301 · Advanced

Fits

Startup, Small and mid-size, Scale-up

Time to apply

45 to 60 minutes for the session, plus 30 minutes to turn the list into plan changes

What you need

a written plan specific enough that it could fail: scope, date, owner, budget · 5 to 10 people who know the work, including at least one known skeptic · a facilitator who does not own the plan · paper or sticky notes, a timer and a place to record every reason as written

A pre-mortem is a planning exercise in which a team assumes that a project has already failed and then explains why. Gary Klein, a research psychologist and chief scientist of Klein Associates, described it in Harvard Business Review in 2007. The aim is to give people who doubt a plan a legitimate way to say so before money and reputations are committed. Daniel Kahneman, the 2002 Nobel laureate in economics, wrote about it in Thinking, Fast and Slow, and Klein says both Kahneman and Richard Thaler have encouraged its use.

Why imagining a failure changes what people say

Once a plan is agreed, doubt becomes impolite. Sunstein and Hastie open their Harvard Business Review article on group decisions by noting that groups often fail to reach the wisdom of crowds. A pre-mortem changes the social rules. Thaler describes it as a way of giving cover to skeptics who might otherwise stay quiet, and of asking why the project did fail, not why it might. A CGMA Magazine article quotes Mark Beasley of North Carolina State University saying the exercise tells everyone it is OK to think about worst-case scenarios.

The psychological idea underneath is prospective hindsight: explaining a future event as if it had already happened. Mitchell, Russo and Pennington studied it in a 1989 paper. Their abstract reports that whether the event was set in the future or the past had little effect, while whether the outcome was certain had a strong one. Explanations for certain events were longer and more often told as episodes. The paper’s abstract says nothing about accuracy.

What the 30% claim does and does not show

Many pre-mortem guides repeat that prospective hindsight improves people’s ability to identify reasons for an outcome by 30 percent. Klein’s 2007 article is where that wording comes from, and it credits the 1989 paper. We could not read the full text of that paper, and its abstract contains no percentage or accuracy measure. Treat the number as Klein’s summary of an old laboratory study on how people explain events, not as a measured benefit of running a pre-mortem on a project.

What the direct tests found

Direct tests are few and small. Klein is a co-author of the best-known one: in 2010, Veinott, Klein and Wiggins asked 178 college students to review a plan for handling an H1N1 flu outbreak, and the pre-mortem group showed the largest drop in overconfidence compared with groups that critiqued the plan or listed pros and cons. A 2020 conference poster from Michigan Technological University tested 53 students on a cybersecurity plan and found that only the pre-mortem condition differed from the control group on confidence. A second experiment with 43 students found no difference between group and individual pre-mortems.

In health care, a 2019 evaluation ran ten written pre-mortem sessions across ten Veterans Health Administration sites. They produced 217 unique ideas about barriers, and participants reported high psychological safety, the term Amy Edmondson introduced in 1999 for a team climate where speaking up is not punished. It measured ideas and safety, not whether the projects later succeeded.

In the sources we could open, none tracked real project outcomes. The solid claim is that the method makes people less sure of a plan and produces a long list of concerns. Whether that list improves results depends on what the team does with it. A 2016 study by Gallop, Willy and Bischoff also set out to measure the technique’s value for risk identification, but we could not read it.

Why plans need this kind of check

Optimism is the usual reason. Lovallo and Kahneman describe how Oxford Health Plans started a claims-system project in 1992 and, on October 27, 1997, disclosed the problems it had caused: the stock fell 63 percent and more than $3 billion of shareholder value disappeared in a day. Flyvbjerg and Budzier tell the story of Levi Strauss, whose IT project was proposed at under $5 million and ended in a $192.5 million charge against earnings in the second quarter of 2008. Buehler, Griffin and Ross showed in 1994 that people underestimate how long their own tasks will take, a pattern known as the planning fallacy.

Knowing about such biases does not remove them. Kahneman, Lovallo and Sibony wrote in 2011 that awareness of biases has done little to improve business decisions, which is why they favor procedures over good intentions.

How it differs from nearby tools

Teams also change the method. Atlassian’s version asks the group what could go wrong and what could go right, uses three votes per person and takes about an hour. The Public Health Foundation’s version ends in countermeasures for the likeliest causes. Both are useful, but the first moves away from Klein’s rule of stating that the failure has happened.

Turning the list into changes

Klein asks teams to rate each reason for likelihood, impact and ease of prevention. A simple chart of likelihood against impact is enough to choose where to start. Reasons that are both likely and costly go first, and the plan is edited to deal with them.

The result belongs in the plan, not in a separate risk document. For a quarter’s plan, put the signals into the weekly review described in quarterly planning. A Growth Lab plan starts from this kind of written list of what would make a launch fail.

How to apply Pre-mortem, step by step

1. Brief the plan and fix the horizon. Walk the group through the plan as it stands and agree the date at which failure will be judged, such as the end of the first year. People can only imagine a failure of something they all understand. Result: one shared version of the plan and a date.
2. Declare that it failed. Tell the team the project has failed completely, in the past tense and as a fact, not as a risk. Klein's own write-up warns against asking 'what could go wrong?' because it brings back the polite, forward-looking mode. Result: a team that is explaining a disaster instead of guessing at one.
3. Write reasons alone. Give everyone about two minutes of silent writing, one reason per note. Writing before speaking keeps the most senior person's view from setting the list. Result: a pile of independent explanations.
4. Collect them round-robin. Go round the room, one reason per person per turn, with the plan's owner going first to show it is safe. Record each reason in the writer's words. Stop when the notes run out. Result: one list, with no reason argued away yet.
5. Group and rate. Merge duplicates, then rate each reason for likelihood, impact and how easily it could be prevented, as Klein suggests. Result: a ranked list, with the likely and costly ones that can still be prevented at the top.
6. Change the plan. Take the top three to five reasons. For each, write one concrete change: a task added, a scope cut, a test moved earlier, a stop rule. Give each an owner, a date and a signal that would show the risk is appearing. Result: a revised plan, not a list of worries.
7. Check the signals on a rhythm. Put the signals into the weekly or quarterly review so the list does not disappear after the meeting. Result: a short standing agenda item that is closed when the project ends or the risk is gone.

Examples

A payments firm opening payouts in a new country

Illustrative. The team imagines it is twelve months later and the launch failed. Reasons written down: the local bank partner took far longer to approve the account than planned, the compliance review had no named reviewer, support could not answer in the local language, and the main customer segment never moved off cash. The changes: ask the bank for an approval timeline in week one and book a fallback partner, name the compliance reviewer before the build starts, and sign three pilot customers before any marketing spend.

A dental clinic moving to online booking

Illustrative. Failure is declared for six months after launch. Reasons: the front desk kept the paper diary because it was faster, older patients did not find the booking link, and doctors' schedules in the system were wrong in the first month. The changes: retire the paper diary on a fixed date, put the link on appointment reminders, and have each doctor check their own template before go-live.

A growth team committing to a quarterly target

Illustrative. Before the quarter's plan is locked, the team imagines the target was missed by a wide margin. Reasons: the one analyst who builds the reports was on leave for three weeks, the main channel's costs rose, and two experiments depended on the same landing page. The changes: a second person learns the reports, a budget stop rule is set for the channel, and one experiment moves to the next sprint.

When to use it

Use it after a plan is drafted and before money, people or a public date are committed: a launch, a migration, a hire into a new role, a quarterly plan, a partnership. It works best when the plan is detailed enough to be tested and when people who doubt it are in the room.

When not to use it

Skip it for decisions that are cheap to reverse, and for plans too vague to fail, where a clearer brief is the first job. Do not use it in place of a post-incident review once something has gone wrong. If the group is afraid of the plan's owner, fix that first or collect the notes anonymously.

Common mistakes

• Asking 'what could go wrong?' instead of stating that the project failed. The past tense is the point of the method.
• Letting the senior person read out their whole list first. It anchors everyone else. The owner should give one reason and then listen.
• Treating the session as the finish. A list with no owners, dates and signals changes nothing.
• Inviting only people who agree with the plan. The method works because doubt gets a legitimate place to go.
• Letting it turn into gloom. CGMA Magazine warns that a mismanaged pre-mortem can make an organization too risk-averse, so end with changes and a go decision.

FAQ

What is a pre-mortem analysis?

A pre-mortem is a meeting held before a project starts in which the team assumes it has failed and writes down why. The reasons are pooled, ranked and used to change the plan. The name comes from the medical post-mortem, which asks why a patient died, but here the question is asked while the patient is still alive.

What is the difference between a pre-mortem and a post-mortem?

A post-mortem looks at a failure that happened, with hindsight bias and often blame. A pre-mortem works on an imagined failure while the plan can still change. Both end in actions. A post-mortem can repair the next project; a pre-mortem can still change this one.

Who invented the pre-mortem?

Gary Klein, chief scientist of Klein Associates, who published it in Harvard Business Review in September 2007. The idea underneath, prospective hindsight, was studied earlier by Mitchell, Russo and Pennington in 1989. Daniel Kahneman wrote about the pre-mortem in Thinking, Fast and Slow (2011).

Does a pre-mortem work, and what is the 30% figure?

It reliably lowers confidence in a plan in the small studies we found, but we found no controlled study that tracked real project outcomes. The 30% figure is how Klein summarized the 1989 paper; that paper's abstract reports no percentage, so treat the number as a claim, not a measured effect of the pre-mortem.

How long does a pre-mortem take?

A first session takes 45 to 60 minutes for a team of 5 to 10 people: a short briefing, about two minutes of silent writing, a round of sharing and a rating step. Turning the list into plan changes with owners and dates needs another 30 minutes, which can be done by the project lead alone.

Sources

1. Gary Klein, Performing a Project Premortem, Harvard Business Review, September 2007
2. Gary Klein, Performing a Project Premortem, IEEE Engineering Management Review, 2008 (reprint)
3. Deborah J. Mitchell, J. Edward Russo, Nancy Pennington, Back to the future: Temporal perspective in the explanation of events, Journal of Behavioral Decision Making 2(1), 1989
4. Gary Klein, The Pre-Mortem Method, Psychology Today, January 2021
5. Gary Klein, Pre-mortem Method of Risk Assessment, gary-klein.com
6. Richard H. Thaler, The Premortem, Edge.org annual question, 2017
7. Daniel Kahneman, Thinking, Fast and Slow, Farrar, Straus and Giroux, 2011
8. Daniel Kahneman, Dan Lovallo, Olivier Sibony, Before You Make That Big Decision, Harvard Business Review, June 2011
9. Nobel Prize Outreach, Daniel Kahneman, Facts, Prize in Economic Sciences 2002
10. Elizabeth Keysor, Aliyah Wojtyna, Elizabeth S. Veinott, Premortem: Evaluating two structured analytic techniques for group brainstorming, SJDM poster, 2020
11. Heather Gilmartin and colleagues, Brainwriting Premortem: A Novel Focus Group Method to Engage Stakeholders and Identify Preimplementation Barriers, Journal of Nursing Care Quality 34(2), 2019
12. Jack Hagel, The merits of thinking the unthinkable, CGMA Magazine, reprinted in Journal of Accountancy, October 2012
13. Atlassian Team Playbook, Pre-mortem
14. Open Practice Library, Backcasting / Pre-mortem
15. Public Health Foundation, Pre-Mortem Analysis
16. Dan Lovallo, Daniel Kahneman, Delusions of Success: How Optimism Undermines Executives' Decisions, Harvard Business Review, July 2003
17. Bent Flyvbjerg, Alexander Budzier, Why Your IT Project May Be Riskier Than You Think, Harvard Business Review, September 2011
18. Cass R. Sunstein, Reid Hastie, Making Dumb Groups Smarter, Harvard Business Review, December 2014
19. Roger Buehler, Dale Griffin, Michael Ross, Exploring the planning fallacy: Why people underestimate their task completion times, Journal of Personality and Social Psychology 67(3), 1994
20. Amy C. Edmondson, Psychological Safety and Learning Behavior in Work Teams, Administrative Science Quarterly 44(2), 1999
21. David Gallop, Chris Willy, Jaron Bischoff, How to catch a black swan: Measuring the benefits of the premortem technique for risk identification, Journal of Enterprise Transformation 6, 2016

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn