Premortem

A premortem asks a team to imagine that a planned initiative has failed, then explain how that happened. The practical purpose is to expose vulnerabilities while the plan can still change. It produces candidate risks and actions to investigate or reduce them, not a prediction that failure will occur.

Gary Klein describes the method on his own website. The Agency for Healthcare Research and Quality also provides an application that moves from imagined failure to mitigation planning. Klein’s description · AHRQ premortem tool

When to use it

Use a premortem when there is a sufficiently concrete plan to criticize and enough time to act on what emerges. Useful moments include before a pilot, before a launch decision, or after a major change in scope or dependencies.

It works best when participants know different parts of the work: delivery, operations, customer experience, implementation, and decision making. Invite someone who understands what happens after launch, not only people who designed the proposal.

Do not use it as a substitute for technical assurance, formal safety analysis, legal review, or financial due diligence. A workshop cannot certify a system. It is also a poor fit when no actual plan exists; the group will produce generic worries rather than specific failure mechanisms.

If participants reasonably expect punishment for criticism, fix the conditions for raising concerns first. A dramatic opening sentence does not make speaking up safe.

Expected outcome and preparation

For a first session, allow 60 minutes with five to eight participants. This is a practical adaptation, not a tested optimal duration. The output should include a short list of risk statements, evidence gaps, mitigation owners, early warning signs, and a review date.

Prepare a one-page plan covering the intended result, scope, key milestones, assumptions, dependencies, and responsible decision maker. Send it in advance. Make clear which decisions can still change and how concerns will be escalated.

Use a shared document or board with fields for: imagined failure, cause, evidence, consequence, possible response, owner, and trigger for review. Supply a timer and private writing space. Ask participants not to name or blame individuals; describe work conditions, decisions, and dependencies.

Decide what failure means for this exercise. “The project failed” can mean a missed launch, poor adoption, a harmful user experience, or benefits that never materialize. Choose a concrete future point and outcome, then allow the group to challenge whether that framing excludes another serious consequence.

A 60-minute facilitation plan

0–10 minutes: brief the plan and failure scenario

Summarize the proposal and answer factual questions. Do not spend the session selling the plan. The sponsor can say: “I want to understand where this breaks. Specific concerns are useful even when they challenge our current assumptions.”

Then present the scenario: “It is six months after the pilot. The intended improvement has not happened, and the team has stopped expanding the service. Write the reasons this happened.”

Use a plausible, relevant scenario. A theatrical catastrophe can distract people from ordinary operational problems that are more actionable.

10–17 minutes: write independently

Give everyone quiet time to list causal explanations. Ask for several different pathways rather than variations of one favorite concern. Offer prompts only after people have begun, so the facilitator’s examples do not dominate.

Prompts include: “Which dependency did we misunderstand?” “What did users find too difficult?” “What happened during a busy period?” and “Which assumption held in the pilot but failed elsewhere?”

The imaginative step resembles prospective hindsight: explaining an outcome as if it has already occurred. Mitchell, Russo, and Pennington studied temporal perspective and outcome certainty. Their abstract reports little influence from temporal perspective in the first experiment, while certainty affected the kinds of explanations given. This is a narrower finding than proof that imagining the future improves risk identification, and it is not a field trial of project success. Original research

17–30 minutes: collect explanations without rebuttal

Go around the group, inviting one explanation per person at a time. People may pass and return later. Capture contributions before debating them. Ask the sponsor and plan author to listen rather than immediately solve each concern.

Translate a vague label into a mechanism. “Poor communication” might become “Shift staff did not receive the new escalation instructions before the old process was removed.” Keep the author’s meaning and ask them to confirm the rewritten version.

Do not merge concerns merely because they share a category. Training content being unclear and staff having no time to attend are different failure pathways.

30–42 minutes: examine and prioritize risks

For each candidate risk, separate what is known from what is imagined. Ask: “What observation supports this?” “What would have to happen first?” and “How could we find out whether this vulnerability is real?”

Select a manageable number for immediate attention. Consider consequence, plausibility, reversibility, and how early the team could detect the problem. Avoid multiplying speculative numbers into a precise-looking score. If a risk is serious but uncertain, the first action may be investigation rather than mitigation.

Preserve a minority concern even if it receives little support. A preference vote cannot determine whether an overlooked technical dependency exists.

A CLOSER LOOK

An imagined failure is the beginning of an inquiry.

1. 01
   Scenario“People went back to their old documents.”
2. 02
   Possible mechanismSome shared articles may lack a responsible owner.
3. 03
   Evidence to seekCheck ownership and review arrangements before the pilot.

Do not turn an imagined explanation into a finding.

42–55 minutes: choose responses and warning signs

For each priority risk, choose a specific response: change the plan, test an assumption, create a contingency, transfer responsibility with agreement, or explicitly accept the residual risk through the appropriate decision maker.

Use a complete action statement: “Before the pilot starts, the operations lead will run the fallback workflow during a simulated service interruption and report whether staff can complete it.”

Add an observable warning sign and a response trigger. “Monitor adoption” is too vague. “Review incomplete handoffs each week; investigate when the same cause appears in successive reviews” is clearer, although the exact threshold must fit the operation.

Check that each owner has time and authority. An action cannot reduce a risk if it is assigned to someone who cannot perform it.

55–60 minutes: close and schedule review

Read out plan changes, open investigations, owners, and dates. Confirm which issues require escalation and who will take them there. Explain when the team will see an updated plan.

Ask: “Which concern remains uncomfortable to say aloud?” Give people a private follow-up route with clear confidentiality limits. Record that a risk remains unresolved where appropriate; forced reassurance defeats the purpose.

Hypothetical example: a new internal knowledge service

A team plans to launch a searchable knowledge service for support staff. The premortem scenario is that three months after launch, staff still use private messages and old documents.

The group identifies several explanations: articles have no maintenance owner, search terms differ from the language staff use, and the service is unavailable in the workflow where questions occur. These are hypotheses, not findings.

The team turns them into separate actions. It assigns an owner to each pilot article, tests search tasks with support staff, and observes where questions arise during real work. A proposed response to “people resist change” is replaced by an investigation of whether the service actually saves effort.

The team also identifies an access dependency. Its response is a permissions walkthrough before launch, with a fallback contact route for the pilot. The premortem has made the plan more testable; it has not established that the service will succeed.

A CLOSER LOOK

A useful risk entry ends with a commitment.

1. 01
   ConcernImportant knowledge articles may become outdated.
2. 02
   Response & ownerThe service owner confirms who maintains each critical article.
3. 03
   Review triggerAn unowned or overdue critical article prompts a review before expansion.

Facilitation problems and adaptations

Criticism triggers a defense speech. Pause and restate that collection comes before evaluation. Ask the sponsor to demonstrate curiosity with a clarifying question.

Every risk is external. Ask what the team controls: scope, staffing assumptions, handoffs, support arrangements, or the choice of pilot conditions. Do not imply that external risks are unimportant; distinguish influence from responsibility.

The group invents vivid but implausible disasters. Return to the causal pathway and available evidence. A memorable story is not a probability estimate.

The workshop ends with a long risk register. Choose a short set of actions and retain the rest for review. Volume is not a measure of usefulness.

For remote work, collect individual contributions before revealing everyone’s list. For a mature project, run separate scenarios for delivery failure and benefit failure. For a very early idea, use a smaller question such as “What would make this concept unusable?” and then return to discovery.

Origin, evidence, and limitations

Klein is the primary attribution for the method, and AHRQ cites his 2007 publication when explaining its use in quality improvement. This guide does not claim that the method was first conceived in that year or reproduce proprietary source graphics.

The wider research supports caution about interpersonal conditions. Edmondson’s field study found an association between psychological safety and team learning behavior. It does not demonstrate that calling a meeting a premortem causes candor or better results. Edmondson, 1999

Treat generated risks as candidate explanations to investigate. The method can still miss unknown dependencies, repeat shared assumptions, and overemphasize recent experiences. Pair it with evidence from actual users, operational data, and specialist review.

After the session, revise the plan and verify completion of the first actions. Use stakeholder mapping if missing perspectives emerged, and the change management guide to connect risk responses with implementation and adoption work.