How to Run a Premortem Before a Decision

How to Run a Premortem Before a Decision

A premortem asks a team to imagine that a proposed decision has failed and explain why. The exercise changes the conversation from "What might go wrong?" to "It went wrong. What caused it?"

The value comes after the ideas. A failure story should become a signal, control, owner, response, and exit rule.

flowchart LR
    A["Define proposed decision"] --> B["Assume failure"]
    B --> C["Generate causes independently"]
    C --> D["Group and test causes"]
    D --> E["Assign indicator, control, and owner"]
    E --> F["Set response and exit rule"]

1. Choose the right moment

Run the premortem after the team understands the proposed decision and alternatives but before final approval or irreversible commitment.

Too early, and participants lack enough detail. Too late, and status, sunk cost, or authority can make dissent unsafe.

State whether the exercise informs, recommends, or approves. A premortem does not replace the decision authority.

2. Define the decision

Write the option, owner, deadline, intended result, affected people, assumptions, constraints, and alternatives.

Name the time horizon. A decision can succeed at launch and fail six months later because of maintenance, adoption, cost, safety, or vendor dependency.

3. Assume a specific failure

Ask participants to imagine a future date when the decision has clearly failed. State the observable failure without assigning blame.

The method draws on prospective hindsight. Gary Klein's premortem page describes the practical exercise as beginning after a team has been briefed on a plan.

Use more than one failure definition where needed. A product can fail financially, operationally, legally, ethically, or for affected users.

4. Generate causes independently

Give each participant quiet time to write causes before discussion. Independence reduces anchoring and gives less powerful participants a chance to preserve concerns.

Ask for causes involving assumptions, evidence, customer behavior, operations, security, privacy, safety, accessibility, regulation, partners, staffing, incentives, measurement, cost, and recovery.

Do not ask participants to make the stories polite.

5. Collect before debating

Gather every cause. Clarify wording without evaluating the author.

Group duplicates only after the original statements are preserved. Two similar concerns may rely on different evidence or affect different people.

Avoid a quick vote that lets familiarity defeat a rare but severe risk.

6. Test each material cause

Ask what evidence supports the cause, what evidence contradicts it, how likely it is, how severe the result could be, who is exposed, and how detectable it would be.

Distinguish a cause from a symptom. "Customers leave" may be the outcome. The causes could include weak value, poor reliability, data concerns, price, support, or a competitor.

Outcome-bias research indexed by PubMed is a reminder that later results can make causes look obvious. Preserve the premortem before launch.

7. Convert causes into controls

For each material risk, define an early indicator, preventive control, detective control, owner, deadline, response, and residual risk.

A control should be testable. "Communicate better" is not enough. Name the audience, message, channel, timing, owner, and measure.

If no practical control exists, the decision maker should explicitly accept, reduce, transfer, delay, or reject the risk.

8. Set stop and exit rules

Define the signal and threshold that triggers review, pause, rollback, or termination. Assign who can act and how quickly.

An exit rule protects the team from explaining away repeated evidence after commitment.

Include a recovery path. A reversible decision is only reversible if the organization can execute the reversal.

9. Protect dissent

Record minority views and what evidence would change them. Do not punish a participant because the risk did not occur.

The later replication of outcome-bias research supports the broader reason to judge decision contributions without letting the outcome dominate.

Psychological safety is not enough if the person lacks information, time, or authority. Give reviewers the material needed to contribute.

10. Integrate the decision record

Attach the premortem to the decision journal. Link the risks, controls, owners, thresholds, approvals, and review date.

After the outcome, compare actual causes with the premortem. Credit useful early warnings, identify blind spots, and update the next template.

Know the limits

A premortem can overproduce vivid stories, anchor a team on failure, duplicate formal risk work, or become theater.

It does not replace security threat modeling, safety analysis, legal review, scientific validation, financial diligence, clinical review, or regulated risk management where those are required.

Use it as a structured dissent and anticipation method. Its success is not the number of risks named. It is whether the decision changes, controls become real, and the organization can detect and respond before failure becomes irreversible.

AI assisted with research organization, structure, drafting, and validation. Dalton Anderson remains the attributed author and final editorial authority. The transcript and linked public sources control factual claims. Publication remains unauthorized.