---
name: Klein Pre-Mortem
status: draft
territory: future-exploration
host_mode: pre-mortem-action
also_loadable_in: []
msi_wired: false
sources:
  - title: Klein, Gary (2007), "Performing a Project Premortem," Harvard Business Review 85(9):18-19
    url: https://hbr.org/2007/09/performing-a-project-premortem
  - title: "Mitchell, Deborah J., J. Edward Russo & Nancy Pennington (1989), \"Back to the Future: Temporal Perspective in the Explanation of Events,\" Journal of Behavioral Decision Making 2(1):25-38"
    url: https://doi.org/10.1002/bdm.3960020103
---

# Klein Pre-Mortem

## Why it matters

The best time to discover why a plan will fail is *before* you start — and the trick that unlocks it is to stop asking "what could go wrong?" and instead declare, as a fact, that it already *did*.

For example: a team is about to launch a product. Everyone's optimistic, the meeting is all logistics and dates. Then someone reframes it: "Imagine it's a year from now and this launch was a total, embarrassing disaster. Take five minutes and write down *why*." The room changes. Out come the worries people had been quietly sitting on — the dependency no one actually owns, the market assumption nobody tested, the timeline half the team privately thinks is impossible. Asking "what are the risks?" got polite nods. Declaring the failure a done deal and asking "why *did* it fail?" got the truth.

- **What it reveals.** The specific failure pathways a committed, optimistic team has stopped voicing — surfaced while there's still time to prevent them.
- **How it changes the read.** You stop asking *"is this plan good?"* (which invites defense) and start asking *"it failed — why?"* (which invites honesty).
- **When to foreground it.** Any plan, launch, or decision that's formed but not yet locked, especially where consensus has gelled and contrarian input has gone quiet.
- **What you'd miss without it.** That the goal isn't a list of generic risks but a trace from each imagined failure back to a *decision you can still change today*.
- **Where it misleads.** It only works as foresight — projecting a *hypothetical* future failure; turn it on a problem already happening and it's just risk assessment wearing a costume, and run as ritual without changing the plan, it's theater.

## How to invoke it in Ora

You have a plan, launch, or decision that's taken shape but isn't yet committed, and you want its failure modes surfaced *now* — honestly, not after the fact.

Describe the plan and ask:

> "Pre-mortem this launch plan: imagine it's failed completely six months out — what went wrong, and which of today's decisions could still prevent each one?"

The Klein pre-mortem is the foundational protocol of this analysis. Ora projects a concrete future-failure state, generates the plausible reasons *independently* (to dodge groupthink), prioritizes them, and — the step that makes it actionable — traces each cause back to a specific present decision, with the early warning sign to watch and the mitigation to take before commitment.

One thing to know: phrases like *pre-mortem*, *imagine this failed*, *prospective hindsight*, *what would the post-mortem say*, or naming Klein are what route you here. Bring a plan that's still changeable — the value is in catching failures while the decisions that cause them are still open.

State the failure as having *happened*, not as a worry. "Imagine it failed — why?" generates far more, and better, reasons than "what might go wrong?" — that grammatical flip is the whole mechanism, and the analysis leans on it hard.

One thing Ora won't do: accept generic doom. Every cause must trace to a named decision, design choice, or assumption you can still alter; a failure you "couldn't have known about" is logged as residual risk, not dressed up as a mitigation.

## How it works

Gary Klein is a psychologist who spent his career studying how experts — firefighters, nurses, pilots — actually make decisions under pressure, and he kept noticing a depressing pattern in groups. Once a team commits to a plan, dissent evaporates. Nobody wants to be the wet blanket. Optimism becomes a kind of social obligation, and the people with the sharpest instincts about what might go wrong — who often *know*, in their gut, the weak point — go quiet, because raising it now feels like disloyalty or foot-dragging. The plan sails forward with its fatal flaw unspoken, to be discovered, expensively, later.

Klein also knew about a curious experiment. The researchers Deborah Mitchell, Edward Russo, and Nancy Pennington had found that the *grammar* you use to ask about the future dramatically changes how well people can reason about it. Ask someone to imagine a future event and explain why it *might* happen, and they generate a modest list. But tell them the event *has* happened — past tense, a done deal — and ask them to explain *why it did*, and they produce about thirty percent more reasons, and more concrete ones. Certainty unlocks the imagination in a way that possibility doesn't. They called it *prospective hindsight*: looking back on a future you've been told already occurred.

Klein put the two together into a ritual so simple it sounds like a trick, and called it the **premortem**. Before a plan is executed — while it can still be changed — you gather the team and say: "Imagine it is months from now. This project has failed. Completely. It was a fiasco. Now, each of you, on your own, take a few minutes and write down every reason you can think of that it failed." Three things in that setup do the work. The *past-tense failure* invokes prospective hindsight, so the reasons flow. The word *independently* — each person writing alone before anyone speaks — protects the quiet experts from the loudest voice and from the pull of consensus, surfacing pathways a group discussion would have smothered. And the framing gives social permission: you're not attacking the plan, you're doing an assigned exercise, so the gut-level doubt finally gets said out loud.

But the premortem's real payoff is in what you do with the list, and it's the step amateurs skip. Generating failures is not the point; *tracing them home* is. For each plausible cause, you ask: where, in the plan as it stands *right now*, is the decision, the assumption, or the design choice that could avert this — and what's the early warning sign that this pathway is activating? "The team lacked alignment" is not actionable; "we approved the staffing plan without naming an alignment owner" is a decision you can change this afternoon. A cause that can't be traced to a present decision is either too vague to use or genuinely outside your control, and it goes in the residual-risk pile, honestly labeled. Done right, the premortem converts a room full of unspoken misgivings into a short list of specific, preventable failure pathways — each tied to a lever you can still pull. Done as a box-ticking ritual that produces a list nobody acts on, it's worse than nothing, because it launders the plan with the appearance of rigor.

## Framework & implementation

*This section uses Ora's own terms for the parts of an analysis, so that if you open the actual mode and lens files they line up. Each is glossed in plain language on first use.*

### Pipeline execution

The Klein pre-mortem is the **foundational** lens of the Pre-Mortem Action analysis — `foundational: true` in its lens file, and the mode's required lens. As a `lens_type: protocol`, it supplies the mode's procedure. It sits in the mode's **`ANALYTICAL PERSPECTIVES`** block under "always loaded," alongside its facilitation sibling (premortem-analysis) and the biases the projection guards against (hindsight-bias, narrative-instinct). The mode runs at **Gear 4**, Ora's most thorough setting — a **Depth analyst** and a **Breadth analyst** work the plan in parallel, critique each other, and revise.

**Where the lens engages.** It activates on its **Detection Signals** — a plan or design formed but not yet locked; a launch with alteration still feasible; a decision converging on one course with contrarian input thin. Its **Application Steps** run the six-step protocol: familiarize with the plan, project a concrete past-tense **failure state**, generate plausible causes *independently*, aggregate and prioritize by likelihood × severity, **trace each cause back to a current decision point**, and produce warning signs plus pre-commitment mitigations.

**What it produces in the analysis.** The mode's output sections are this protocol made explicit. The projected failure seeds a **Failure mode inventory** (each classed execution / assumption / context-shift / interaction / motivational, and grounded in a *plan-specific mechanism* rather than a generic trope). **Causal pathways to failure** trace each mode from its breakage point through the cascade; **Leading indicators per failure mode** name the observable early signal and its lead time; **Pre-commitment mitigations** name the test, decision-gate, or kill-criterion that locks in *before* commitment (a mitigation that can only be taken after failure begins is reshaped here); and **Residual unmitigated risks** honestly carries what can't be traced to a present decision.

**Cross-adversarial evaluation.** At Gear 4 each analyst's reading is critiqued by the other, which catches the lens's signature failures — keyed to its **Critical Questions** and **Common Failure Modes**: generic doom-mongering instead of specific cause-tracing (**pessimism trap**); projecting only failures that confirm a prior view of the plan's weaknesses (**confirmation projection**); causes that tie to no alterable decision (**cause without decision point**); a ritual that changes nothing (**theatrical pre-mortem**); and one narrow failure story when the plan has several distinct failure modes (**single-failure tunnel**). The evaluator presses the load-bearing checks: *is the failure projected as a hypothetical future, and does each cause trace to a decision the team can still alter?*

**Honesty discipline.** The mode requires that mitigations be *integrated* — it produces a revised plan and checks the diff against the original, defeating the theatrical-pre-mortem failure. And it guards the **confirmation-projection** trap by steelmanning the plan before projecting its failure, so the exercise surfaces pathways the analyst would *not* have predicted rather than confirming the ones they already suspected.

**What the analysis will not do.** It will not accept a cause that traces to no present decision as a mitigation (it's logged as residual risk), will not treat an already-occurring problem as a "projected" failure (that's risk assessment or root-cause analysis), and will not let a single failure scenario stand in for a plan's multiple distinct failure modes.

### Origin and evidence

The protocol is Gary Klein's, set out in his 2007 *Harvard Business Review* article "Performing a Project Premortem" and situated within his broader work on naturalistic decision-making (*Sources of Power*, 1998; *The Power of Intuition*, 2003). Its empirical engine is the **prospective hindsight** finding of Mitchell, Russo, and Pennington (1989): asking people to explain a future event as though it had already happened increases the reasons they can generate by roughly 30%. The method was popularized for a wide audience by Daniel Kahneman, who in *Thinking, Fast and Slow* singled out the premortem as one of the most effective and underused debiasing techniques — a cheap institutional remedy for the overconfidence and groupthink that sink committed plans. It has retrospective and adversarial siblings (the project post-mortem; red-teaming) but is distinguished by being *prospective* and *cooperative* — done by the plan's own team, before commitment.

### Applications and common uses

The premortem is a working tool wherever a plan is about to be committed and its failure modes need surfacing while they're still preventable.

- **Project and product launches.** Its native ground: catching the unowned dependency, the untested assumption, the doubted timeline before launch, and tying each to a decision still open.
- **Strategy and major investments.** A debiasing gate before a big commitment, where optimism and sunk-cost momentum most suppress dissent.
- **Risk management and safety.** Pairing with failure-pathway and barrier models (Swiss cheese, normal accidents) to find where defenses are thin *before* the incident.
- **Policy and program design.** Surfacing implementation failure modes — the gap between the plan on paper and contact with reality — early enough to design around them.
- **Personal high-stakes decisions.** A career move, a house purchase, a venture: imagining it as a finished failure and asking why generates the concrete concerns a hopeful "should I?" suppresses.

In every case the payoff is the same: a committed, optimistic group's unspoken misgivings converted into specific failure pathways, each traced to a present decision and a pre-commitment mitigation — foresight bought cheaply, before the cost is real.

### Failure modes and when not to use it

The lens's characteristic ways of going wrong are catalogued in its **Common Failure Modes**:

- **Pessimism trap.** Failure projection degenerates into generic doom ("everything fell apart") rather than specific cause-tracing. Re-prompt for concrete pathways: "the failure happened because X, caused by Y, a consequence of decision Z."
- **Confirmation projection.** Projecting only failures that match the analyst's prior view of the plan's weaknesses. Steelman the plan first, then run the pre-mortem against the steelmanned version, so unexpected pathways surface.
- **Cause without decision point.** Every cause identified, none tied to a decision the team can alter. Reframe the cause narrowly to find the lever, or accept it as out-of-scope and document it as residual risk.
- **Theatrical pre-mortem.** The protocol run as ritual with no mitigation integrated into the actual plan. Require a revised plan and check the diff; a premortem that changes nothing is worse than none.
- **Single-failure tunnel.** One narrow failure scenario imagined when the plan has several distinct failure modes. Run parallel projections, one per major mode.

**When not to reach for it.** When the failure is already happening — not a projection but a present problem — use risk assessment or root-cause analysis; the premortem's value depends on the failure being counterfactual. When the plan is genuinely locked and unchangeable, the exercise can only catalog regrets, not prevent them (though it may still inform monitoring). And when there's no real plan yet — only a vague intention — there's nothing concrete to project a failure *of*; shape the plan first, then pre-mortem it.

## Related

- **Pre-Mortem Action** — the analysis this lens founds; projects a plan's failure, traces it to present decisions, and outputs pre-commitment mitigations.
- **Premortem Analysis** — the facilitation sibling: the meeting design (independent silent writing, round-robin disclosure) that surfaces the causes without the loudest voice anchoring the room.
- **Hindsight Bias** — the retrospective cousin the premortem co-opts: the same "of course it failed, it was obvious" clarity, borrowed *before* the failure instead of after.
- **Taleb Fragility and Antifragility** — a complementary lens on which failure modes a plan is structurally exposed to, beyond the ones a team happens to imagine.

## Sources

- [Klein, Gary (2007), "Performing a Project Premortem," Harvard Business Review 85(9):18-19](https://hbr.org/2007/09/performing-a-project-premortem)
- [Mitchell, Deborah J., J. Edward Russo & Nancy Pennington (1989), "Back to the Future: Temporal Perspective in the Explanation of Events," Journal of Behavioral Decision Making 2(1):25-38](https://doi.org/10.1002/bdm.3960020103)