Pre-Mortem Meeting: A 45-Minute Agenda, Script and Worksheet

The silent man and the shortcut

Gary Klein tells of a team building software to put state-of-the-art algorithms in the hands of military air-campaign planners. The team had sat through a long kickoff meeting. One member said nothing the whole time. Then Klein ran a pre-mortem: everyone was told the project had already failed, and asked to write down why.

In the pre-mortem, the silent man spoke up. One of the algorithms, he said, would not fit easily on the laptops used in the field, so the software would take hours to run when planners needed answers fast. Then a 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" ¹. The shortcut went in, and the project went on to be highly successful.

Both the problem and its fix had been in the room for the whole kickoff. Neither had been said. That is the job of a pre-mortem: not to predict the future, but to get a team to say what it already knows while the plan can still change.

A post-mortem asks why the patient died. A pre-mortem asks the same question while the patient can still be saved.

Why telling the room it failed works

An ordinary risk review asks what might go wrong. People answer politely: the risks everyone already knows, phrased so nobody is blamed. A pre-mortem, in Klein's words, "operates on the assumption that the 'patient' has died, and so asks what did go wrong" ¹. The failure is a fact. The only open question is the cause.

That small change does something social. Raising a doubt in a kickoff can feel like disloyalty to the plan and its sponsor. Once the room has been told the project failed, naming the flaw is the assignment. Klein's case for the method is exactly this: "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" ¹. It also, he writes, "reduces the kind of damn-the-torpedoes attitude often assumed by people who are overinvested in a project" ¹.

Be honest about the evidence. Klein grounded the method in a 1989 study of what its authors called prospective hindsight ³. That study's own summary reports that treating an outcome as certain changed the explanations people gave: they were longer and more concrete. A later experiment with 178 college students, by Klein's account, found the pre-mortem cut overconfidence in a plan more than ordinary critiques did ². Neither measured whether real projects went on to do better. Treat the pre-mortem as a cheap way to surface what people know, not as proof a plan is safe.

Daniel Kahneman, Dan Lovallo and Olivier Sibony put it on their checklist for big decisions, under the question "Is the worst case bad enough?": "Have the team conduct a premortem: Imagine that the worst has happened, and develop a story about the causes" ⁴.

Before the meeting

Hold it once the plan has been briefed and before the money, the contract or the launch date is committed: the last meeting in which changing the plan is still cheap. Klein's point is that it comes at the beginning of a project rather than the end ¹.

• Pick a plan specific enough to fail. It needs a goal, a date and a cost. An idea too vague to fail produces a list of vague worries.
• Invite the people who will do the work, not only those who will sign it. The silent man in Klein's story was a team member, not a sponsor.
• Choose a facilitator who is not the sponsor. The person who owns the plan has the hardest time hearing the first uncomfortable reason without defending it.
• Send a one-page brief the day before: the plan, the date and the budget. Do not send the risk register; it anchors people on the risks already listed.
• Book 45 minutes. Klein says it can take as little as 20 to 30 minutes ²; the extra time is for owners and early signs, the part most teams skip.
• Decide now who owns the list afterward. In Klein's version the project manager reviews it for ways to strengthen the plan ¹.

The 45-minute agenda

The script: what to say

1. Open with the failure, not the risk"It is [date, about a year out]. We carried out this plan exactly as it stands today, and it failed. Not wobbled: failed. It was switched off, written off or quietly abandoned. We are here to work out why."
2. Set the writing task"Take two minutes, on your own, and write down every reason it failed. Especially the ones you would not say in a normal meeting. Nobody will see your sheet but you."
3. Start the round"I'll go first." The leader reads one real reason, not a safe one. Klein's advice is to start with the team leader, to set an example of being candid ². Then: "One reason each, going around, until every list is empty. If yours has been said, read your next one."
4. Hold the line on debateWhen someone starts to argue: "Let's get every reason up first. We'll sort them in ten minutes." Thank each reason as you write it down.
5. Ask the outside questionBefore the round ends: "Has anyone outside this room already said this would fail? A customer, a supplier, an analyst, a former colleague? What did they say?"
6. Turn reasons into work"Which three would hurt most, and which of those can we still do something about? For each one: who owns it, what changes in the plan, and what is the first sign we would see?"

The worksheet and the reason log

Two sheets. The first is private: each person fills it in during the silent writing and keeps it. The second is the team's log, filled in during the last fifteen minutes and kept by the plan's owner.

After the meeting

A list on a whiteboard changes nothing. Klein's version ends with the project manager reviewing the list for ways to strengthen the plan ¹, and the exercise has a second payoff he names: it "sensitizes the team to pick up early signs of trouble once the project gets under way" ¹. Both only happen if the list goes somewhere.

• Within two days, the owner sends the sponsor one page: the three to five kept reasons, the change each made to the plan, its owner and its early sign. The full list goes in an appendix, without names.
• Put the early signs on the status report. A sign nobody checks is decoration.
• Run it again before the next big commitment: a contract, a hire, a launch date. The plan will have changed, and so will the reasons.
• At the end, compare. Which reasons came true, and which failure surprised everyone? That is how a team learns what its pre-mortems miss.

Write the decision and its kept reasons into the decision log, so the next review can judge the plan by what was known when it was made.

Remote and asynchronous teams

The method survives a video call if two things are protected: private writing and no early discussion. Have everyone write their reasons in a private form or a document only they can see, then reveal them all at once before the round begins, so nobody edits their list after hearing the boss. Run the round in the call, one reason each, exactly as in the room.

Across time zones, split it. Send the plan and the opening line with a 24-hour window to submit reasons privately. Then hold a 30-minute call to read the combined list, pick the few that matter and assign owners. Keep the reasons anonymous in anything that leaves the call.

A worked example

Notice what the meeting did. None of the three reasons was on the project's risk register, and none needed a forecast. Each was known to someone in the room. The pre-mortem gave them a turn to say it, and the log turned it into a date, an owner and a sign to watch.

When it goes wrong

• Asking "what could go wrong?" Klein names this non-challenging question as a common mistake ². It invites the known risks, politely phrased. State the failure as a fact.
• Running it after the commitment. Once the contract is signed, the reasons have nowhere to go, and people know it.
• The boss argues back. One defensive answer ends the honesty for the rest of the meeting.
• A slow, leisurely pace. Klein lists this too ². Short, timed writing keeps people from editing themselves.
• Ending with a list and no owners. A reason without an owner, a change and an early sign is a worry, not a decision.
• Naming who said what. Keep names out of anything that leaves the room, or the next pre-mortem will be polite.

And know its limit. A pre-mortem only surfaces what someone in the room knows or suspects. A risk nobody has seen stays unseen, which is why the outside question in the script matters, and why the people closest to customers, suppliers and operations belong in the room. For futures the team cannot see from here, pair it with scenario planning.

Before you run it: a checklist

• The plan has a goal, a date and a cost.
• The money or the launch is not yet committed.
• The people who will do the work are invited, not only the sponsors.
• The facilitator is not the plan's sponsor.
• The opening line names a date and states the failure as a fact.
• Silent writing comes before anyone speaks.
• The leader reads first, and reads a real reason.
• Someone owns the list after the meeting, and a date is set to review it.

Running a big decision meeting soon after? The decision meeting checklist covers the day before, the room and the last ten minutes, and the initiative charter is where the kept reasons become kill criteria.

Questions

What is a pre-mortem meeting?

A short meeting held before a plan is committed, in which the team is told the project has already failed and each person writes down why. The reasons are collected one at a time, and the plan is changed to deal with the ones that matter. Gary Klein described it in the Harvard Business Review in 2007.

How long does a pre-mortem take?

Klein says it can take as little as 20 to 30 minutes. Allow 45 if you want to leave with owners, changes to the plan and early signs for each kept reason, which is the part most teams skip.

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

A post-mortem asks why a project failed after it has. A pre-mortem asks the same question before the project starts, by imagining the failure, so the answers can still change the plan.

What questions do you ask in a pre-mortem?

Open with a statement, not a question: it is a year from now, and the project failed. Then ask why it failed, what reason people would not say in a normal meeting, who outside the room has already predicted the failure, and which reasons the team can still do something about.

Who should run a pre-mortem?

Someone other than the plan's sponsor, if possible. The leader should still read the first reason, and a candid one, to show that hard reasons are welcome.

Where to go next

• Decision Meeting Checklist: Most of It Happens the Day Before
• Project Charter Template: Write the Ending Before the Work Starts
• Strategy Workshop Facilitation
• Decision Log