A post-mortem asks why something died. A pre-mortem asks the same question before you start.
What it is
Gary Klein described the pre-mortem in Harvard Business Review in 2007. The setup is simple. Before a project starts, the team imagines it's a year later and the project has failed badly. Each person writes down why.
It works because it changes the question. "What could go wrong?" invites polite answers. "It failed. Why?" gives people permission to say what they were already worried about.
Why people skipped it
It's cheap compared to an FMEA, but it still takes a meeting. And it depends on people being willing to say awkward things in front of the boss. Many teams skip it, or do it once and stop.
How a bot does it
A bot has no boss to worry about and doesn't run out of ideas. It can write many different failure stories quickly. People read them and pick the ones that ring true.
- Give it the plan. The project charter, schedule, budget, the process map, the people and suppliers involved.
- Ask for stories, not a list. A short story makes the bot follow cause to effect. A list invites vague one-liners.
- Ask for variety. Different kinds of failure: technical, supplier, people, schedule, customer, money, regulation.
- Have it group and rank them. Which failure stories share a root? Which are most likely? Which would hurt most?
- A person picks the top few. Each one gets an owner and an early warning sign to watch for.
The bot brief
Run a pre-mortem on the attached project plan.
Assume it is [date one year out] and the project failed badly.
Write 20 short failure stories (3-4 sentences each). Each story must:
- name the specific part of the plan that broke (cite the plan section)
- say what the first warning sign would have been
Cover at least: technical, supplier, people/skills, schedule, customer, cost, regulatory.
Mark any story that depends on facts not in the plan as GUESS.
Then group stories that share a cause, and rank the groups by likelihood x impact
(High/Medium/Low each). For the top 5 groups, propose one early warning sign to
monitor and one action to take now. Do not decide; this is for team review.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
Say a small shop plans to move its quoting to a bot by March.
| Failure story (short) | Warning sign | Likely | Impact | Action now |
|---|---|---|---|---|
| Bot quoted from last year's price list, three quotes lost money | A quote margin below normal | Medium | High | Point the skill at one master price file. See The current version at the point of use |
| Estimator left; nobody knew the rules the bot was built on | Questions nobody can answer | Medium | High | Write the quoting rules into a skill before go-live |
| Customers got quotes with no person reviewing them | First complaint about a wrong quote | Low | High | Keep a person's yes on every quote. See Nothing ships without a yes |
| Project stalled because the ERP export never worked | No test export by week 2 | High | Medium | Test the export first |
Four rows here. A real run would have twenty stories, grouped. The team spends its time on the top groups.
Where bots differ
People in a pre-mortem bring the fear they've been keeping quiet. That fear is often the most valuable input, and a bot doesn't have it. So run the bot's version first, then ask the team one question: "What's missing from this list?" The answers to that question are often the best ones.
A bot will also produce failures that sound dramatic and aren't likely. Ranking matters more than volume.
What this means for you
- Run a pre-mortem on anything with a deadline and a budget.
- Have the bot write stories, not a list.
- Ask people what's missing.
- Give each top risk a warning sign and an owner.