Six weeks before a demo deadline, a three-person team discovers that the one programmer who understands their save serialisation is unreachable for two weeks, the publisher wants a build in the middle of that gap, and the only machine that can produce a signed Windows build is that same programmer's laptop. Nobody was careless. Everyone knew each of those three facts individually. Nobody had ever written them down on the same page.
That is what a pre-mortem is for. It is a short, structured session where you assume the project has already failed and work backwards to the reasons — and then, crucially, you turn those reasons into a living risk log with owners and tripwires instead of a document nobody opens again.
Why most risk lists die within a week
Teams abandon risk tracking for three reasons. The entries are vague — "scope creep" is not a risk, it is a genre, and you cannot assign it or detect it. The entries have no owner, and a risk belonging to "the team" belongs to nobody. And the log has no review cadence: it gets written in a burst of enthusiasm at project start, when the project is least legible, then never updated as the real risks change.
A usable risk log fixes all three: specific sentences, one named owner each, and a fifteen-minute review on a fixed schedule.
The 45-minute pre-mortem
Run this at the start of a project and again at each milestone. It works with two people and with twelve.
Minute 0-5 — Frame the failure. State a specific, dated failure out loud: "It is 14 March, our vertical slice deadline. The build we shipped was rejected and the team is demoralised." Not "the project went badly." Concreteness is doing all the work here.
Minute 5-15 — Silent writing. Everyone writes causes alone, one per line, no discussion. Silence matters: the moment someone speaks, the room anchors on their framing, and the quieter people stop generating. Aim for at least eight lines each.
Minute 15-25 — Round robin. Each person reads one item at a time, going around the circle, until everyone is out. No debating whether a risk is "real" — that filtering happens later, and doing it now teaches people to self-censor.
Minute 25-35 — Cluster and cut. Group duplicates. You will typically go from sixty raw lines to fifteen or twenty distinct risks. Kill anything outside your control ("Steam changes its algorithm") unless you can genuinely prepare for it.
Minute 35-45 — Score and assign. Score each surviving risk, then give the top handful an owner. Stop at the top eight. A risk log with thirty live entries is a reading task, not a management tool.
Write risks as sentences, not nouns
Use a fixed template so every entry is testable:
Because [cause that is true today], [event] may happen, which would [concrete impact].
Compare:
- Weak: "Build pipeline risk."
- Strong: "Because only Priya's laptop has the signing certificate and our build scripts are local, we may be unable to produce a publisher build while she is away from 2-16 March, which would cost us the mid-milestone check-in."
The second version tells you the fix in its own first clause. Most good risk entries do.
Scoring without pretending to be precise
Use a 1-5 scale for likelihood and a 1-5 scale for impact, multiply them, and sort. Do not agonise over whether something is a 3 or a 4 — the number exists to produce an ordering, not a forecast.
Add a third column that most teams skip and that pays for itself: detectability, scored 1 (you will find out immediately) to 5 (you will find out only when it is too late). A moderate risk you cannot see coming is often more dangerous than a large one you will spot a month out.
| Risk | L | I | D | Score | Owner | Response |
|---|---|---|---|---|---|---|
| Signing certificate only on one machine, holder away 2-16 Mar | 4 | 4 | 2 | 32 | Priya | Reduce — move to shared CI, done by 25 Feb |
| Save format still changing while playtest builds ship | 4 | 3 | 4 | 48 | Tom | Reduce — version the save header this sprint |
| Contract composer has not confirmed March availability | 3 | 4 | 3 | 36 | Marek | Avoid — confirm in writing by 10 Feb, else use temp tracks |
| Boss fight design not validated with new players | 3 | 4 | 3 | 36 | Ana | Reduce — 5 external playtests before greybox lock |
| Engine version upgrade breaks the input plugin | 2 | 4 | 4 | 32 | Tom | Accept — trigger: branch spike if upgrade is forced |
| Steam page assets late because capsule art unscheduled | 3 | 2 | 2 | 12 | Marek | Reduce — book the slot in this milestone |
Notice that the save-format risk outranks the certificate risk purely on detectability. That is the column earning its place: a save format that drifts silently corrupts weeks of playtest feedback before anyone notices, while a missing certificate announces itself loudly the first time you try to build.
Four responses, and picking one on purpose
Every live risk gets exactly one of these:
- Avoid — change the plan so the risk cannot occur. Cut the feature, move the deadline, pick the boring engine version.
- Reduce — take a concrete action that lowers likelihood or impact. This is where most of your work goes, and it must be a task with a date, not an intention.
- Transfer — move the exposure elsewhere: a contract clause, a licensed asset instead of a bespoke one, a publisher handling console certification.
- Accept — decide consciously to live with it, and write down the tripwire that will tell you it is happening plus what you will do then.
"Accept" is a legitimate, adult answer. An accepted risk with a named tripwire is safer than a "reduce" that nobody scheduled.
Tripwires make the log self-executing
For each risk, write one observable condition that flips it from watching to acting:
- "If the composer has not confirmed by 10 February, we switch to temporary tracks and rebudget."
- "If two consecutive playtesters fail the boss on their first three attempts, we redesign phase two rather than tune numbers."
- "If the input plugin is still broken 48 hours after the upgrade branch opens, we revert and stay on the old engine version through ship."
A tripwire converts a judgement call made under deadline pressure into a decision made calmly in advance. That is most of the value of the whole exercise.
Keeping it alive: the 15-minute review
Put this at the top of your milestone or sprint review, not at the end where it gets cut for time.
- Any risk that fired? Move it to the issue log and record what actually happened.
- Any risk now impossible? Close it and say why.
- Any mitigation task that slipped two reviews in a row? It is not being done — either escalate it or change the response to "accept".
- Any new risk from what we learned this milestone? Usually there are one or two.
- Re-sort by score. Is the top of the list still where attention is going?
Five minutes of that beats an hour-long quarterly ceremony.
Where it lives
The log has to sit next to the work, not in a separate spreadsheet someone forgets exists. In GameDesignerX, the risk log sits alongside the idea, issue and decision logs and the milestone board, so a risk that fires becomes an issue in one step and a mitigation becomes a task on the sprint it belongs to. The mechanism matters more than the tool: risks that live in the same place as tasks get reviewed, and risks that live in a document get archived.
One habit worth keeping regardless of tooling: when a risk fires, log one line about what you did and whether the tripwire was set at the right threshold. After a few milestones you will have calibration data for your own team.
The failure modes to watch for
Too many entries. Eight live risks is a working list. Thirty is a filing cabinet.
Optimism scoring. If every likelihood in your log is a 2, you are rating the risk you would like to have. Ask instead: "if this went wrong on a project like ours, would anyone be surprised?"
Risks that are really tasks. "Write the combat design doc" is not a risk. "Because combat rules only exist in Ana's head, an illness or a hire would stall combat work for weeks" is.
No safety to speak. Pre-mortems work because people can name uncomfortable things without it being an accusation. If calling the schedule unrealistic is career-limiting on your team, you will get a list of tooling risks and no schedule risks — which is itself the most useful finding of the day.
Run one before your next milestone. Forty-five minutes now, fifteen a fortnight after that, and the demo-week discovery at the top of this article becomes a line item you closed in February.