Pre-Mortem: How to Run One, With a Template and Example (2026)
A pre-mortem is a meeting you hold before a project starts, where the team imagines the project has already failed and works backward to explain why. It is the opposite of a post-mortem. Instead of dissecting a failure after the damage is done, you surface the likely causes while there is still time to prevent them. The trick is the framing: assuming failure has happened, rather than asking whether it might, pulls risks into the open that a normal planning meeting never reaches.
The technique comes from research psychologist Gary Klein, who set it out in a 2007 Harvard Business Review article. This guide covers what a pre-mortem is, why the framing works, how to run one in six steps, a worked example, and how it differs from a post-mortem. There is an interactive facilitator below that runs the exercise and exports your results as the first draft of a risk register.
Quick answer: what a pre-mortem is
A pre-mortem is a risk exercise run at the start of a project. The team imagines it is the future and the project has failed completely. Each person writes down every reason they can think of for that failure. The group consolidates the reasons, and for each one decides on an action to prevent it. The whole thing takes about 30 minutes.
The reason it beats a normal "what could go wrong" discussion is the grammar. Asking a team to imagine a failure that has already happened, rather than one that might, frees people to voice doubts they would otherwise keep quiet. It is the cheapest risk-identification method there is, and it produces a ready-made starting point for a risk register.
Run a pre-mortem
Use the facilitator below as a reusable pre-mortem template. Add each reason the project failed, then a preventive action and an owner for each. When you are done, copy the list out and it becomes the first draft of your risk register.
Pre-mortem facilitator
Run the exercise the way Gary Klein describes it. Add each reason the project failed, then capture one preventive action and an owner for each. Copy the result out and it becomes the first draft of your risk register. Three example causes are loaded to start.
Imagine it is launch day and the project has failed badly. Looking back, why did it fail?
Failure causes and preventions
Each row is a risk you can carry straight into a risk register: the cause is the risk, the prevention is the response, and the owner is the owner. Copy the list to take it there.
A pre-mortem is only worth it if the actions get tracked.
Drop each prevention onto a Rock board with an owner, and the risks you surfaced stay visible through the project instead of dying in the meeting notes. One flat price, unlimited users.
What is a pre-mortem?
A pre-mortem (also written pre mortem or premortem) is a risk-identification technique from research psychologist Gary Klein. He set it out in a September 2007 Harvard Business Review article, "Performing a Project Premortem." A post-mortem examines a failure that has happened. A pre-mortem examines one that is imagined to have happened, before the project begins. The shift from "what could go wrong" to "what did go wrong" is the entire method.
"Unlike a typical critiquing session, in which project team members are asked what might go wrong, the premortem operates on the assumption that the patient has died, and so asks what did go wrong." - Gary Klein, Harvard Business Review (2007)
That small change has a large effect. In a normal planning meeting, raising doubts can feel like disloyalty, so people who see problems stay quiet. By making failure the premise rather than the question, a pre-mortem gives everyone permission to be a critic. The quiet skeptic who would never say "I think this will fail" will happily explain, in detail, why the project that already failed did so.
Why a pre-mortem works
The method rests on a documented cognitive effect called prospective hindsight: imagining that an event has already occurred, rather than that it might occur. Research by Mitchell, Russo, and Pennington in 1989 found that prospective hindsight increases a person's ability to correctly identify reasons for a future outcome by around 30 percent. Klein built the pre-mortem directly on that finding.
It also works against the optimism that grips a team once a plan is set. Daniel Kahneman champions the pre-mortem in Thinking, Fast and Slow as one of the few practical defenses against overconfidence and groupthink. It legitimizes dissent at the exact moment a group is most inclined to suppress it. The team has committed to a plan, morale is high, and that is precisely when the unspoken risks are most dangerous.
The practical payoff is threefold. It surfaces risks a checklist would miss, runs in about 30 minutes, and produces a list of concrete causes you can act on. Each cause becomes a candidate for the risk register, with the prevention as its response.
How to run a pre-mortem in six steps
Klein's method is deliberately simple, and the simplicity is the point. The whole exercise fits in half an hour and needs nothing but the team, a timer, and somewhere to write.
- Gather the team and brief the plan Get everyone working on the project in one room or call, ideally three to ten people. Make sure they all understand the current plan: the goal, the timeline, and the approach. The pre-mortem works because of the diversity of viewpoints, so include the people doing the work, not only the managers.
- Set the scene: the project has failed Ask the team to imagine it is the future and the project has been a complete failure. Not "might fail," but "has failed." This framing is the heart of the technique, so say it plainly: "It is six months from now. This project was a disaster. What happened?"
- Everyone writes independently Give the team a few minutes to write down, alone, every reason they can think of for the failure. Independent writing first is essential. It stops the loudest voice from anchoring the room and surfaces concerns people would not say out loud in open discussion.
- Share round-robin Go around the group, each person reading one reason from their list, until every reason is on the board. No debating or defending during this round. The facilitator records each cause as it is read. Round-robin sharing gives quieter members equal airtime.
- Consolidate and prioritize Group similar causes together and focus on the ones the team judges most likely or most damaging. You do not need to score every item. The goal is to agree on the handful of failure causes worth acting on now.
- Assign actions and owners For each priority cause, decide one preventive action and name one owner accountable for it. This is the step that turns the exercise into prevention. Capture the causes, actions, and owners in your risk register so they are tracked through the project, not forgotten after the meeting.
Pre-mortem example
Here is a pre-mortem for a fixed-fee website build, the kind a small team might run at kickoff. The team imagined the launch had failed, listed the causes, and assigned a prevention and an owner to each. The result reads like the opening of a risk register, which is exactly what it becomes.
| Why it failed (the cause) | Prevent it by (the action) | Owner |
|---|---|---|
| Scope grew past the fixed fee and we ate the cost | Lock scope in the SOW, price a change-order rate, log every request | Account lead |
| The client went quiet and approvals stalled the timeline | Put approval deadlines in the contract with a slip clause | Project manager |
| The one developer who knew the stack left mid-build | Document the build weekly, cross-train a second developer | Founder |
| A third-party API was not ready and we found out in week eight | Build and test the integration in week one as a spike | Tech lead |
| We never aligned on what "done" meant, so launch slipped on rework | Write acceptance criteria into the kickoff and get sign-off | Project manager |
Notice that none of these are exotic. They are the ordinary ways small projects fail, and the team knew them all along. The pre-mortem simply created the moment to say them out loud and write down what to do about each. That is the whole value: not predicting the unpredictable, but capturing the predictable before it bites.
Pre-mortem vs post-mortem
The two are mirror images, and a good team runs both. A pre-mortem happens before the work, imagines failure, and is about prevention. A post-mortem or retrospective happens after the work, examines what actually happened, and is about learning. The pre-mortem asks "what could sink this?" The post-mortem asks "what did, and what do we change next time?"
They feed each other. The causes a post-mortem finds on one project become the prompts a pre-mortem starts with on the next. That builds a memory of how the team's projects really fail. Run the pre-mortem at kickoff to set the risk register, review the register through delivery, and hold the post-mortem at the end to feed the next cycle.
A pre-mortem is also not the same as a risk register or a risk matrix. The pre-mortem is the meeting that generates the risks. The register is where they live and get tracked, and the matrix is how they get prioritized. The pre-mortem comes first and hands its output to the other two.
Common pre-mortem mistakes
The exercise is simple, which makes it easy to run badly. These are the failure modes that drain the value out of it.
- Asking "what could go wrong" instead of "what did" If the facilitator softens the framing back to the conditional, the whole effect is lost. The technique only works when the team treats the failure as something that has already happened. Say "it failed," not "it might fail."
- Discussing out loud before writing Open the meeting with a group discussion and the first confident voice anchors everyone else. Always start with a few minutes of silent, independent writing so the full range of concerns reaches the board.
- Surfacing risks and then doing nothing A pre-mortem that ends with a list and no owners is a venting session. Every priority cause needs a preventive action and a named owner, captured somewhere it will be reviewed.
- Running it too late A pre-mortem held after the plan is locked and resources are committed can only document risks, not prevent them. Run it while the plan can still change, at or just before kickoff.
- Inviting only the managers The people doing the hands-on work see the failure modes the planners miss. A pre-mortem with only leadership in the room produces a thinner, more optimistic list than one with the whole team.
What we recommend at Rock
The risk with any pre-mortem is that the energy stays in the meeting and the actions never get tracked. The fix is to land the output somewhere the team already works. Among teams who use Rock, the pattern that sticks is to turn each prevention into a card on the project board the moment the meeting ends.
In practice the facilitator runs the exercise, then the causes, actions, and owners go straight onto a board in the project space, one card per risk. The card carries the owner and the action, and it sits next to the actual project tasks, so the weekly review covers it without a separate meeting. The pre-mortem stops being a one-off event and becomes the first entry in a risk register the team actually maintains.
Pairing the pre-mortem with a project charter at kickoff works well. The charter sets the goal and scope, the pre-mortem stress-tests it, and the board holds both from day one.
Free resource: the Project Management template gives you a space with boards ready to hold tasks and the risks your pre-mortem surfaces, side by side.
Frequently asked questions
What is a pre-mortem in simple terms?
A pre-mortem is a meeting at the start of a project where the team imagines the project has already failed and lists every reason why. For each likely reason, the team decides on a preventive action and an owner. It is a fast way to surface risks while there is still time to act on them.
Where does the pre-mortem come from?
The technique was developed by research psychologist Gary Klein and popularized by his 2007 Harvard Business Review article "Performing a Project Premortem." It is based on prospective hindsight, a cognitive effect shown by Mitchell, Russo, and Pennington in 1989 to improve people's ability to identify reasons for a future outcome by about 30 percent.
How long does a pre-mortem take?
About 30 minutes for a typical project. A few minutes to brief the plan, a few minutes of independent writing, a round-robin to collect the causes, and a short session to consolidate and assign actions. It is one of the highest-value-per-minute exercises in project management.
What is the difference between a pre-mortem and a post-mortem?
A pre-mortem runs before the project, imagines a failure, and is about prevention. A post-mortem runs after the project, examines what actually happened, and is about learning. The pre-mortem asks what could sink the project; the post-mortem asks what did and what to change next time. Strong teams run both.
Who should run a pre-mortem?
The project manager or team lead usually facilitates, but the whole team should take part, including the people doing the hands-on work. Their range of viewpoints is what surfaces the failure modes a managers-only meeting would miss. Three to ten participants is a good size.
How is a pre-mortem different from a risk register?
A pre-mortem is the meeting that generates risks; a risk register is the document that tracks them. The pre-mortem produces a list of failure causes and preventions, which becomes the first draft of the register. The register then carries those risks, with owners and statuses, through the rest of the project.
A pre-mortem costs half an hour and surfaces the risks your team already senses but would not otherwise say. Run it at kickoff, assign an owner to every prevention, and carry the list into a register you keep reviewing. Rock keeps chat, tasks, and your risk list in one workspace. One flat price, unlimited users. Get started for free.
