What needs to be finished first
A concrete initiative, project or launch is described with scope, timeframe and success criterion.
Team culture allows uncomfortable truths to be spoken without sponsors or senior voices suppressing divergent views.
What needs to be ready before start
Whiteboard or digital board (Miro, FigJam); stickies in one color for risks, second color for mitigations; markers; timer; visible scenario ("It is 6 months later and the initiative has failed badly").
One facilitator; 4-10 participants from the project team, mixed functions and experience; optionally a note-taker; ideally a neutral external member (devil's advocate).
Initiative description; already known risks; experience from similar projects; timeframe and scope; stakeholder expectations.
20-45 min
Place scenario sentence at the top: "Imagine it is [target date + 3 months]. The initiative has failed. Why?" Set sticky zones for reasons for failure and mitigation. Set timer to 30 min.
The one question this method answers
What reasons could cause the initiative to fail, and which mitigations can we build in now to reduce these risks?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Invoke scenario | 5 min | Sponsor or facilitator briefly describes the initiative, then states the scenario sentence: "It is [X months later], and the initiative has failed." Pause for 30 sec for visualization. | Anyone who does not take the scenario seriously ("it will be fine") will not contribute real risks. Facilitator sets the tone: serious thought experiment, not pessimism. |
2Phase 2: Solo risk writing | 5-10 min | Each person silently writes 3-5 reasons for failure on stickies. Formulate concretely ("Stripe integration fails due to 3DS2 compliance"), not generically ("tech problems"). | Solo start avoids groupthink. Otherwise the loudest voices would define the risks. Silence forces diversity. |
3Phase 3: Collect and cluster | 10-15 min | Put stickies on the wall. The author briefly explains each sticky. Cluster similar ones. Consolidate duplicates. Cluster by category (Tech, People, Process, Market, External). | Clustering shows risk hotspots. If all stickies land in one category (for example only Tech), other perspectives are probably missing. |
4Phase 4: Assess probability and impact | 5-10 min | For each cluster or top risk, rate probability (low / medium / high) and impact (minor / moderate / critical). Mark top 5 (high probability x high impact). | Do not ignore risks with low probability but critical impact (tail risk). Show-stoppers matter even when unlikely. |
5Phase 5: Mitigation per top risk | 10-15 min | For each top-5 risk, define concrete mitigation (action that reduces probability or impact). Owner and date per mitigation. Integrate mitigation into project plan. | Mitigation must be concrete and assigned. "More tests" is not mitigation. "Stripe integration spike before Sprint 1, Owner @ben, CW 22" is one. |
What comes out at the end
Risk list with categorized risks (Tech, People, Process, Market, External), probability, impact and prioritized top risks; plus mitigation plan with owner, date and integration into project plan; assumption log for unclear assumptions.
Run Pre-Mortem at the start of an initiative, plus optional mid-point refresh. Track risk status (open, mitigated, occurred, discarded) over the lifecycle. After initiative end, compare Post-Mortem with Pre-Mortem predictions for learning.
Compact working template for Pre-Mortem with context, input, output artifacts, and next step.
Imagines future failure to identify risks in advance.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Initiative: New checkout flow including 3DS2 compliance, Apple Pay, inline validation. Launch planned for 2026-07-15.
Scenario: "It is 2026-10-15. The launch has failed. Conversion dropped by 15%, the compliance audit found gaps, the team is demotivated. Why?"
Tech (8 stickies)
People (3 stickies)
Process (4 stickies)
Market/External (3 stickies)
Recognize symptoms and steer against them
Risks are softened, "it will be fine", polished list.
Make scenario setup serious. Facilitator asks: "What would competitor XYZ or a security audit criticize?" Optimism kills Pre-Mortems.
Junior team members stay silent because the sponsor dismisses divergent views.
Sponsor leaves the room during solo writing. Collect stickies anonymously. Facilitator gives all voices equal weight.
"Technical problems", "team conflicts" without specificity.
Force concretization: what exactly goes wrong, how does it show up, how would we notice? Otherwise no mitigation can be derived.
Mitigations are formulated, but nobody takes responsibility.
Owner and date are mandatory for every mitigation. Without owner, mitigation is wishful thinking. Document it in the project plan or backlog.
Pre-Mortem is conducted, results land in the wiki, no integration into project plan.
Mitigations become sprint items or spikes. Top risks are visible in weekly status. Otherwise the Pre-Mortem was busywork.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.