Stratrix

Quick reference

Key formula / structure

The project has failed. Why? Write alone, share one at a time, then own the top reasons.

Memory aid

The risk is usually already in the room. The pre-mortem's job is to get it said.

TL;DR

After the plan is briefed and before it is approved, tell the team the project has failed by a set date. Everyone writes every reason alone for a few minutes. Collect one reason from each person in turn, the leader first, until all are recorded. Rank them, give the top few an owner, a change to the plan and an early sign to watch, and check the signs at every review.

What Is Pre-Mortem?

A pre-mortem is a short meeting held before a plan is committed. The leader tells the team that the project has failed, and everyone writes down, on their own, every reason they can think of. The reasons are then read out one at a time, and the project's owner uses the list to strengthen the plan. Gary Klein described the method in the Harvard Business Review in 2007. A post-mortem asks why a project died; a pre-mortem asks the same question while the patient can still be saved.

By making it safe for dissenters who are knowledgeable about the undertaking and worried about its weaknesses to speak up, you can improve a project’s chances of success.

— Gary Klein, "Performing a Project Premortem," Harvard Business Review (September 2007)

The usual reason given for running a pre-mortem is that it finds risks nobody saw. Klein's own best story shows something else. In a session on a project to bring advanced algorithms to military air-campaign planners, a team member who had been silent through a long kickoff meeting said that one of the algorithms would not fit easily on the laptops used in the field, so the software would take hours to run when users needed quick results. Then, Klein writes, "it turned out that the algorithm developers had already created a powerful shortcut, which they had been reluctant to mention." The shortcut went in, and the project went on to be highly successful. Both the problem and its fix were already in the room. Neither had been said. That is the job. Most projects that fail were doubted by somebody before they started, inside the team or outside it. A pre-mortem does not need to be clever about the future. It needs to make it safe, and expected, to say the thing people are already thinking. Telling the team the project has already failed does that: a doubt stops being disloyalty and becomes the assignment.

A pre-mortem in five moves

From the briefed plan to a stronger one, in under an hour.

Brief the plan

Everyone hears the same plan

→

Declare the failure

"It failed. Why?"

→

Write alone

Every reason, a few minutes, no talking

→

One each, in turn

Until every reason is recorded

→

Own and change

Owners, plan changes, early signs

Origin & context

Gary Klein described the premortem in "Performing a Project Premortem" in the September 2007 issue of the Harvard Business Review. He grounded it in a 1989 study by Deborah J. Mitchell, J. Edward Russo and Nancy Pennington of what they called prospective hindsight: imagining that an event has already happened, and then explaining it. His stated motive was social: "too many people are reluctant to speak up about their reservations during the all-important planning phase."

Builds on: Deborah J. Mitchell, J. Edward Russo and Nancy Pennington (1989), Back to the future: Temporal perspective in the explanation of events, Journal of Behavioral Decision Making; Gary Klein (2007), Performing a Project Premortem, Harvard Business Review.

Pre-Mortem in action

A military planning project

The problem and the fix were both in the room

Gary Klein's own best example comes from a session on a project to make state-of-the-art computer algorithms available to military air-campaign planners. The team had already sat through a long kickoff meeting. One member had said nothing during it.

In the pre-mortem he volunteered that one of the algorithms would not fit easily on certain laptop computers being used in the field. The software would take hours to run when users needed quick results. Unless the team found a workaround, he argued, the project was impractical.

Then the second silence broke. As Klein tells it, "it turned out that the algorithm developers had already created a powerful shortcut, which they had been reluctant to mention." Nothing in the session predicted the future. It got two people to say what they already knew.

The developers' shortcut was substituted, and, Klein writes, the project went on to be highly successful.

Quibi

The doubts were in print six weeks before launch

Quibi raised $1.75 billion before a single customer had paid for a single show. Its plan was a phone-only service of premium short shows, at $4.99 to $7.99 a month, with 175 series in the pipeline and content costing as much as $6 million an hour.

On February 24, 2020, six weeks before launch, the trade site VideoWeek asked analysts about it. "I'm skeptical there's a large audience for it now," said Ross Benes of eMarketer. Nitesh Patel of Strategy Analytics said "the challenge for Quibi will be convincing users $4.99 delivers value for money." Two reasons any pre-mortem asks a team to consider, whether anyone wants the product and whether they will pay for it, were already being raised in public.

Quibi launched on April 6, 2020. Whether anyone inside said the same things before launch is not on the public record. What the record shows is that the reasons did not need inventing. They needed to be heard by the people who could still change the plan.

Quibi had projected more than 7 million subscribers in its first year and had about 500,000 a few weeks before it announced, on October 21, 2020, that it was shutting down. The app stopped streaming on December 1, 2020, and its content library was sold to Roku in January 2021 for what Variety reported as significantly less than $100 million.

Read the full story: what Quibi got wrong →

Using it in the room

Run it once the plan has been briefed and before the money is committed: the last meeting in which changing the plan is still cheap. On a long project, run it again before each major commitment, such as a contract, a hire or a launch date.

Questions to ask

  • ?It is a year from today and this project has failed. What happened?
  • ?What is the reason you would not say in a normal meeting?
  • ?Who outside this room has already said this will fail, and what did they say?
  • ?Which reason would hurt most, and which would be cheapest to prevent?
  • ?Who owns each reason we keep, and what is the first sign it is happening?

The 30-minute version

Five minutes to restate the plan. One sentence from the leader: it is a year from now and the project has failed. Five minutes of silent writing. Fifteen minutes going around the room, one reason each, the leader first, until the list is complete. Five minutes to pick the top three. The last few minutes to give each an owner, a change to the plan and an early sign.

Core Components

1

The failure, stated as fact

The leader does not ask what might go wrong. The leader says the project has failed and asks why. Klein's case for the method is that this framing, which the research behind it calls prospective hindsight, helps people identify reasons for an outcome.

Example

"It is one year from today. The new billing system was switched off last week. Write down why."

2

Writing before speaking

Everyone writes their reasons alone for a few minutes before anyone speaks, so the first opinion voiced does not set the rest and the quietest people's reasons reach the list.

Example

Five minutes of silent writing on cards, one reason per card.

3

One reason each, in turn

The leader goes around the room taking one reason from each person, starting with the project's leader, until every reason is recorded. Klein's version starts with the project manager, which signals that doubts are expected from the top.

Example

The project lead offers 'the vendor's key engineer leaves', then the next person, and so on.

4

An owner for the list

After the session the project's leader reviews the list and changes the plan. Without that step, the meeting is a vent, not a method.

Example

The three reasons ranked highest each get a named owner and a change to the plan by Friday.

5

Early signs

For each reason kept, the team names the first visible sign that it is starting to happen. Klein notes the exercise sensitizes a team to early signs of trouble once the project is under way.

Example

'Vendor engineer leaves' gets the sign 'vendor misses two status calls in a month'.

Klein's article describes the premortem as an advantage over ordinary prelaunch risk analysis not only because it surfaces problems early but because it "reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project."

When to Use Pre-Mortem

Scenario 1

Before a large project is approved

Problem it solves: The plan has momentum, the sponsors are invested, and the people with doubts have not said them.

Real-world application

A finance team runs a pre-mortem on a new planning system the week before the board approves the spend.

Scenario 2

Before signing an acquisition

Problem it solves: The deal team has spent months building the case for the deal and few incentives to argue against it.

Real-world application

The integration lead asks the deal team to imagine the deal written off three years from now and to list why.

Scenario 3

Before a launch

Problem it solves: The launch date is fixed and nobody wants to be the one who slows it.

Real-world application

A product team imagines the launch has flopped and finds that its pricing has not been tested with a single paying customer.

Scenario 4

At the end of a strategy offsite

Problem it solves: The room has agreed a plan, and agreement in a room is not the same as belief.

Real-world application

The last hour of the offsite is a pre-mortem on the plan the team agreed that morning.

The leader's first reaction decides the rest

If the most senior person in the room argues with the first uncomfortable reason, nobody offers a second. Thank every reason, write it down, and save the debate for after the list is complete.

How to Apply Pre-Mortem: Step by Step

Before you start

  • →A plan specific enough to fail: what will be done, by when, at what cost
  • →The people who will carry it out in the room, not only the sponsors
  • →A leader willing to hear the reasons without arguing with them
Tools:Cards or sticky notesA board or shared document for the listA timer
1

Brief the plan

Make sure everyone in the room has heard the same plan, with its goal, date and budget.

Tips

  • ✓Keep the briefing short; the plan is not on trial yet

Common mistakes

  • ✗Running a pre-mortem on an idea too vague to fail
2

Declare the failure

Set a date in the future and tell the room the project has failed by then. Ask why, not whether.

Tips

  • ✓Make the failure specific: switched off, written off, abandoned

Common mistakes

  • ✗Asking what might go wrong, which invites a polite list of known risks
3

Write alone

Give everyone a few minutes to write every reason they can think of, without talking.

Tips

  • ✓Ask especially for the reasons people would not mention in a normal meeting

Common mistakes

  • ✗Letting discussion start before everyone has written
4

Collect one reason at a time

Go around the room, starting with the project's leader, taking one reason from each person until every reason is recorded.

Tips

  • ✓Thank each reason and write it where everyone can see it

Common mistakes

  • ✗Arguing with a reason while the list is still being built
5

Rank and assign

Pick the reasons that would hurt most and that the team can do something about. Give each an owner, a change to the plan, and an early sign to watch.

Tips

  • ✓Three owned reasons beat thirty listed ones

Common mistakes

  • ✗Ending with a list and no owners
6

Change the plan and check back

The project's leader reviews the list after the session and changes the plan. At the next review, check each early sign.

Tips

  • ✓Put the early signs on the project's regular status report

Common mistakes

  • ✗Filing the list and never looking at it again

Showing the result

One slide for the sponsor: the three reasons the team ranked highest, and for each the change it made to the plan, its owner and the early sign the team will watch. The full list goes in an appendix.

On the slide

  • ✓The top three reasons, in the team's words
  • ✓The change each one made to the plan
  • ✓An owner and an early sign for each

Left off

  • ✕Who said which reason
  • ✕The full list (put it in the appendix)
  • ✕Probabilities nobody measured

Value & Outcomes

Primary benefit

It gets the doubts and fixes people already have said while the plan can still change, at the cost of under an hour.

Additional benefits

  • ✓Makes dissent the assignment rather than a risk to the person who offers it
  • ✓Cools the overconfidence that builds as a team invests in its plan
  • ✓Gives the team early signs to watch once the project is under way

What you'll learn

  • →How to frame the failure so the reasons come out specific
  • →How to stop the first voice from setting the list
  • →How to turn a list of reasons into owned changes to a plan

Typical outcomes

Three to five owned changes to the planA list of early signs for the status reportDoubts on the record before the money is spent

Best Practices

📋 Preparation

  • •Hold it after the plan is briefed and before it is approved
  • •Invite the people who will do the work, not only those who will sign it
  • •Decide in advance who owns the list after the meeting

🚀 Execution

  • •State the failure as fact, with a date
  • •Write before anyone speaks
  • •Take one reason from each person in turn, the leader first

🔄 Follow-Up

  • •Give every kept reason an owner and a change to the plan
  • •Track the early signs on the regular status report
  • •Run it again before the next major commitment

💎 Pro Tips

  • •Ask who outside the room has already said the project will fail
  • •Do not record who said which reason in anything that leaves the room
  • •If no reason surprises the leader, the room did not feel safe
Ask who outside the room has already said it

Add one question to the round: who outside this team has already predicted this project will fail, and what did they say? Analysts, customers, suppliers and former employees often say it in public first.

Limitations & Pitfalls

⚡

The research behind it is small. Klein's article rests mainly on one 1989 study, which, as he describes it, measured how well people could identify reasons for an outcome, not whether plans that went through a pre-mortem then failed less often.

Mitigation: Treat it as a cheap way to surface what people know, not as proof a plan is safe

⚡

It only surfaces what someone in the room knows or suspects. A risk nobody has seen stays unseen.

Mitigation: Invite people close to customers, suppliers and operations, and ask what outsiders have already said

⚡

It depends on the leader. If the senior person argues with the first hard reason, the rest are not offered.

Mitigation: Have someone other than the sponsor run the meeting, and ban debate until the list is complete

⚡

It can become a ritual whose list is filed and forgotten.

Mitigation: End with owners, plan changes and early signs, and check them at the next review

⚡

Vivid stories can crowd out likely ones. The most dramatic reason is not always the most probable.

Mitigation: Rank the reasons on likelihood and harm before assigning owners

What comes before and after

Run first

The decision-making framework →

Frame the decision and the plan clearly enough that they can fail.

Scenario planning →

Sets out the futures the plan has to survive; the pre-mortem tests the plan inside them.

Run next

Stage-Gate →

Turn the top reasons into the questions asked at the next gate.

A decision log →

Record the reasons, owners and early signs so the next review can check them.

Where this comes fromGary Klein introduced this (2007).

Sources & further reading

More Management Frameworks

Other frameworks in the Stratrix library.

Risk & Governance

Risk Appetite Framework

A governance framework that defines how much risk an organization is willing to accept in pursuit of its objectives, providing boundaries for decision-making at all levels.

Risk & Governance

Scenario Analysis for Risk

A forward-looking risk assessment technique that explores plausible future scenarios to understand potential impacts and prepare appropriate responses for uncertain events.

Risk & Governance

COSO ERM Framework

A comprehensive enterprise risk management framework that integrates risk management with strategy and performance, helping organizations identify, assess, and manage risks across the entire enterprise.

Risk & Governance

Three Lines Model

A governance model that structures an organization's risk management and assurance activities into three distinct lines: management controls, risk oversight functions, and independent assurance.

Risk & Governance

Monte Carlo Simulation

A quantitative risk analysis technique that uses random sampling and probability distributions to model the range of possible outcomes for uncertain decisions, providing probability-based insights rather than single-point estimates.

Risk & Governance

Compliance Management Framework

A structured system for ensuring an organization meets all applicable legal, regulatory, and ethical requirements through policies, training, monitoring, and enforcement.

Tools to try

More from Stratrix

The Strategist’s Craft

The methods behind the job: the planning cycle, initiative charters, decision rights, the memo that gets a yes.

Methods and templatesStart with the craft →

Ask Stratrix

Three questions a month are free.

Stratrix Team

Every Casebook, three Strategy Packs a seat each year and Ask Stratrix, for teams that face these decisions all year.

$1,999 a year · $499 a seatWhat is included →

New analyses, by email

The defining moves in business, and what they teach, as they publish.

We'll email you a link to confirm. Unsubscribe anytime. Privacy policy.

See Pre-Mortem in the wild.

Follow Pre-Mortem across the companies and lenses where it actually shaped the strategy — the decision, the rationale, and how it played out.

Explore the lenses →