Pre-mortem technique to spot blind spots before decisions

A pre-mortem is a short, facilitated meeting practice used before a decision or project launch. Teams assume the outcome is a failure and then list reasons why that failure happened. The goal is not pessimism but to surface overlooked risks, hidden dependencies, and unexamined assumptions that a standard plan-focused discussion can miss.

It is concrete, time-boxed, and collaborative. A facilitator frames the scenario, each person contributes possible failure causes, and the group clusters and prioritizes those causes to produce mitigation actions or checkpoints.

Key characteristics:

Used well, a pre-mortem balances creative skepticism with practical follow-up—teams leave with a shorter, clearer list of what to watch and what to change.

**Social pressure:** Teams default to agreement or polite support in meetings, which hides doubts.

**Confirmation bias:** Groups often seek information that confirms the chosen plan instead of challenging it.

**Sunk-cost thinking:** Once time or resources are committed, people are less willing to consider alternatives.

**Overconfidence:** Teams underestimate complexity and overrate their control of variables.

**Narrow framing:** Discussions focus on the immediate problem and miss related risks or wider context.

**Information silos:** Key facts or dissenting data are held by people not present in the decision meeting.

**Time pressure:** Short deadlines encourage quick buy-in rather than careful probing of weaknesses.

Team meetings where everyone nods but implementation later uncovers missed issues.

Proposals accepted quickly with little challenge from quieter members.

Repeated surprises in projects that seemed well-reviewed in planning sessions.

Decisions made with optimistic timelines and few contingency checks.

Action lists that lack monitoring points for early warning signs.

Single-person decisions presented as finished plans with limited team input.

Meeting agendas that focus on solutions and skip systematic risk listing.

Post-launch retrospectives that identify obvious risks that were never discussed.

Approaching a major launch or go/no-go decision.

High-stakes budget or resource commitments.

Tight deadlines that cut discussion time.

New technologies, vendors, or partners introduced into a plan.

Cross-functional handoffs with unclear ownership.

Low prior failure transparency (no history of honest post-mortems).

Executive pressure to present a confident timeline or forecast.

Teams that have recently experienced a surprising failure.

Schedule a short pre-mortem (20–45 minutes) near decision points to make it routine.

Use silent writing first: give everyone 5–10 minutes to list failure reasons before speaking.

Rotate facilitators so different roles shape risk framing and reduce dominance.

Ask everyone to describe how the failure looks (symptoms) rather than who’s at fault.

Cluster similar items and ask the group to vote on the top 3 risks to address.

Convert top risks into concrete mitigations, tests, or monitoring metrics with owners and deadlines.

Keep the tone systematic: emphasize exploration over blame and prioritize learning.

Capture and share the session notes and track the mitigation items in the project plan.

Invite a cross-functional reviewer not involved in the plan to offer fresh perspectives.

Time-box the exercise and include it on the standard decision checklist so it isn’t skipped.

If debate stalls, use a quick red-team or devil’s-advocate role to argue the most likely failure points.

Run mini pre-mortems for subcomponents rather than one long session for complex programs.

Post-mortem / retrospective: Post-mortems analyze causes after an actual failure; pre-mortems anticipate possible failures before they happen and aim to prevent them.

Devil’s advocate: Both inject critical viewpoints; a devil’s advocate is usually a single role, while a pre-mortem elicits distributed critique from the whole team.

Red teaming: Red teams simulate adversarial attacks or scenarios; pre-mortems are quicker, lower-cost workshops focused on likely failure causes rather than full adversarial testing.

Scenario planning: Scenario planning explores multiple future states and strategy responses; pre-mortems focus narrowly on one assumed failed outcome to reveal blind spots for a specific decision.

Checklists: Checklists standardize actions and checkpoints; pre-mortems generate content that can be turned into effective checklists before launch.

Confirmation bias: A cognitive bias that favors supporting evidence; pre-mortems work to counteract confirmation bias by creating structured opportunities for negative evidence.

Groupthink: A social dynamic where dissent is suppressed; pre-mortems reduce groupthink by soliciting anonymous or private inputs before discussion.

Risk register: A formal list of risks and mitigations; pre-mortems populate and prioritize entries for that register based on team input.

Retrospective bias: Tendency to interpret past events as more predictable after the fact; pre-mortems try to surface issues before outcomes are known to avoid hindsight rationalization.

Root cause analysis: Post-failure technique to find underlying causes; pre-mortems surface plausible causes early so root-cause work may be avoided or reduced by prevention.