top of page

90-Minute Pre-Mortem Facilitation Kit

S. West
1 hour ago
4 min read

Two people on the team knew how the launch could fail. Nobody asked them until the incident review.

The migration had been planned for months and the rollout checklist was green. In the review afterwards, one engineer said she had worried that the cache would be stale after the cut-over. An operations lead admitted the rollback script had never been run against production-sized data. Neither had said so earlier, because the planning meetings were about dates, and doubt sounded like a lack of commitment. The cut-over ran with a stale cache, and reads returned old data for two hours.

(Composite example, assembled from patterns common in teams that plan launches around a schedule. The figures are illustrative.)

A post-mortem takes a week and has a casualty list: customers, trust, a weekend. A pre-mortem takes 90 minutes and can prevent the incident. The technique is Gary Klein's ("Performing a Project Premortem", Harvard Business Review, September 2007). Instead of asking what might go wrong, the team assumes the project has already failed and explains why. It builds on research into "prospective hindsight": people find it easier to generate explanations for an outcome when they treat it as having already happened. This kit gives you the timed agenda, the prompts and a one-page artifact to run one.

Step 1: prepare before the meeting

  • ☐ Pick one project, launch or change with real downside.

  • ☐ Invite the people who will build and operate it. Our rule of thumb is five to eight people: enough for different views, few enough for everyone to speak.

  • ☐ The leader sets the tone: structured pessimism is welcome for the next 90 minutes.

  • ☐ Prepare a shared document and a way to rank (dots, a grid or numbers).

Step 2: run the timed agenda

The six blocks add up to 90 minutes. Keep the timings, because the silent writing and the mitigations are the parts that get squeezed first.

Time

Step

What happens

5 min

1. Set the scene

"It's six months from now. We launched [the thing]. It went badly: customers complained, leadership is asking what happened, and we're in incident review. We're here to work out why." The mode is investigative, not speculative.

10 min

2. Silent writing

Each person writes their own account of what happened. Make it concrete: "the migration ran with a stale cache, so reads returned old data for two hours", not "there was a caching issue". Silence stops the group converging on the loudest voice.

15 min

3. Round-robin

Each person reads their list aloud. No discussion yet. Build a shared inventory; the variety is the value.

25 min

4. Cluster and rank

Group related failure modes. Rank them by probability and impact. The top three to five become the focus.

30 min

5. Mitigations

For each top failure mode, agree one specific, actionable mitigation: an extra test, a different rollout, a feature flag, a rehearsal, a runbook or a named owner. Not "be careful". Something someone can commit to by a date.

5 min

6. Go/no-go criteria

Agree that the project doesn't ship until the top mitigations are in place.

In our experience, step 6 is the most-skipped step, and it is the one that decides whether the pre-mortem changes the outcome or just produces a document.

Step 3: fill in the one-page artifact

Fill this in during the meeting, not afterwards.

#

Failure scenario (concrete)

Probability (H/M/L)

Impact (H/M/L)

Mitigation

Owner

Due

1

______

______

______

______

______

______

2

______

______

______

______

______

______

3

______

______

______

______

______

______

4

______

______

______

______

______

______

5

______

______

______

______

______

______

Go/no-go: this ships only when the mitigations for #______ are complete. Reviewed by: ______

Keep the artifact and refer to it during the project, especially when something starts to look familiar.

Step 4: decide when to run one

  • ☐ Every major launch: anything where failure would become a story.

  • ☐ Every hard-to-reverse change: a database migration, a data-model or breaking API change, a cloud or provider switch.

  • ☐ Every new external dependency: focus on the vendor failing.

  • ☐ Quarterly, system-wide: pick the riskiest piece and imagine it fails in six months.

Our rule of thumb, not a measured figure: about 10 to 15 pre-mortems a year, aimed at the projects with the most downside, is doing the work. Run them on everything and they become ceremony. Run them on nothing and you pay the post-mortem cost instead.

Step 5: watch the blind spots

  • ☐ Unknown unknowns: you can only imagine failures you have language for. Invite someone from outside the team if the room is too alike.

  • ☐ Slow failures: pre-mortems tend to focus on sudden incidents. Ask, "How could this fail gradually?"

  • ☐ Legal optics: keep the artifact about mitigations, not blame. It is a planning document, not a confession.

How to use it

  • Who: a facilitator who isn't the project lead, with the five to eight people who will build and operate the change. One 90-minute session.

  • Output: a ranked list of three to five concrete failure scenarios, one mitigation for each with an owner and a date, and an agreed go/no-go line.

  • Done when: every top scenario has a named owner and a due date, and someone with authority has signed the go/no-go line.

Where this changes

A small team shipping a reversible change can run a shorter version: silent writing, a quick rank and one mitigation each. In regulated or safety-critical work, the pre-mortem feeds a formal hazard or risk analysis rather than replacing it, so carry its scenarios into your risk register with owners and review dates. Large programmes benefit from running one per workstream and a final one across the whole launch.

The reasoning behind this kit is in pre-mortems beat post-mortems. If a scenario you ranked does happen anyway, incident command for software teams covers how to run the response.

Final takeaway

The doubts that sink a launch are usually already in the room. A pre-mortem gives people permission and structure to say them while there is still time to act, and the go/no-go line makes sure what they said changes the plan.

Sources

bottom of page