Make dissent useful before a commitment becomes a failure: imagine the plan has already gone badly wrong, surface causes independently and turn credible concerns into action.
In one minute
A Premortem begins after a team has a real plan but before irreversible execution. The facilitator states a specific future failure as fact: “It is ninety days after launch, and this effort failed badly.” Participants silently and independently write reasons why. The team then shares, clusters and tests those reasons, prioritises the most decision-relevant risks and assigns mitigations, evidence, owners and triggers.
The imagined failure temporarily legitimises criticism and helps expose concerns that ordinary planning, optimism and hierarchy can suppress. It does not predict the future, estimate probability reliably or replace specialist risk analysis.
Best for: a consequential plan that is sufficiently concrete to challenge but still changeable.
Avoid when: the plan has not been explained, psychological safety is absent, or a regulated quantitative risk assessment is required.
The problem it addresses
Teams become attached to a preferred plan. Senior advocacy, sunk effort and the desire to appear constructive can silence weak signals. A standard “What might go wrong?” question often produces familiar risks or waits for the loudest person.
Prospective hindsight changes the prompt. Independent generation preserves distinct knowledge before group discussion converges. The method improves the risk conversation; it does not prove that listed causes are real or complete.
When to use it
Use a Premortem when:
- a launch, migration, decision or transformation has a working plan;
- material assumptions remain uncertain;
- several disciplines see different failure mechanisms;
- hierarchy or momentum may discourage challenge;
- the team still has authority and time to change the plan;
- outputs can be assigned to owners and followed up.
When not to use it
Do not use it:
- before participants understand the plan and intended outcome;
- after a real incident—use Root Cause Analysis;
- as a substitute for FMEA, quantitative safety analysis or mandated assurance;
- to create a theatrical risk list with no actions;
- to blame people or solicit rumours about individuals;
- when speaking honestly could expose participants to retaliation without protection;
- when leaders have already removed the team’s ability to change anything.
Inputs required
Prepare:
- the plan, desired outcome, scope, horizon and success criteria;
- assumptions, dependencies, decision gates and irreversible commitments;
- available evidence and known unknowns;
- a diverse participant group close to the work and its consequences;
- a psychologically safer way to contribute, including silent or anonymous input if needed;
- an owner for the resulting risk actions and review.
Step-by-step process
1. Establish the decision boundary
Explain what is planned, what has been decided, what remains changeable and what success means. A Premortem cannot repair a vague plan.
2. Define a concrete failed future
Choose a plausible review date and state that the effort failed materially. Describe failure in outcome terms without supplying causes: customers abandoned it, the migration was reversed or the intended benefit did not appear.
3. Generate causes independently
Give participants several quiet minutes to write one mechanism per note. Ask for causes, not symptoms or blame. Preserve unusual items before discussion.
4. Share round-robin
Collect one item from each person per round. Do not debate, merge or rank until the independent knowledge is visible. Allow confidential channels for sensitive concerns.
5. Clarify and cluster
Group genuine duplicates while preserving materially different mechanisms. Translate vague claims into causal statements: condition, mechanism and consequence.
6. Test against evidence
Mark each item observed, inferred or speculative. Add supporting and contradictory evidence, uncertainty and what could be checked quickly. Novelty is not validity.
7. Prioritise for decisions
Consider consequence, plausibility, detectability, time to act and reversibility. Avoid multiplying uncalibrated scores into false precision. Escalate high-consequence uncertainties even when probability is unclear.
8. Design responses
For priority risks choose one or more responses: change the plan, test an assumption, reduce exposure, add prevention or recovery, create a trigger, or accept the risk through authorised governance.
9. Assign ownership and evidence
Record the action, owner, due date, evidence of completion, residual risk and escalation path. “Monitor” is incomplete without a signal and threshold.
10. Revisit at decision gates
Review the register before irreversible commitments and after material changes. Add evidence, close invalidated risks and deepen important mechanisms with PDPC, FMEA or Bow-Tie when appropriate.
AI automation lens
AI can anonymise and cluster independently generated notes, compare risks with approved lessons learned, detect unowned actions and draft neutral mechanism statements.
It must not:
- generate the participant list and call it independent dissent;
- score probability from fluency or frequency of mention;
- expose sensitive authorship or infer who raised a concern;
- discard rare high-consequence mechanisms as outliers;
- accept residual risk or remove a decision gate;
- replace specialist safety, legal, security or regulatory analysis.
Human decision owners decide which concerns change the plan and whether residual exposure is acceptable.
Visual model
Text alternative: start from a concrete plan, assume a specific future failure, generate causes independently, clarify and test them, then convert priority risks into owned actions and decision-gate reviews.
Interactive example
Scenario
A manufacturer will launch an AI-assisted supplier portal in six weeks. The sponsor describes adoption as inevitable. Suppliers have not tested exception orders, identity data comes from two systems and the fallback process exists only in a slide deck.
Your move
Write three failure mechanisms and convert one into an action with evidence and a trigger.
Worked answer
Possible mechanisms: smaller suppliers cannot complete identity checks and return to email; conflicting master data blocks valid orders; the untested fallback cannot handle peak demand after an outage. The last item becomes: run a representative fallback simulation with Operations and five suppliers by 18 September; evidence is completed orders, queue time and error log; the launch pauses if the fallback cannot process the agreed peak volume within four hours. The action tests a mechanism instead of merely adding “portal outage” to a list.
Facilitation notes
- Say the failure statement in the past tense and make it outcome-specific.
- Protect silent independent generation before discussion.
- Invite roles with direct, customer, control and delivery knowledge.
- Separate a mechanism from a person’s name.
- Ask what evidence would raise or lower concern.
- End with owners and decision effects, not a photographed wall.
Expected output
- a concrete failure scenario and scope;
- independently generated failure mechanisms;
- clusters with evidence and uncertainty;
- prioritised risks and residual exposure;
- plan changes, tests, protections and triggers;
- named owners, due dates and review gates.
Common mistakes
- Premature discussion. The first confident explanation anchors everyone else.
- Generic disaster. “It failed” needs a date and outcome boundary.
- Blame list. Names obscure mechanisms and damage safety.
- Popularity as probability. Frequently mentioned risks are not automatically most likely.
- Risk register theatre. Unowned concerns do not strengthen the plan.
- Method overreach. Premortem elicits risks; it does not replace assurance.
Quality checklist
- Participants understand the plan, success and changeable decisions.
- The failed future is concrete and outcome-based.
- Causes were generated independently before convergence.
- Distinct mechanisms remain visible after clustering.
- Evidence, uncertainty and alternatives are recorded.
- Priority criteria include consequence and time to act.
- Actions have owners, evidence, dates and triggers.
- High-stakes risks receive the required specialist analysis.
Template
| Failure mechanism | Evidence / uncertainty | Consequence | Time to act | Response | Owner / due | Trigger / residual risk |
|---|---|---|---|---|---|---|
| Condition → mechanism → failure | Observed, inferred or speculative | Who or what is affected | Reversibility and detection | Change, test, prevent, recover or accept | Named role and date | Signal, threshold and escalation |
Use the structured Premortem workspace after the Premortem session exercise to turn contributions into a governed action record.
Knowledge check
Question: Eight participants independently list a rare but catastrophic control failure; current data cannot estimate its probability. What should the team do?
A. Ignore it because probability is unknown.
B. Escalate the uncertainty, define evidence or specialist analysis and avoid uncalibrated numerical certainty.
C. Set probability to eight percent.
D. Accept it because several people agreed.
Answer: B. Premortem surfaces a mechanism; consequence and uncertainty determine the next analysis, not the number of notes.
Related tools
- Process Decision Program Chart turns a plan into explicit failure branches and countermeasures.
- FMEA analyses failure modes, effects and controls more systematically.
- Bow-Tie Analysis maps threats, a top event, consequences and barrier assurance.
- Root Cause Analysis investigates an event that has actually occurred.
References
- Klein, Gary. “Performing a Project Premortem.” Harvard Business Review, September 2007. Article (opens in a new tab). Accessed 7 September 2026.
- Klein, Gary. “The Premortem Technique.” Author resource (opens in a new tab). Accessed 7 September 2026.
- Agency for Healthcare Research and Quality. “Premortem Tool.” AHRQ resource (opens in a new tab). Accessed 7 September 2026. Sector-specific application; not a substitute for required clinical risk systems.
Method profile
- Primary output: evidence-qualified risks converted into owned plan changes and tests.
- Decision level: project, launch or consequential plan.
- Evidence strength: exploratory until mechanisms are tested or supported.
- Review trigger: decision gate, scope change, new evidence or material incident.