After a pre-mortem, the step before the mitigation plan is signed off is to test the assumptions that limited which failures the team could imagine. A longer failure list says nothing about the premises that set its edges.
Imagining that an event has already happened increases the ability to correctly identify reasons for future outcomes by 30%, according to Gary Klein's premortem article in Harvard Business Review, drawing on research by Mitchell, Russo and Pennington (1989). That figure measures how many reasons a room produces, not whether the room was looking in the right place.
A pre-mortem is a planning exercise in which a team assumes its project has already failed, and each member writes down the reasons why before the plan is committed.
Turning failure stories into a mitigation log
Klein's procedure is short. The team is briefed on the plan. The leader announces that the project has failed spectacularly. Each person spends a few minutes writing down every reason they can think of, especially the ones they would normally keep to themselves. Then the leader goes round the room, one reason per person, until every reason is recorded.
Klein's own description of the next step is a single sentence: after the session, the project manager reviews the list, looking for ways to strengthen the plan. In practice that review follows a familiar sequence. Duplicate reasons are merged. Similar ones are clustered under headings such as vendor delivery, staffing, funding or regulatory approval. Each cluster is rated for likelihood and impact, and the highest-rated clusters receive an owner and a mitigation action.
The mitigations are then folded into the project plan or the risk register. Some teams schedule a return to the list at the first major milestone. The artefact that leaves the room is a list of imagined failures with an owner beside each one. Soon after, the charter is signed or the go decision is made.
This is a different animal from a post-mortem analysis, which examines a failure that has actually occurred and works backwards from evidence. The pre-mortem works forwards from a fiction. Its raw material is whatever the people present can imagine, which is why the techniques for drawing dissent out of a group matter so much to how well it runs.
Imagined failure gives dissent a hearing
The pre-mortem's main achievement is social. In a normal planning meeting, raising a doubt reads as disloyalty to the project. Once the leader declares the project dead, doubts become the assignment. A reservation that would have sounded obstructive becomes a contribution.
Klein's examples show the effect. In one session, a team member who had stayed silent through a long kickoff meeting pointed out that an algorithm would not run quickly on the laptops used in the field. The developers turned out to have a shortcut they had been reluctant to mention, and the project went on to succeed. In another, an executive noticed that nobody had allowed for the timing of an upcoming corporate review.
Klein also argues that the exercise tempers the overconfidence of people heavily invested in a plan, and that it primes the team to notice early signs of trouble once work begins. Those are real gains in decision quality. The pre-mortem is cheap to run and returns information the plan's authors did not have. Its value lies in widening the list, which is also where its reach ends.
Write down the part of the plan nobody in the pre-mortem believed could fail and ask who has tested it before the go decision is signed. Start the Walk →
The fence around what the room could imagine
Every reason on a pre-mortem list is a story. Someone pictures the project collapsing and explains how it happened, using their working model of how the project operates: which parts move, which parts are fragile, which parts depend on people outside the room. The model supplies the plot. Anything the model treats as fixed never becomes a character in the story.
Three kinds of premise tend to sit outside the story. The first is anything the team regards as already verified: the component that passed its tests, the vendor proven at another site. The second is anything believed not to change over the life of the project. The third is anything the team has filed as someone else's responsibility. None of these feel like assumptions to the people holding them. They feel like the ground the plan stands on.
Which part of this plan did nobody in the room believe could fail?
The pre-mortem asks why the project failed. That question rewards vivid narratives about parts everyone already knows can move. It does not ask what the room took as settled, and so the premises that bound the imagination stay out of view. Adding more participants or more time lengthens the list inside the same fence. Well-known cognitive biases such as overconfidence make the fence harder to see from inside.
This is the category of assumption the exercise embeds: the premise that decides what counts as a possible failure in the first place. A pre-mortem can only fail the plan in ways the room already believes are possible. The work of surfacing assumptions before a decision is aimed at exactly this layer.
What did AECL's fault tree leave off the list?
The Therac-25 was a computer-controlled radiation therapy machine built by Atomic Energy of Canada Limited (AECL). Eleven were installed, five in the US and six in Canada. The earlier Therac-20 had independent protective circuits and mechanical interlocks. The Therac-25 relied more heavily on software for those safety functions.
In March 1983, AECL performed a safety analysis in the form of a fault tree: a formal exercise in imagining how the machine could fail and tracing each failure to its causes. According to Leveson and Turner's 1993 investigation, the analysis rested on three stated assumptions.
Programming errors had been reduced by extensive testing, and any residual software errors were not included. Software does not degrade through wear, fatigue or reproduction. Computer execution errors are caused by faulty hardware and by random soft errors from alpha particles and electromagnetic noise.
The tree did include the computer, but only as hardware. "Computer selects wrong energy" was given a probability of 10-11, and "Computer selects wrong mode" 4 x 10-9. Leveson and Turner note that the report gave no justification for either number.
Between June 1985 and January 1987, six known accidents involved massive overdoses. After an overdose in Hamilton, Ontario in July 1985, AECL could not reproduce the malfunction and suspected a transient failure in a turntable microswitch. It modified the switch assembly and claimed an improvement "by at least five orders of magnitude", while its final report to the FDA conceded it could not be firm on the exact cause.
In March 1986, after an overdose at the East Texas Cancer Center in Tyler, AECL engineers again could not reproduce the fault, and one reportedly explained that it was not possible for the machine to overdose a patient. After a second overdose there in April, the hospital physicist, Fritz Hager, reproduced it with the operator: the error appeared when treatment data was edited quickly. The cause was a race condition in the software.
At least three patients died from their overdoses or complications of them. The machine was recalled in 1987 for design changes that included hardware safeguards against software errors.
The fault tree was diligent within its boundary. Each investigation after an accident generated fresh hypotheses inside the same boundary. The assumption that software was not a credible cause shaped the analysis and every search AECL ran until a hospital physicist reproduced the fault.
From a longer failure list to tested assumptions
The artefact to check is the pre-mortem risk list and the mitigation actions log built from it. The trigger is the moment before the project charter or go decision is signed. At that point, take each cluster on the list and ask two questions: what must be true for this failure not to happen, and what did nobody list because everyone treated it as settled?
| What the pre-mortem named | What the room assumed | Gap to test |
|---|---|---|
| The vendor misses the integration deadline | The vendor's platform, proven at another client, will handle this organisation's transaction volume | A load test at projected peak volume on this organisation's data |
| Key staff leave during the rollout | The documented process describes how the work is actually done today | Observation of the process on the floor, compared line by line with the documentation |
| A hardware interlock fails in service | Software faults were removed by testing and cannot cause the failure | An independent check that does not depend on the software reporting its own state |
Write the answers down as assumptions, each with its evidence and an owner. Most will be adequately supported. The few that carry the plan and rest on nothing but confidence are the ones to test before signing. The Universal Decision-Making Method treats this as its own step, separate from framing the decision and separate from judging how much certainty is sufficient.
The same discipline applies after any exercise that lists hazards, as in what follows risk identification. Keep the record of which assumptions were tested and which were accepted untested. If the project later fails, that record is what a decision autopsy needs. Sign the go decision against the tested assumptions, not against the length of the list.
AECL had a formal analysis of how the Therac-25 could fail. What it did not have was a test of the assumption that its software could not.
Work through your decisionNo sign-up. Just pick your decision and start.
Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.