A post-mortem is what you do after a project collapses. You gather the team, reconstruct the sequence of events, and arrive at a list of things you should have caught earlier. It is useful. It is also too late.
The pre-mortem runs the same process in reverse. You assume, before the decision is made or the project is launched, that it has already failed spectacularly. Then you ask: what went wrong?
That simple inversion is surprisingly powerful. It turns out that humans are much better at explaining failure than predicting it. Give someone a blank page and ask them what might go wrong, and you get a thin list of sanitized risks. Tell them it has already gone wrong and ask them why, and the details come flooding out.
Gary Klein, the cognitive psychologist who formalized the pre-mortem in the 1990s, found exactly this in his research on decision-making under pressure. The technique has since become a fixture in certain corners of corporate strategy and military planning. What it has not become, in most organizations, is a consistent operational habit.
This article is for the operators who want to change that. Not for the project manager running a retrospective, but for the director or department head who needs to pressure-test a consequential decision before committing resources to it.
Why Most Risk Reviews Do Not Work
Before getting into the mechanics, it is worth being honest about why standard risk reviews tend to fail.
The typical format is a meeting where someone presents a plan, a slide appears listing known risks, and the group offers incremental amendments. There are three problems with this.
The plan is already invested. By the time a risk review happens, the person presenting has usually spent weeks building the proposal. The psychological cost of admitting a fatal flaw is high. The group senses this and acts accordingly.
Criticism feels like obstruction. In a live meeting, raising a serious concern about a plan reads as opposition to the person who built it. People pull their punches. The risks that get named are the ones that feel safe to name.
The framing is hypothetical. Asking "what could go wrong?" keeps everyone in a predictive, probabilistic headspace. The answer is usually a list of low-probability edge cases rather than a clear-eyed look at the structural vulnerabilities in the plan itself.
The pre-mortem sidesteps all three problems. The plan has already failed (hypothetically), so there is nothing left to protect. The question is not "could this go wrong?" but "how did this go wrong?" That shift from the conditional to the past tense is what unlocks honest thinking.
What a Pre-Mortem Actually Is
The process Klein describes is clean. Here is the core of it:
The team reviews the plan in detail, as they normally would.
The facilitator says: "Imagine we are twelve months from now. This project failed. It did not just underperform; it failed badly. Take two minutes and write down every reason you can think of for why it failed."
Each person reads their list aloud, one item at a time, round-robin, until all the distinct failure modes are on the table.
The group does not debate the items in the room. The output is a ranked list of failure modes that the team then takes back to the plan.
That is the original format. It is good. For operators working without a large team, it needs adaptation.
The Operator's Version: Pre-Mortem Analysis for Individual Decision Makers
Most of the writing on pre-mortems assumes you have a room full of people. But a significant number of consequential decisions are made by individuals or by very small groups. A head of department approving a new vendor. A director deciding whether to kill a product line. A founder choosing between two strategic directions.
For those situations, the social dynamic that makes the pre-mortem work (everyone writes independently, then shares) is not available. You need a different approach.
The operator's pre-mortem is a structured solo exercise that borrows Klein's core insight, the retrospective imagination, and applies it through a series of directed lenses. Instead of relying on a group to surface different failure modes, you deliberately rotate through the perspectives most likely to reveal blind spots.
Here is how to run it.
How to Run a Pre-Mortem Analysis: A Step-by-Step Process
Step 1: Write the Decision Clearly
Before anything else, write a one-paragraph description of the decision you are making and what success looks like. Be specific. "We are approving a 24-month contract with Vendor X for our CRM migration, with a go-live target of Q3 and a budget of £180,000. Success is a fully operational system with no data loss and adoption above 70% within 90 days of launch."
If you cannot write this paragraph cleanly, the decision is not ready to be stress-tested. That itself is useful information.
Step 2: Set the Scene
Write the failure statement in past tense, twelve months out. "It is [Month, Year+1]. The CRM migration failed. We are over budget, behind schedule, and adoption is below 30%. Several team members have left. We are considering reverting to the old system."
The specificity matters. Vague failure prompts produce vague answers.
Step 3: Work Through the Six Failure Lenses
This is the core of the pre-mortem analysis. Work through each lens in writing, giving yourself at least five to ten minutes per lens. Do not rush. The value comes from depth, not speed.
Lens 1: The Assumptions That Were Wrong
Every plan rests on assumptions. Most of them are never written down. Under this lens, list every assumption baked into your decision and ask which ones, if wrong, would be most damaging. For the CRM example: you assumed the vendor's implementation team was experienced. You assumed internal adoption could be managed without a full-time change manager. You assumed the data migration from the old system was straightforward. Which of those would hurt most if false?
Lens 2: The People Who Will Resist
Execution depends on people. Who has the most to lose from this decision? Who was not consulted and will feel that absence? Who has tried something similar before and failed? Who will comply in the meeting and drag their feet afterward? Name them. Name their likely objection. Decide whether the plan accounts for it.
Lens 3: The Timing Risks
Most plans assume a stable context. They rarely get one. What is happening in the next twelve months that could destabilize the conditions your plan requires? A leadership change, a budget cycle, a competitor move, a regulatory shift. Which of those could derail the work even if you execute flawlessly?
Lens 4: The Complexity You Are Underestimating
This is the lens most often skipped. Every plan has a step that is described in a single sentence but represents weeks of difficult, uncertain work. Find that step in your plan. Now find the next one. What would need to be true for both of them to go smoothly? Have you ever seen both go smoothly at the same time?
Lens 5: The Success Metric That Is Wrong
Sometimes plans fail not because execution breaks down but because the definition of success was wrong from the start. Will the number you are optimizing for actually tell you the plan worked? Or will hitting the metric produce a result that nobody wanted? The CRM project might hit 70% adoption in 90 days, but if the 30% who did not adopt are the highest-value users, the metric told a false story.
Lens 6: The Thing Nobody Said Out Loud
In most decision processes, there is at least one concern that was felt but not voiced. Sometimes it is political. Sometimes it feels too uncomfortable to raise. Sometimes the person who felt it was the most junior person in the room. What is the concern in this decision that you noticed but set aside? Write it down. Look at it directly.
Step 4: Rank the Failure Modes
You now have a list of potential failure modes. Sort them by two dimensions: how likely, and how damaging if they occur. The top-right quadrant (likely and damaging) is your risk register. The top-left (damaging but unlikely) deserves a contingency plan. The bottom-right (likely but manageable) needs a mitigation built into the execution plan.
Step 5: Revise the Decision or the Plan
The pre-mortem is not a reason to kill decisions. It is a tool for improving them. For each high-priority failure mode, ask: can we redesign the plan to reduce this risk? Can we add an early tripwire that will tell us we are heading in this direction before it is too late? Can we reduce the scale of the commitment until we have more information?
The output of the pre-mortem is not a risk list. It is a better decision.
The Pre-Mortem and the Decision Memo
A pre-mortem is most valuable when its output is captured in a structured format that travels with the decision. The failure modes you identified, the assumptions you surfaced, the contingencies you built in. Without that, the work lives only in your head and evaporates the moment the decision is made.
This is where the Decision Memo format becomes useful. A good decision memo documents not only what you decided and why, but what you considered and discarded, what risks you acknowledged, and what would cause you to revisit the decision. The pre-mortem analysis feeds directly into that structure. The assumptions you challenged, the failure modes you ranked, the tripwires you named: all of it belongs in the memo.
If you run a pre-mortem and then write the decision in an email or a Slack message, you have done the hard thinking and thrown away the artifact. The memo is how the thinking survives the moment.
Common Mistakes in Pre-Mortem Analysis
Treating it as a risk register exercise. The pre-mortem is not about listing risks in a spreadsheet. It is about vividly imagining a specific failure and working backward. The imagination is the mechanism. Strip it out and you are just doing standard risk management.
Running it too early. The pre-mortem needs a fully formed plan to work against. Running it before the plan is clear means working against a moving target. Get the plan to 80% before you stress-test it.
Running it alone and too fast. Even for individual decision makers, it helps to sleep on the pre-mortem before finalizing the output. The subconscious continues working on the problem. Things you missed on day one show up on day two.
Not updating the plan. A pre-mortem that produces a list of risks and then is filed away has not done its job. The output should change something. If it did not, the exercise was performative.
Stopping at one failure scenario. Klein's original research involved a single catastrophic failure. For complex strategic decisions, it is worth running two or three distinct failure scenarios, not just one. The CRM project might fail through slow adoption, but it might also fail through vendor collapse or internal political conflict. Each scenario surfaces different failure modes.
When to Use a Pre-Mortem
The pre-mortem is not appropriate for every decision. Routine operational decisions do not warrant it. Decisions that are easily reversible do not need it either.
Use it when the decision involves a significant, hard-to-reverse commitment. A new hire at the director level. A major vendor contract. A product pivot. An acquisition. A significant budget reallocation. A new market entry. Anything where being wrong is expensive and slow to correct.
The rough heuristic: if the decision would appear in a board report, run a pre-mortem first.
The Pre-Mortem Template: A Summary
For quick reference, here is the structure of the operator's pre-mortem:
Step 1. Write the decision clearly. One paragraph. Include the success criteria.
Step 2. Write the failure scenario in past tense. Specific, detailed, twelve months out.
Step 3. Work the six lenses:
Assumptions that were wrong
People who will resist
Timing risks
Complexity you are underestimating
Success metrics that are misleading
The thing nobody said out loud
Step 4. Rank failure modes: likelihood vs. damage.
Step 5. Revise the decision or the plan.
Step 6. Capture the output in a decision memo.
