Best when
- Use this when surfacing failure modes before execution.
- Use this when before major launch or transformation milestones.
- Use this when cross-team dependencies introduce hidden risk.
- Use this when leaders need proactive mitigation planning.
Method
Pre-mortem / Risk Storming
A structured risk workshop where participants imagine future failure, identify causes, and define mitigations early.
Why you were brought here
You came here from identify risks and failure modes.
- Choose this if the room needs a concrete next move for identify risks and failure modes.
- Back out if the room needs a different outcome than the one named here.
Pack = one session you can run now. Workspace = a saved thread for method choice, planning, and shareable outputs.
What Workspace helps you carry forward
- Brief the work
- Check the method fit
- Plan the session
- Prepare outputs you can share
Artifact preview
Risk register
De-risk · Low
Best when vs. Avoid when
Decide fit before you spend session time.
Avoid when
- Avoid this when the initiative is too early to discuss execution risk.
- Avoid this when the team treats risk discussion as blame assignment.
Room fit check
Is this the right room for this method?
Best when the team is close enough to execution that failure modes can be named concretely and acted on. This room has enough of the right conditions for the method to hold without extra ceremony.
Primary risk: The room lists generic risks instead of concrete failure stories.
Runbook
The core facilitation flow, with enough structure to run the method confidently in the room.
Standard setup for Mixed in remote delivery.
Total planned time: 90 min
Set future-failure scenario
What happens
Assume project failed and ask why.
Facilitator does
Read the scenario aloud and confirm the room accepts the premise before moving on. 'Imagine it is twelve months from now and this initiative failed' is stronger than asking people to speculate. If participants resist the hypothetical, acknowledge real stakes without letting defensiveness shut down the exercise.
Participants do
Accept the hypothetical premise fully before generating causes. If you find yourself resisting the scenario because the project is well-planned, that resistance is itself useful data — name it, then set it aside and participate as if the failure premise is true.
Output / signal of success
The failure scenario is written in a single sentence on the board and accepted by the room: "It is 12 months from now. This initiative has failed. We are conducting the post-mortem." At least one participant who was initially resistant to the premise has engaged with the hypothetical.
Watch for
Scenario is too vague to anchor specific failure causes.
Recovery tip
If participants resist the premise, acknowledge it directly: "The resistance you're feeling is useful — it means you're invested. But the session is more valuable when we take the premise seriously. Let's spend 10 minutes inside the hypothetical and see what comes up." Do not debate whether failure is likely.
Generate failure causes
What happens
Capture individual causes silently, then cluster.
Facilitator does
Run five minutes of individual silent generation. Push for specificity — not 'communication problems' but 'the delivery team found out about the scope change four weeks after the decision was made.' Hold all discussion until the board is loaded.
Participants do
Write causes as specific, named mechanisms — not "poor communication" but "the delivery team found out about the scope change four weeks after the executive decision was made." Specific causes produce specific mitigations. Vague causes produce vague responses.
Output / signal of success
20–30 specific failure causes are on the board. The most uncomfortable or politically sensitive causes are present — if the board contains only safe risks, the session hasn't done its job. Cross-team or cross-leadership failure causes should be visible.
Watch for
Failure causes stay at surface level instead of naming specific mechanisms.
Recovery tip
After the silent generation phase, ask: "Is there a cause on this list that anyone in this room would feel uncomfortable presenting to the sponsor?" If not, the room has self-censored. Ask each person to add one more cause that reflects a risk they privately believe in but haven't named.
Prioritize high-risk causes
What happens
Rank by likelihood and impact.
Facilitator does
Score on two axes — likelihood and damage — and require the room to name which causes they'd actually lose sleep over. Don't let anyone minimize a high-damage item because it 'probably won't happen.' Ask: what would need to be true for this to become real?
Participants do
Score each cause on two axes: how likely is it (given what we know today), and how much damage would it cause if it happened? For any cause scored high on damage, don't let likelihood discount it — ask instead: "What would need to be true for this to happen?" If the answer is plausible, the cause stays in the top tier.
Output / signal of success
The room has a clear shortlist and can explain why those choices matter more than the alternatives.
Watch for
Room converges quickly on familiar risks and overlooks structural or systemic causes.
Recovery tip
If the room is converging quickly on the same three familiar risks, call a pause. Ask: "What's a cause we haven't mentioned that we'd really not want to explain to a stakeholder?" The most uncomfortable answers are typically the ones that haven't been mitigated.
Define mitigations
What happens
Assign prevention and contingency actions.
Facilitator does
For each top risk, require a concrete mitigation with an owner, a checkpoint date, and a specific change to the current plan. Generic mitigations ('communicate better') don't count. If the room can't name a mitigation, that gap is data about the risk level of the initiative.
Participants do
Accept ownership only for mitigations you have the authority and access to implement. If the right mitigation requires action from someone outside the room, name that person as the owner rather than proxying for them.
Output / signal of success
Each top risk has a mitigation with: one named owner, one specific action (not "communicate better" but "schedule a bi-weekly dependency review with the engineering lead"), a checkpoint date, and a specific change to the current plan. Generic or action-free mitigations are rejected before the session closes.
Watch for
Mitigations are stated as intentions rather than as specific owner-action pairs.
Recovery tip
For each vague mitigation ("improve stakeholder communication"), ask: "What specifically will change, who will do it, and what will it look like when it's done?" Write the answer as three separate fields: the action, the owner, and the success signal.
Prep and materials
Prepare the room, the evidence, and the working surface so the session can stay focused on synthesis.
Minimum viable evidence
A sufficiently developed plan for the team to name specific failure modes — at minimum, a scope statement, a team, and a timeline. Running a pre-mortem before the initiative has enough shape to fail in specific ways produces generic risks that could apply to any project. The most useful pre-mortem sessions happen when the plan is clear enough that participants can describe the specific mechanisms by which it might fail.
Pre-work
Current plan
Optional
Risk categories
Optional
Mitigation owner tracker
Optional
Operational context note
Optional
Bring examples, pain points, or service evidence the room can point to quickly.
Room setup
Pre-mortem board
Optional
Remote facilitation choreography
Required
Pre-plan handoffs, breakout usage, and how people rejoin the main board.
Tools / materials
Pre-mortem board
Required
Shared digital board with timer and voting
Required
Keep instructions and voting visible at all times.
Templates
Pre-mortem board
Run well / recover fast
Keep the output usable, then use the recovery guidance when the room starts drifting.
What strong output looks like
- Make the output legible to both sponsors and delivery owners.
- A well-formed risk register has 4–8 prioritised risks, each with a named owner, a specific prevention or contingency action, a checkpoint date, and an explicit change to the current plan. The register includes at least one risk that was uncomfortable to name — cross-team failure, leadership decision risk, or a strategic assumption failure. A weak register contains only execution-level risks that the room controls, vague mitigations ("monitor closely"), and no tail risks despite the initiative having high stakes.
What this does not produce
A pre-mortem produces a prioritised risk register with mitigation commitments. It does not prevent failures — it produces the early warning system and the response plan. Teams that complete a pre-mortem and file the register without reviewing it against actual project developments miss the entire value of the method.
Red flags to correct before closing
- Generalized risks without owners.
- Ignoring low-probability high-impact risks.
- Re-state decision objective and expected artifact
- Timebox discussion and force owner assignment
- State what the artifact is confident about versus what still needs tailoring.
Failure mode
The room generates risks they're comfortable with and avoids politically sensitive ones
Why it happens
The pre-mortem premise creates a safe space in theory, but in practice participants self-censor risks that would implicate senior stakeholders, popular decisions, or the sponsor's preferred approach. The result is a risk register that covers execution risks the room controls and avoids strategic risks the room is uncomfortable naming.
Recover now
If this happens, ask directly: "Which risk on this board, if we named it in an executive review, would create the most discomfort?" That risk needs to be on the register. Name it explicitly and ask who would own mitigation if it were true.
Prevent next time
Next time, before Step 2 opens, say: "The most useful risks are the ones nobody wants to say out loud. This session only has value if those risks appear on the board." Give people 2 minutes of individual silent generation before any group sharing — privacy reduces self-censorship.
Failure mode
Mitigations are stated as intentions rather than as specific owner-action pairs
Why it happens
Under time pressure at the end of a session, the room accepts vague mitigation language ("we'll improve communication," "we'll track this more closely") because it sounds like progress. The mitigation register looks complete but contains no actionable commitments. Two weeks later, nothing has changed because nobody was specifically accountable for anything.
Recover now
If this happens, read each mitigation aloud and apply the test: "Could I check on this in two weeks and have a specific conversation about whether it happened?" If not, it needs a named owner, a specific action, and a date.
Prevent next time
Next time, build the mitigation step as a three-field exercise from the start: "action / owner / checkpoint date." Do not allow one-line mitigations that skip any of the three fields.
Failure mode
Low-probability, high-impact risks are deprioritised because they seem unlikely
Why it happens
Scoring by likelihood and impact should place rare-but-catastrophic risks high on the register. In practice, "likelihood" scores are influenced by recency and personal experience — risks that feel abstract get rated as low-likelihood even when their potential impact is significant. The register ends up focused on familiar medium-impact risks and misses the tail risks that could actually end the initiative.
Recover now
If this happens, before finalising the register, scan for any risk scored high-impact but low-likelihood. For each one, ask: "What would need to be true for this to happen?" If the answer is plausible under certain conditions, raise the likelihood score and build a mitigation. Low-probability risks with catastrophic consequences need contingency plans even if prevention isn't realistic.
Prevent next time
Next time, in the prioritisation step, explicitly ask: "Are there any risks on this board that would end the initiative if they materialised?" Those items belong in the top tier regardless of their likelihood score.
Adjust for your room
Change the shape of the session only after the fit and runbook are clear.
Open adjustment controlsStandard setup for Mixed in remote delivery.
Standard variant for Mixed in remote delivery. Waypoint is adapting timing, facilitation emphasis, prep, and recovery guidance here, but the room still needs final tailoring to the exact stakes and participants.
What to do next
Use this after you have checked the fit and know you want to carry the method forward.
The pack is the fastest way to run this now. Use the links below when you need prep, sharing, or a saved reference point.
Guides
Read why this works
The secondary fit is narrower but real: the book strongly supports deliberate failure-imagination, premortem review, and structured challenge before a recommendation hardens into a decision artifact.
Open this when you want stronger rationale before choosing the method or taking it into the workspace.
Critical Thinking for Strategic Intelligence
A judgment-discipline brief on how to stop polished discovery outputs from outrunning the evidence beneath them by exposing assumptions, testing rival explanations, and showing confidence honestly.
References
Sources and references used in this method page.
- Harvard Business Review - Performing a Project Premortem
Klein, G. (2007) Project premortem method.
Reviewed 2026-02-27 by Discovery Waypoint Editorial Team