What a pre-mortem is
A pre-mortem is a structured risk identification exercise developed by Klein Associates founder and decision-research psychologist Gary Klein. The technique flips the conventional risk-workshop question. Rather than asking the team "what could go wrong?", the facilitator asks them to assume that twelve months have passed, the project has failed, and the press release announcing the failure has just been written. The team's job, working individually and silently, is to write down all the reasons why this failure occurred. The facilitator then collects the responses, reads them anonymously, and uses them as the basis for structured discussion.
The technique works because of a well-documented quirk of human cognition: people generate causal explanations more readily when given a reference point than when asked to imagine abstract future risks. Asking "what could go wrong?" puts the brain into hedging mode; asking "the project failed — explain why" puts it into explanation mode, which is the mode that generates concrete answers. The same person who can't articulate a vague concern in a meeting will write three specific paragraphs about how a failure unfolded.
In UK project controls practice, the pre-mortem is the qualitative front end of the quantitative risk analysis (QRA) pipeline. The risks surfaced in a pre-mortem feed the risk register; the register feeds the QRA; the QRA produces the cost and schedule confidence ranges that the funding decision rests on. A pre-mortem that surfaces a major risk the register would otherwise have missed therefore changes the contingency calculation, the P80, and the cost case the sponsor sees.
The facilitation script
A pre-mortem takes 60 to 90 minutes. Schedule it as a standalone session, not as the last item on an existing risk-workshop agenda — the framing change matters and gets lost when the previous discussion has been about something else. The room should have one chair per participant arranged at a table they can write on, not auditorium-style. Eight to twelve participants is the sweet spot. Below six and the diversity-of-thinking benefit is lost; above twelve and the discussion phase becomes unwieldy.
Open with two minutes of context. State the project, the scope, the deliverable, the budget, and the timeline. State the assumption: it is twelve months from now (or whatever the natural failure-realisation horizon is for the programme), the project has failed badly, costs significantly overran, the programme slipped, the client is unhappy. State the task: write down, individually and in silence, all the reasons you think this failure occurred. There is no wrong answer; quantity matters as much as quality. They have 10 minutes.
During the writing phase, the facilitator stays silent. If a participant pushes back ("how am I supposed to know why it failed?"), respond once with "make it up — what story would explain it?" and then withdraw. The cognitive trick of the pre-mortem only works when participants commit to the assumption that the failure has already happened. Letting them debate whether the failure is possible defeats the exercise.
Collect the responses anonymously. The facilitator reads each entry aloud without attribution and writes a short summary on a flip chart or whiteboard, grouping similar entries as they emerge. After every entry has been read, work through the groups one by one. For each group: is this a risk the existing register captures? If yes, does the pre-mortem add specificity that the register lacks? If no, is the gap because the risk is genuinely novel, or because the existing register categorisation is too coarse to surface it? The goal is not to relitigate every risk; it is to identify the items that the formal process missed.
The questions that work — and the ones that don't
The wording of the failure-framing question matters more than the rest of the script combined. The framing that works on UK infrastructure and defence programmes is: "It is twelve months from now. The project has failed. Costs are significantly over, the programme has slipped, and the client has lost confidence. Write down the reasons why." The wording is short, declarative, and concrete. It names specific failure modes (cost, schedule, client confidence) rather than asking about generic failure.
Framings that don't work in practice: "What might go wrong on this project?" — too generic, returns the same hedged answers a brainstorm would. "Imagine the project was a complete disaster" — too dramatic; participants either reject the framing or generate cartoon answers. "What's your biggest concern?" — puts participants on the spot, triggers self-censorship, returns the lowest-common-denominator concerns. The Klein framing works because it specifies the failure type without specifying the cause, which is what we want the participants to generate.
A second question that pays off, asked at the end of the discussion phase: "Which of the risks we've identified would you bet money on being the actual cause if the project did fail?" This forces participants to commit to a prioritisation rather than treating all risks as equally weighted. The risks that get bet on are the candidates for high-impact mitigation in the next phase of work.
Common pitfalls
The first pitfall is running the pre-mortem too early. Before the team has enough shared context — typically before the scope is defined, the team is in place, and the broad approach is understood — the pre-mortem returns generic project-management risks rather than programme-specific ones. The right window is after the team can describe what the project actually involves but before the plan has solidified to the point where challenging it feels disloyal.
The second pitfall is running it as a group brainstorm instead of an individual written exercise. The cognitive mechanism only works when participants commit to writing answers in silence. Group discussion at the input stage triggers the same social dynamics that suppress risks in a conventional workshop — vocal participants frame the conversation, junior participants defer, contrarian views go unstated. The discussion happens after the writing, not during.
The third pitfall is letting the outputs drift back into the risk register without further work. A pre-mortem entry that says "the contractor underestimated the scaffolding requirement" is a failure narrative, not a risk register item. It needs to be parsed into a discrete risk ("scaffolding scope is under-quantified at tender stage"), a probability, an impact range, and an owner before it can feed the QRA. Skipping the parsing step is the most common reason pre-mortem outputs don't change the eventual cost case.
The fourth pitfall is doing it once and then not doing it again. A pre-mortem at the start of the project is high-value; a second pre-mortem at the start of each major phase or after a significant scope change is also high-value, because the team's knowledge of the programme has updated. Many of the most useful risks come from the second pre-mortem, not the first — they're the risks that only became visible after some delivery effort.
Using the outputs in QRA
The pre-mortem's value to project controls compounds when the outputs are explicitly integrated into the QRA. Three connections matter. First, individual risks identified in the pre-mortem that aren't on the register get added with their probability, impact range, and a brief narrative justification — typically two to five new register entries per session on a programme that hasn't had a pre-mortem before. Second, existing risks on the register often get their probability or impact distributions recalibrated based on the pre-mortem discussion — the team's confidence intervals widen when the failure narrative makes the upside-risk side more vivid. Third, the pre-mortem surfaces correlation between risks that the register treats as independent — if multiple failure narratives share the same underlying cause (a key supplier, a regulatory approval, a technical interface), the QRA model should reflect that correlation rather than understating the joint risk.
On UK MoD CADMID and IPA-gated programmes, a documented pre-mortem also functions as evidence of robust risk identification at the gateway review. Reviewers familiar with the technique recognise that a register supported by a pre-mortem has had at least one structured challenge to its completeness — that is meaningfully different from a register that emerged only from category-based brainstorming. Including the pre-mortem session date, participant list, and a sanitised summary of the failure narratives in the QRA documentation pack is good practice on any gate-reviewed programme.
How SOMA uses pre-mortems
SOMA Project Controls runs pre-mortems as part of QRA workshop facilitation on UK defence, nuclear, and infrastructure programmes. The shape of the engagement depends on the programme stage. For pre-investment programmes, the pre-mortem feeds the option-level QRA that supports the IPA Gate 1 / 2 decision. For in-flight programmes, the pre-mortem is used to test the existing risk register before a major rebaseline or contingency reset. In both shapes, the output is delivered as a documented session pack — facilitation script used, participant list, sanitised failure narratives, and a list of new or recalibrated risks for register integration — that holds up under independent reviewer scrutiny.