How to Run a Pre-Mortem Without Turning It Into Pessimism

A pre-mortem begins with a deliberately false statement: the plan has already failed. The team then works backward to explain how. The fiction is useful because it loosens the social grip of the current plan. People who hesitate to challenge a proposal can describe a future failure without having to declare that the leader is wrong.

The exercise is not fortune-telling. It does not prove that the imagined failure will occur, and it should not become a competition to invent cinematic disasters. Its value is practical: surface plausible pathways while there is still time to change the plan, define warning signals and assign ownership.

Use it when the plan is real enough to fail

Run a pre-mortem after the goal, owner and rough plan exist but before major commitments become difficult to reverse. It works well before a launch, migration, purchase, trip, policy change, automation or public claim. It is weaker when the question is still “what should we do?” because participants have no concrete plan to interrogate.

Scale the exercise to consequence. A reversible personal choice may need ten quiet minutes. A system touching money, safety, rights, customers or irreplaceable data deserves more participants, evidence and follow-through. The Reversibility Test helps choose that depth.

Step 1: freeze the plan

Write one paragraph stating the intended outcome, deadline, scope, key dependencies and who can stop or change the work. Record what is explicitly out of scope. If the plan changes during the exercise, note the change rather than quietly moving the target.

Include assumptions that carry the plan: a vendor will deliver, users will understand the interface, the source data is current, the backup restores, the weather window holds or a reviewer will be available. Assumptions hidden in conversation are difficult to test.

Step 2: state a specific failure

Move to a date shortly after the intended result and say: “The project failed in a way that mattered.” Define what that means. Missed deadline, unsafe outcome, unusable result, cost overrun, public correction, lost data and low adoption are different failures.

Do not begin with causes. Begin with the observable outcome. “The automation failed” is vague. “It sent the wrong file to 200 recipients and there was no recall path” creates something the group can reason about.

Step 3: generate causes independently

Give each participant several quiet minutes to write plausible reasons. Independent generation reduces anchoring on the first confident speaker and gives quieter domain experts room to contribute. Ask for causes across five layers:

• Goal: the success condition was ambiguous or conflicted with another objective.
• Evidence: data was stale, incomplete, misread or drawn from the wrong population.
• Execution: time, skill, capacity or a dependency was missing.
• Control: warnings, approvals, rollback or testing failed.
• Environment: a vendor, policy, user behavior or physical condition changed.

For AI-assisted work, add prompt ambiguity, source failure, fabricated support, model or tool changes, privacy exposure, unreviewed automation and loss of a human stop point. The aim is not to blame the model. It is to map the whole system.

Step 4: separate pathways from stories

A plausible sentence is not yet a risk finding. For each proposed cause, ask what evidence supports it, what mechanism connects it to the failure and what would have to be true. “Users will hate it” becomes useful only when translated into a mismatch, such as a required workflow taking twice as long or an accessibility barrier blocking a group.

Mark each item as observed, inferred, expert judgment or speculative. Speculation is allowed; disguising it is not. Combine duplicates but preserve meaningful differences in mechanism.

Step 5: rank by decision value

Do not multiply invented precision. A simple high, medium or low judgment for likelihood and consequence is often enough. Add detectability and recovery cost when they change the response. The priority is not the scariest scenario. It is the scenario for which action now has meaningful value.

Some risks should be accepted. A low-consequence failure with a cheap recovery may not deserve another meeting. Some risks transfer to a qualified professional, insurer or specialist. Some require redesign. Record the choice.

Step 6: convert risks into controls

For the top three to five pathways, choose a response:

1. Prevent: change the plan so the cause is less likely.
2. Detect: create a measurable warning before the consequence grows.
3. Contain: limit scope, permissions, audience or exposure.
4. Recover: prepare rollback, restore, refund, repair or communication.
5. Accept: state why the remaining risk is proportionate.

A control needs an owner and evidence. “Test it” is weak. “Sam restores the backup to a separate device by Thursday and records the result” is a control. “Keep an eye on quality” is weak. “Pause publication if two sampled claims lack direct source support” is a trigger.

Step 7: define stop and shorten signals

Before optimism returns, name the conditions that change the plan. These can be stop signals, review signals or scope reductions. Examples include a missed dependency date, error rate above a threshold, unresolved safety question, failed restore test, unavailable reviewer or a source that no longer supports the central claim.

Triggers should be visible to the person with authority to act. A dashboard no one checks is not detection. A warning without permission to pause is theater.

Step 8: assign ownership without assigning blame

The risk owner watches the signal and coordinates the response. The owner is not automatically the person morally responsible if the risk occurs. Keep causal, role and remedial responsibility distinct, as described in Automation Does Not Remove Responsibility.

Record who can approve exceptions, who communicates externally and who performs recovery. If every role belongs to “the team,” none may exist when pressure arrives.

Step 9: close the exercise

End with the revised plan, not the imagined wreckage. Read back the changes, owners, triggers and accepted risks. Time-box unresolved research. Put decisions into the same work system that holds the project, not a separate document nobody will revisit.

Schedule one check at the earliest meaningful warning point. Do not run the entire pre-mortem every week. Review whether controls were completed and whether new information changed the priority risks.

A ten-minute solo version

1. Write the intended result and deadline.
2. Imagine one ordinary failure, not a catastrophe.
3. List five causes without editing.
4. Circle the two with the highest combination of consequence and preventability.
5. Add one prevention, one early warning and one recovery step.
6. Put each action on the calendar or checklist.

Use a decision journal to preserve what you expected before the outcome. Otherwise hindsight will make the known failure look obvious and the avoided ones look imaginary.

What to avoid

• Do not use the exercise to defeat a decision already made by inventing unlimited objections.
• Do not let seniority decide which risk is “real” before independent generation.
• Do not confuse a long risk list with control.
• Do not assign safety, legal, medical, financial or technical judgments beyond participants' competence.
• Do not leave without owners, triggers and a revised plan.

The bottom line

A good pre-mortem creates temporary permission to doubt and permanent improvements to the plan. It does not predict the future. It exposes assumptions, makes failure paths discussable and turns a small number of them into owned controls.

Imagine the failure briefly. Return to the present with work someone can actually do.

Research and framework notes

• Gary Klein, Performing a Project Premortem, the foundational managerial description of the method.
• NIST, Guide for Conducting Risk Assessments, for threat, vulnerability, likelihood, impact and uncertainty concepts.
• NIST AI Risk Management Framework, Playbook, for mapping context, measuring risk, managing controls and governing responsibility.
• NASA, Lessons Learned Information System, an institutional example of carrying observed failures forward into planning.