Pre-mortem template

A pre-mortem template is a structure for a meeting held before work starts, where the team assumes the project has already failed and writes down why. It surfaces risks people would not raise in a status review. The trick is the past tense.

A pre-mortem template (PMT) is not a post-mortem template, which shares the same initials. The pre-mortem runs before the work and imagines a failure; the post-mortem runs after a real one and explains it.

It is also not a risk register. The register is the standing list you maintain — the pre-mortem is the session that fills it with the risks nobody had written down yet.

Key takeaways

• A pre-mortem assumes the project failed, then asks the team to explain how.
• The past tense is what frees people to name a risk out loud.
• The output is a ranked list of causes with owners, not a general mood.
• It feeds the risk register; it does not replace one.

How it works

A pre-mortem works in one short session. The facilitator states that the project has failed badly, gives everyone silent writing time, collects the causes, then groups and ranks them. Owners and mitigations come last.

A typical session shape runs like this.

Be specific about the failure you declare. “The project failed” produces vague answers; “it is March and we have missed go live by two months” produces dated, checkable ones.

Silence is doing the work. The moment the room starts debating the first cause out loud, the quieter people stop writing — and their causes are usually the ones nobody else has.

Write causes as sentences, not labels. “Risk: resourcing” tells you nothing, while “the two people who know the legacy interface both leave in May” tells you exactly what to do.

The output belongs inside your enterprise risk management process rather than in a private document, which is where most of these lists quietly go to die.

Rank on two columns, not one. How likely a cause is matters less than how much warning you would get, because a cause you can see coming is one you can still act on.

Most of what surfaces is ordinary business risk — a dependency that slips, a sponsor who leaves, a budget approved for the wrong financial year.

Outsourced work adds a layer, which is why third party risk management questions belong in the session whenever a supplier sits on the critical path.

Severe causes graduate. If a named cause would stop the service outright, it belongs in the business continuity plan rather than on a project action list.

Sizing comes next. A business impact analysis tells you what losing each dependency would actually cost, which is how the ranked list stops being a show of hands.

Set a review date on the day. A pre-mortem whose list is never reopened is a very good meeting that changed nothing — which is the usual failure mode.

Invite the dissenter. The person most sceptical about the plan is the cheapest source of causes you have, and a session that excludes them produces a comfortable list.

The public sector version of this is formal. The US government’s Ready.gov business planning guidance describes risk assessment as a process used to identify potential hazards and what could happen if one occurs.

Healthcare has a formal version of the same instinct, built for processes rather than projects.

Healthcare Failure Mode and Effects Analysis (HFMEA), developed by the Veterans Health Administration National Center for Patient Safety, combines risk scoring with a decision tree to decide which hazards need addressing.

Examples

Pre-mortems fit any piece of work with a date and a budget. Transitions, migrations, product launches and new outsourcing contracts are the usual settings, and the same three or four causes keep reappearing in every sector.

Outsourcing transitions. Before a process moves offshore, the session reliably surfaces undocumented steps, one person who never wrote anything down, and a volume forecast nobody owns.

System migrations. Teams imagine the cutover weekend failing, which tends to produce the rollback plan that would otherwise have been written on the night, by tired people.

New outsourcing contracts. Before signing, both sides run the session separately and compare lists, which surfaces assumptions about volumes, holidays and escalation that the contract never mentions.

Clinical and safety processes. Hospitals assess processes before an error happens, using structured scoring rather than open discussion. It is the same idea applied to a repeated process instead of a one off project.

Related terms

• Risk outsourcing: transferring a risk to a provider instead of mitigating it yourself.
• Governance risk compliance: the standing structure the session’s output gets filed into.
• Enterprise risk management: the process that owns the register this session feeds.
• Business impact analysis: the sizing exercise that ranks the causes credibly.
• Business continuity plan: where the most severe causes end up.

FAQ

What is a pre-mortem template?

It is a structure for a session held before work begins, where the team assumes the project has failed and lists the reasons. The output is a ranked set of causes with owners.

How is a pre-mortem different from a post-mortem?

A pre-mortem runs before the work and imagines a failure. A post-mortem runs after a real one and explains what actually happened.

Who should attend a pre-mortem?

The people who will do the work, plus anyone with the authority to stop it. Keep the group small enough that everyone reads their own list out loud.

How long does a pre-mortem take?

Under an hour for most projects. The silent writing stage is deliberately short, because first answers are usually the honest ones.

Does a pre-mortem replace a risk register?

No, it populates one. The register is still where the causes get tracked, reviewed and closed.

Find providers used to running structured risk sessions before a transition on Outsource Accelerator.