What a Pre-Mortem Is
A pre-mortem is a structured meeting you run at the beginning of a project — typically after the one-pager is written but before any significant work has started. You imagine that the project has already failed, and you ask everyone in the room to explain why.
The technique was developed by psychologist Gary Klein and made popular by Nobel Prize winner Daniel Kahneman. The core insight behind it is simple: when a plan is being presented, most people are unconsciously trying to support it — they look for reasons it will work. When you explicitly instruct people to imagine the plan has already failed, they switch modes. They stop being optimistic and start being honest. Things that felt impolite to say in a planning meeting become easy to say when failure is the premise.
The pre-mortem extracts information that people already know but won't volunteer. That is its entire value.
Telling a room "this project will fail — here's why" creates psychological safety around pessimism. Normally, naming risks feels like disloyalty to the plan. In a pre-mortem, it's the assignment. People say things they wouldn't say in any other setting — and those things are often the most important things to hear.
When to Run One
The best time for a pre-mortem is after you have a plan but before you've committed to it publicly. That means: after the one-pager is written and shared with the team, but before the project has been announced to the org or kicked off formally.
Too early (before you have a plan) and there's nothing concrete to critique. Too late (after the project has started and resources are committed) and the findings feel threatening rather than useful — people get defensive, and the window to act on the findings has narrowed significantly.
For projects longer than three months, consider running a second pre-mortem at the halfway point. Your understanding of what can go wrong improves dramatically once you've been inside the project for six weeks.
Who to Invite
Invite five to eight people. Larger groups produce groupthink — the loudest voices anchor the conversation. Smaller groups miss perspectives.
Include:
- The full project team (they will spot execution risks others won't)
- One or two people from adjacent teams (they'll name things the project team has normalized)
- Your most honest skeptic — the person who is most likely to think the project is risky (they are often right for reasons they've never fully articulated)
Do not invite senior executives or anyone in the reporting chain of the people in the room. Hierarchy kills honesty in pre-mortems. If someone worries their observation will reflect badly on them in front of their skip-level, they won't say it.
The Step-by-Step Facilitation Guide
A pre-mortem takes 60–90 minutes. Here is the exact sequence.
Open with exactly this framing: "Imagine it's six months from now. The project has failed — completely. The launch either didn't happen, or it happened but didn't achieve what we needed. Leadership is disappointed. Some customers are affected. I want you to write down all the reasons why that happened."
Then stop talking. Give the room two minutes of silence to write. Do not allow discussion yet. The silent individual writing is critical — it prevents groupthink and ensures you get the ideas from people who wouldn't normally speak up.
Important: Do not soften the premise. "Imagine we didn't fully hit our goals" is not the same as "imagine it failed completely." The latter unlocks more honest answers.
Go around the room. Each person shares one failure reason from their list. Write each one on a whiteboard or shared doc — verbatim, not paraphrased. Do not allow debate at this stage. If someone objects to another person's reason, note it but do not let it become a discussion. The goal of this phase is collection, not evaluation.
Keep going around the room until the list stops growing. Typically this produces 15–25 distinct failure modes for a complex project.
Common categories you'll see:
- Technical risks (underestimated complexity, unknown dependencies, integration failures)
- People risks (key person leaves, team gets pulled onto higher-priority work, skill gaps)
- External risks (dependency team doesn't deliver, customer requirements change, regulatory surprise)
- Process risks (decisions take too long, scope keeps expanding, communication breaks down)
- Assumption failures (things we assumed were true that turn out not to be)
Give each participant three votes (use sticky dots or a raised-hand poll in remote settings). Ask: "Which of these failure modes would you bet money on? Vote for the ones you think are most likely to actually happen."
This is different from asking which ones are scariest. You want the ones they think are likely. The most-voted items become your priority list.
After voting, you typically have a clear top four or five failure modes that got multiple votes. Everything below the threshold is low-probability noise. Focus the rest of the meeting on the top items only.
Take each top failure mode and ask two questions:
"Why would this actually happen?" Go one level deeper. Not "the dependency is late" but "the dependency is late because that team has already committed their next two sprints to another initiative and we haven't confirmed capacity." The deeper root cause is often where the actionable insight lives.
"What could we do now to prevent it or contain it?" Keep this specific. "We should communicate better" is not an action. "We should schedule a weekly check-in with Priya Nair starting this Friday and get a written delivery commitment by May 4" is an action.
Assign every action to a named person. Unowned actions are not real actions.
Close the meeting with the following: read back the three to five highest-priority failure modes and their assigned prevention actions. Confirm owners. Set a follow-up date to check that prevention actions have been completed.
Write a brief summary doc within 24 hours. It should contain: the failure modes, the root causes identified, the prevention actions, and the owners. Share it with the full project team, not just the attendees. The findings should be visible to everyone who can act on them.
Failure Mode Prompt Library
If the room goes quiet during phase two, use these prompts to draw out more items. Ask each question directly to the group.
"What happens if the one person who knows how this system works leaves the company in month two?"
"Which external team will fail to deliver their part? What do we do when that happens?"
"Which thing that is currently out of scope will definitely be requested in week four? What do we say when that happens?"
"What are we assuming is true that we've never verified? What if it's wrong?"
"Which stakeholder secretly disagrees with this plan but hasn't said it yet? When will they say it?"
"Which part of the technical plan are we least confident about? If that blows up, what does it cost us?"
"What is the one thing on the critical path that will take twice as long as we think? What is our buffer?"
"What will the on-call team say the first time they get paged after launch? Did we give them the tools to respond?"
Example Output: SSO Project Pre-Mortem
Common Facilitation Mistakes
Letting the project lead defend the plan
The project lead's job in a pre-mortem is to listen, not to respond. When someone names a failure mode, the project lead's instinct is to explain why that won't happen. Every time they do this, they shut down the next three people who were about to say something similar. The facilitator (ideally someone other than the project lead) should intercept any defensive responses: "We're not evaluating yet — let's just capture it."
Skipping the silent individual writing
When you go straight to group discussion, the loudest voice in the room sets the agenda and everyone else pattern-matches to what was already said. The two minutes of silent individual writing before group sharing is what generates the diverse perspectives that make pre-mortems valuable. Don't skip it even if the room feels awkward.
Producing findings with no owners
A pre-mortem that ends with a list of failure modes and no action items is a frustration exercise. The value is entirely in the prevention actions. For every failure mode in the top tier, there must be a named person, a specific action, and a date by which the action will be complete. Otherwise, the pre-mortem was a meeting, not a tool.
Running it at the wrong time
Pre-mortems run after significant resources are committed produce a different dynamic. People defend the plan because they've already invested in it. The findings still have value, but you've lost the chance to act on the most fundamental ones. Earlier is always better.
Teams that run pre-mortems regularly develop a cultural habit: they get comfortable saying "this is going to fail because of X" without it being a personal attack on anyone. That comfort — the ability to name problems out loud before they become crises — is worth more than any individual pre-mortem session. It is the foundation of a team that ships hard things reliably.
The Blank Facilitation Script
Project: _________________________________ Date: ___________
Facilitator: _____________________________ Attendees: _______ (target 5–8)
PHASE 1 — Set the premise (5 min)
Say: "Imagine it's [target date + 3 months]. The project failed completely. Write down all the reasons."
Silent individual writing: 2 minutes. No discussion.
PHASE 2 — Round-robin collection (20 min)
One item per person per round. Capture verbatim. No debate. Keep going until list stops growing.
Items collected: _____ (target 15–25)
PHASE 3 — Dot voting (10 min)
Each person gets 3 votes: "Which ones will actually happen?"
Top items (2+ votes): _________________________________________________
PHASE 4 — Root cause + prevention (30 min)
For each top item:
Failure mode: ____________________________________________
Root cause (one level deeper): ___________________________
Prevention action: ________________ Owner: ________________ By: ____________
PHASE 5 — Close (10 min)
Read back top 3–5 failure modes + actions + owners.
Follow-up review date: _______________
Summary doc owner: _______________ Sent by: _______________