The pre-mortem: finding delivery risks before the customer does
Updated
A 45-minute pre-mortem format that surfaces the risks a delivery brief hides, with a worked fictional example and a reusable risk table.
Most delivery failures are not surprises. Somebody saw them coming, usually in week one, and said nothing because the meeting moved on. A pre-mortem is a 45-minute meeting that makes saying it the assignment.
The short answer
Gather the builders and the future operators. Announce that the project has failed, six months from now, badly. Everyone writes down why. Then you turn the answers into owners, mitigations and acceptance criteria before anything is built.
Why post-mortems arrive too late
A post-mortem asks what happened. By then the answers are expensive: data migrated the wrong way, access approved two weeks late, the one operator who knew the batch job left. A pre-mortem asks the same questions while the answers still cost a sentence in a one-page brief instead of a month of rework.
The mechanism is simple. Optimism is social: in a planning meeting, doubting the plan reads as doubting the team. The pre-mortem flips the social pressure by declaring failure a fact. Now the skeptic is cooperating, and the quiet operator who knows where the bodies are buried gets explicit permission to point at the ground.
The 45-minute format
Minutes 0-5: set the scene. Read the failure headline out loud: the system went live on the agreed date and failed in the specific way you fear most. Name a date. Vagueness lets people off the hook.
Minutes 5-20: silent writing. Everyone writes failure reasons on their own, one per line, no discussion. Silence matters more than facilitation skill: it stops the senior voice from anchoring the room.
Minutes 20-35: read-out and cluster. Each person reads their list. Group duplicates visibly. Expect 15 to 25 raw reasons from five people; most cluster into four or five themes.
Minutes 35-45: score and assign. For each theme, score likelihood (1 to 3) and impact (1 to 3), multiply, and name one owner plus one concrete mitigation. Anything scoring 6 or above also gets a rollback or fallback line in the plan.
Who must be in the room
Three roles, minimum. Someone who builds, someone who will operate the result after handover, and one skeptic with no stake in the timeline. Customer operators are the highest-value seats: they know the change windows, the access queues and the batch jobs that never appear in architecture diagrams. If the operators cannot attend, interview one beforehand and read their answers into the room.
Worked example: a fictional clinic scheduler
Context is fictional and labeled as such. A fictional clinic network, Harbor Clinics (fictional), books 300 appointments a day across four sites by phone and a shared inbox. The brief: a scheduling page over the existing patient store, read-only first, behind staff login, one site pilot, then rollout.
The pre-mortem headline: pilot launched March 1, rolled back March 9, front desk back on phones. Nineteen reasons cluster into five themes:
| Theme | Likelihood x Impact | Owner | Mitigation in the brief |
|---|---|---|---|
| Double bookings from phone plus page overlap | 3 x 3 = 9 | FDE | One writer per slot: page locks the slot, phone staff check the page first; acceptance criteria name the conflict rule |
| Staff login approvals take weeks | 2 x 3 = 6 | Customer IT lead | Login request filed in week 1 with named approver; pilot login list capped at six named staff |
| No-show data missing, reminders misfire | 2 x 2 = 4 | FDE | First slice ships without reminders; reminder rule added only after two weeks of clean booking data |
| Rollout to four sites at once | 3 x 2 = 6 | FDE + head nurse | One site pilot, written go criteria, other sites gated behind them; see handling scope change |
| Rollback path unclear | 2 x 3 = 6 | FDE | Phones-plus-inbox fallback rehearsed once before launch; rollback plan names who declares rollback |
Two themes score 9 and three score 6, so all five earn owners. Notice what changed in the brief: the conflict rule, the six-name login list, reminders deferred, single-site pilot, rehearsed fallback. None of this needed new technology. It needed the failure stated out loud before the build.
The reusable artifact: risk table
Copy this shape into every brief. Five columns, no more:
| Risk (failure stated plainly) | L (1-3) | I (1-3) | Owner | Mitigation plus fallback |
|---|
Rules that keep it honest. One risk per row, stated as a past-tense failure, never as a worry. Scores are relative within the project, not calibrated across projects. Every row has a named human owner, never a team. Score 6 or above requires a fallback line, not just a mitigation. Review the table at each demo: retire what passed, re-score what moved.
Turning risks into acceptance criteria
A mitigation without an acceptance criterion is a wish. For each row scoring 6 or above, add one testable line to the brief: the slot conflict rule rejects the second writer, the pilot login list holds exactly the six names, the fallback drill completes in under 30 minutes. The FDE Foundations course modules M03 and M09 teach the brief and the rollback shapes this plugs into, and every lesson is free to read.
Run the pre-mortem once per project and revisit the table at every demo. The meeting costs 45 minutes. The failures it catches cost months.
Straight answers
Frequently asked questions
When should a pre-mortem run?
After the brief is accepted and before the first build slice: early enough to change scope, late enough that the plan is concrete.
Who must be in the room?
Whoever builds, whoever operates it afterward, and one skeptic. Customer operators catch the risks engineers miss.
How is this different from a risk register?
A register lists what people already admit. A pre-mortem assumes failure and asks why, which unlocks the risks nobody wanted to say out loud.
What if every risk sounds unlikely?
Score them anyway. Low likelihood times high impact still earns a mitigation owner and a rollback path.