A project pre-mortem asks a team to imagine that a future project failed and then work backward to identify plausible causes. The exercise is useful when it converts imagination into reviewable failure modes, early-warning signals, owners and decision triggers. It is weak when it becomes a creative list of worries with no action.
This guide provides a copyable PREMORTEM-9 template and a 45-minute facilitation plan.
The short answer
Run a pre-mortem after the project has a proposed objective, scope, plan and owner, but before major commitments become difficult to reverse. Ask participants to work independently first, then combine and test failure modes. Finish with a bounded risk register update and explicit decisions.
Do not use a pre-mortem to replace normal risk management, technical assurance, legal review or safety analysis. It is a structured way to uncover assumptions and dissent earlier.
Copyable PREMORTEM-9 template
| Field | What to record | Example |
|---|---|---|
| P — Project outcome | the intended result and deadline | launch self-service onboarding by 30 November |
| R — Ruin statement | a neutral statement that the project failed | adoption stalled and service workload increased |
| E — Event or cause | a specific plausible failure mode | customer identity data did not reconcile |
| M — Mechanism | how the cause creates the failure | duplicate records trigger failed verification |
| O — Observable warning | an early signal and threshold | reconciliation exceptions exceed 3% in pilot |
| R — Response | prevention, contingency or experiment | run a 500-record reconciliation before rollout |
| T — Trigger decision | what happens if the threshold is crossed | stop expansion and return to data remediation |
| E — Executive owner | one accountable decision owner | onboarding product director |
| M — Monitoring date | when evidence is reviewed | weekly during pilot; formal gate on 15 October |
The two most important fields are Observable warning and Trigger decision. Without them, the output is only a concern list.
A 45-minute facilitation plan
1. Re-state the project boundary — 5 minutes
Show the objective, success measure, deadline, in-scope work, key dependencies and decisions already made. Clarify that the exercise tests the plan; it does not evaluate individual competence.
2. Announce the failure — 3 minutes
Use a concrete prompt: “It is six months after launch. The project missed its intended outcome and created material rework. What happened?” Avoid dramatic catastrophe wording unless the project genuinely concerns safety or resilience.
3. Generate independently — 7 minutes
Each participant writes three to five causes in silence. Independent generation reduces anchoring on the most senior voice. Ask for mechanisms, not labels. “Poor communication” is too broad; “the service team learned of the workflow change after customer messages were approved” is testable.
4. Combine and clarify — 10 minutes
Group duplicates, but preserve different mechanisms. A data problem, unclear authority and missing training may all appear under “readiness”; they require different owners and tests.
5. Select material failure modes — 8 minutes
Rate each cause on three dimensions from one to five:
- plausible within the project context;
- impact on the stated outcome; and
- detectability before harm.
Use the simple priority score:
priority = plausibility × impact × (6 − detectability)
A high score does not prove probability. It directs attention toward plausible, material causes that are harder to see early.
6. Define warnings and responses — 8 minutes
For the highest-priority modes, name one observable signal, a threshold, evidence source, prevention action, contingency and owner. Prefer leading indicators over late outcome measures.
7. Make decisions — 4 minutes
Decide which items change the plan, enter the risk register, require an experiment, need specialist review or remain accepted with monitoring. Record who approved the decision and when it will be reviewed.
Worked example
A company plans to introduce an AI-assisted knowledge tool for frontline service teams.
| Failure mode | Mechanism | Early warning | Response | Decision trigger |
|---|---|---|---|---|
| outdated answers reach customers | source content has no owner or review date | more than 2% of pilot answers cite expired guidance | restrict retrieval to controlled sources; assign content owners | pause external use until the stale-source rate is below threshold |
| agents over-trust fluent output | interface does not expose source or uncertainty | reviewers cannot identify supporting evidence in sampled answers | require citations and human confirmation for consequential answers | disable automatic suggestions for the affected workflow |
| handle time rises | staff must check multiple systems because integration is incomplete | median pilot handle time increases by more than 10% | test a narrower use case and improve handoff design | do not scale beyond pilot until time returns within guardrail |
| privacy boundary is breached | prompts include customer data outside the approved purpose | any confirmed unauthorized data field in logs | minimize fields, enforce access and review logs | trigger incident process and suspend the use case |
The pre-mortem did not predict the future. It created earlier, cheaper tests and explicit stop conditions.
Failure-mode categories to prompt the room
Use categories only after independent generation so they do not narrow thinking too early.
| Category | Useful prompt |
|---|---|
| outcome | Did the project deliver activity but not the intended result? |
| customer or user | Which need, behavior or access condition was misunderstood? |
| scope and requirements | Which ambiguity created rework or incompatible expectations? |
| dependency | Which supplier, system, approval or team was assumed to be available? |
| data and technology | Which quality, security, integration or recovery condition failed? |
| people and capacity | Which skill, workload or adoption assumption proved false? |
| governance | Which decision had no owner, evidence or escalation path? |
| economics | Which cost, demand, price or benefit assumption broke? |
| transition and operations | What failed after handover, not during build? |
Common pre-mortem errors
Treating every worry as a risk
Require a cause, mechanism and affected outcome. If the team cannot describe the chain, record it as an open question rather than a scored risk.
Voting away minority evidence
A low-frequency concern may come from the one person who understands the dependency. Keep the evidence and ask what observation would confirm or refute it.
Creating mitigations with no owner
“Improve communication” is not an action. Name the artifact, channel, audience, deadline and accountable owner.
Measuring only final failure
Late indicators such as budget overrun or missed launch are useful outcomes but poor early warnings. Look for prerequisite failure: unresolved interface decisions, defect escape, unowned data, supplier delay or low pilot completion.
Never revisiting the output
Attach review dates to the project cadence. Close, revise or escalate items as evidence changes.
How to use the template responsibly
For regulated, safety-critical, security or high-value work, combine the pre-mortem with the organization's approved risk, assurance and incident processes. Do not place sensitive threat details in broadly shared notes. Preserve dissent, evidence and decision authority without attributing speculative blame to individuals.
Learning pathway
MTF Institute's Professional Certificate in Project Management develops practical work across project planning, risk, delivery, stakeholder coordination and decision evidence. It is professional, non-degree education and does not guarantee a project outcome or career result.