Pre-mortem generator

A pre-mortem starts from an assumption, not a question. Assume the round is over and the answer was useless. The team is asked what happened. What comes back should be a short ranked list of concrete failures, each one with the point in the process where it started and the cheap thing that would have prevented it.

The prevention column is what separates this from a worry list. "The data will be bad" is not usable. "The vendor loss files arrive at postcode level and the whole comparison needs property level, which nobody discovers until week five" points at a phone call the team can make on Monday.

This is the cheapest step in the scope stage and it is often skipped because the output feels negative. It costs an hour. The failures it names are the ones that would otherwise be discovered halfway through, when the design is already fixed and the deadline is closer.

It does not produce a plan. It produces a list the team argues about for twenty minutes, from which two or three items get designed against. The rest are noted and ignored on purpose.

A pre-mortem run against a topic returns platitudes. Run it against the actual plan. That means the research question, the branches, the sources the team intends to use, who is doing the work, how long they have, and who receives the answer. All six matter, and the last two matter most.

Most useless rounds fail on delivery, not on method. The work was fine and the recipient had already decided, or had moved to a different problem, or needed it three weeks earlier. A pre-mortem that does not know who is waiting for the answer cannot see that failure, and it is the most common one.

Then define the personas. Four or five is enough, and each one needs a stake, not just a job title. A methodologist who cares whether the comparison is fair. A domain practitioner who knows what the data actually looks like on the ground. The person who commissioned the work and will have to act on it. And someone who has run this kind of round before and remembers how the last one went.

Add a hostile persona if the answer will be contested. Someone whose budget or reputation depends on the round reaching a particular conclusion will find the weak joints faster than anyone friendly to the work.

Run each persona in isolation. Asking one model to speak as five voices in one pass produces a blend where the strongest failure is softened by the others. Separate calls, separate outputs, then merge by hand. Overlap between two personas is itself a signal. The same isolation rule applies later in adversarial review of a completed deep dive, for the same reason.

Keep the question in the past tense. It is over, it failed, explain why. Present-tense phrasing invites risk assessment, and risk assessment returns probabilities and hedges. Past tense forces a story, and stories contain mechanisms. The mechanism is the part you can act on.

Ask each persona for a small number of failures, not everything they can imagine. Three is a good cap. A capped list forces ranking inside the persona, and the top item from a domain practitioner is usually more specific than the tenth item from anyone.

Then sort the merged list on two axes. How early the failure starts, and how expensive it is to fix once it has started. Failures that start in scope and are cheap to prevent now go straight into the design. Failures that start late and are cheap to fix later can be left as monitoring notes.

Take a hypothetical case. An insurer's emerging-risk team is scoping a review of external wildfire catastrophe models. The question is which model, if any, should replace the one currently used for a western property book. Three vendors are in scope. The team has one analyst and a modeler, and eleven weeks.

The methodologist persona returns a failure about the benchmark. The review compares each vendor model against the last four fire seasons, and four seasons in one region cannot separate the models. Whichever wins, the ranking will not be stable. The prevention is to agree in week one that the output is a qualitative comparison of assumptions, not a skill ranking.

The underwriting persona returns something else. The review answers a portfolio question, but the people who will use the model day to day price individual risks. A model that performs well on aggregate loss and badly at the address level is useless to them, and they will not adopt it. The prevention is to add an address-level criterion now, before the vendor conversations start.

The persona who has run this before returns the boring one. Two of the three vendors will not release the documentation the review needs without a commercial conversation that takes six weeks. Eleven weeks minus six is not a review. The prevention is a data request sent in week one, with a named fallback if it is refused.

The team designs against three of the eleven items returned. The scope changes: the deliverable becomes an assumptions comparison plus an address-level check, and the vendor data request moves to day two. The other eight go in an appendix that nobody reads again, which is the correct fate for most of them.

The first failure mode is output that would fit any project. Insufficient data, unclear stakeholder alignment, scope creep, resource constraints. These are true of every round ever run and they change nothing. If the list would survive being pasted onto a different study, the plan was not specific enough in the prompt.

Test each item with one question: what would the team do differently on Monday. An item with no Monday action is a worry, not a failure mode. Delete it or push it back to the persona for a mechanism.

The second failure mode is paralysis. A long list of plausible disasters, delivered to a nervous team, produces either a scope so cautious it answers nothing, or a decision to gather more evidence about the risks. Cap the list, cap the number designed against, and move on. A pre-mortem that delays the round has cost more than it saved.

The third is running it too late. Once fieldwork has started, most of the identified failures are already unavoidable, and the exercise becomes a record of regret. This belongs beside the tree and the screening criteria, while both can still be changed for free.

The list is advice. Choosing which failures to spend the budget on is a judgment about what this organization can absorb. A lead who has watched two previous reviews stall on vendor access will weight that item heavily, and the model has no way to know that.

Write down what was accepted. A pre-mortem where every item is mitigated is a pre-mortem nobody read properly. Naming the risks the team is knowingly carrying is more valuable than the mitigations, because it is the honest part of the scope document.

Keep it out of the deliverable. A pre-mortem is an internal design artifact. Handing a recipient a list of ways the work could have gone wrong, before they have read the work, spends credibility for no gain. The relevant limitations reach them through the findings, where they belong.

Reread the list at the end of the round. Which predicted failures happened, and which items nobody saw coming, is the only way this exercise improves. Store it next to the round's other artifacts so it can be found, alongside what the last comparable round decided and what peers were scoping toward at the time.