pre-mortem

Also called: premortem, pre-mortem analysis

A short exercise before a decision or launch: the team imagines it's some months later and the plan has failed, then each person writes down why. It brings out risks people would otherwise keep to themselves and turns them into checks or changes to the plan.

A pre-mortem is a short exercise run before a decision is final or a plan starts. The team imagines a specific date in the future when the plan has clearly failed. Each person then writes, alone and in a few minutes, the reasons it failed. The reasons are collected, similar ones grouped, and the most likely or most damaging few are turned into a check, an early-warning trigger or a change to the plan. The whole thing fits in fifteen to twenty minutes.

It works for three reasons. Taking failure as given makes it safe to name risks: pointing out a weak spot no longer sounds disloyal to the plan or its owner. Writing alone before any discussion keeps people from anchoring on the lead or the loudest voice, so quieter people's concerns get onto the list too. And imagining an outcome as if it had already happened tends to produce more concrete reasons than asking "what could go wrong?", which early studies of this kind of hindsight have found.

The output is only as good as its lines. "Communication problems" changes nothing; "the refund rules changed in June and she will use the old ones" can be checked by Friday. A pre-mortem is not a vote against the plan and not a post-mortem, which looks for causes after a failure: it makes the plan you pick stronger while changes are still cheap. Include yourself as a possible cause, and give each check an owner and a date.

Example

July 2027. The lead of Klasna's Support team leans toward option A for the September restart: a September–October contract for Sofiia, a seasonal coordinator who knows the work. Before the half-page recommendation goes to Iryna, the people who will train or cover spend fifteen minutes on a pre-mortem: "It's the end of October and the plan has failed. Why?"

Reason someone wrote	Check, trigger or change	Owner, date
Sofiia signed, then left mid-September for the other job	start date and term confirmed in writing before her 16 July deadline for the other offer	Lead, 15 July
September was much busier and one extra person wasn't enough	trigger: if first replies on shift take longer than the 45 minutes in the working agreement on three days in one week, ask Iryna for more help	Lead, weekly from 1 September
Nobody told her what changed since June, so she used the old refund rules	a one-hour refresh on everything new, including the refund-ticket rule	Olha, first day
The lead slipped back into taking the hard tickets	hard-ticket rotation stays on; the lead's own-ticket hours capped at 8 a week	Lead, reviewed at the Iryna check-in

The recommendation now carries its top risks with an answer to each, which is what makes it something Iryna can actually decide on.

Common mistakes

Discussing out loud before writing. People anchor on the first or most senior voice; write alone first.
Accepting vague lines. "Bad communication" can't be checked; ask for who, what and when.
Running it after the decision is already locked. Do it while the plan can still change.
Leaving the reasons on the board. Each top reason needs a check, a trigger or a change, with an owner and a date.
Leaving yourself out. "The lead slipped back into old habits" is one of the most common real causes.

Learn it in the course

Real options and the pre-mortem · Put at least two real options on the table, write the must-haves first, compare trade-offs, collect views before the discussion and imagine the failure before it happens.
Case: support for the summer with two people · Use last summer's ticket mix to plan August with two coordinators on shift: forecast the load, choose the structure, decide who decides, and run a pre-mortem.