Premortem analysis is a planning exercise in which a team imagines that a proposed project has failed, then works backward to identify plausible causes. The team uses those findings to challenge assumptions, change the plan and agree what to monitor before committing further resources.
For project leaders, delivery managers and transformation teams, its value lies in what happens next: a dependency gets an owner, an unrealistic rollout is phased, or a critical assumption is tested before approval. A useful premortem ends with decisions that someone can carry out.
Use the copyable premortem template, follow the 60-minute workshop agenda, or jump to the completed transformation example. The agenda and worksheet below are practical adaptations; the example is hypothetical.
What is premortem analysis?
A project premortem changes the starting point of the discussion. Instead of asking people to endorse a plan and then offer reservations, the facilitator asks them to imagine a future in which the intended outcome was missed. Participants describe how that failure could have happened.
Psychologist Gary Klein describes the premortem method as an exercise in which a team considers the possible causes of a proposed plan’s imagined failure. That failure is a scenario for investigation, not a prediction.
For example, “the project failed because communication was poor” is too broad to guide action. “Operations learned about the new workflow after staffing was approved, leaving nobody available for the pilot” describes a mechanism the team can check. Ask which decision, constraint or interaction would produce the outcome.
The exercise can create an opening for concerns that are difficult to raise during an enthusiastic project launch. It still depends on how people are treated. If a sponsor punishes uncomfortable observations, changing the workshop’s name will not make the conversation safe.
Premortem vs postmortem vs risk assessment
| Approach | When | Starting question | Useful output |
|---|---|---|---|
| Premortem | Before a commitment or phase transition | Imagine the plan has failed. What caused it? | Plausible failure causes, evidence checks and plan changes. |
| Risk assessment | During planning and delivery | What could go wrong, and how should we respond? | Assessed risks, chosen responses and continuing review. |
| Postmortem | After an event or completed project | What happened, why, and what should change? | Lessons grounded in actual outcomes and improvement actions. |
A premortem can feed a risk assessment with concerns that deserve investigation. It does not establish their probability or replace the assessment. A postmortem can provide evidence from earlier projects that makes the next premortem more grounded. These approaches can work together.
When should you run a project premortem?
Run one when a plan is concrete enough to examine but flexible enough to change. Useful points include approving a business case, committing to a delivery date, expanding a pilot or moving several business units onto a new platform. Repeat the exercise when major assumptions or dependencies change.
A premortem has limited value if every important decision is already irreversible. In that situation, focus the discussion on the remaining choices: containment, contingency, sequencing and escalation. State those boundaries honestly.
Who should participate?
Invite people who see different parts of the work: delivery, operations, frontline users, technical dependencies and the business outcome. Include someone who can authorize changes or obtain a decision promptly. A facilitator should keep the process moving without becoming the defender of the plan.
For a focused session, start with a small cross-functional group whose members can each contribute. Collect written input from people who cannot attend. In remote or hybrid meetings, use the same shared worksheet for everyone and provide quiet writing time before discussion.
Prepare the decision before the meeting
- Send a short outline of the plan, intended outcome, major milestones and constraints.
- Choose a future date and define what failure would mean for customers or operations.
- Identify which decisions the group can change and which require escalation.
- Bring available evidence: capacity plans, dependencies, pilot findings and lessons from previous work.
How to run a premortem: a 60-minute workshop
The following agenda is a suggested format for one bounded decision. Complex programmes may need separate sessions and further analysis. Preparation happens before the hour; unresolved evidence checks continue afterward.
| Time | Activity | Required output |
|---|---|---|
| 0–5 minutes | Frame the scenario | A shared plan, outcome and imagined failure date. |
| 5–12 minutes | Write independently | Individual lists of plausible causes. |
| 12–25 minutes | Share without defending | A visible set of concerns. |
| 25–35 minutes | Group and test causes | Specific mechanisms and evidence to check. |
| 35–50 minutes | Choose responses | Plan changes, owners and warning signals. |
| 50–60 minutes | Confirm follow-through | Recorded decisions, review dates and escalation triggers. |
1. Frame the scenario
Use a concrete prompt: “It is three months after launch. The platform is live, but customer-service delays have increased and two units have returned to the old process. What caused this outcome?” Confirm the scenario is imagined. The purpose is to examine the plan, not to accuse people.
2. Write independently
Give participants uninterrupted time to list plausible causes before seeing other answers. Encourage specific concerns about workload, ownership, incentives, dependencies and user behavior. Independent input preserves observations that might disappear after a confident colleague sets the direction.
3. Share without defending
Invite contributions in turns and record the substance accurately. Clarifying questions are welcome; immediate rebuttals should wait. Ask the sponsor to avoid evaluating every concern as it appears. A facilitator can ask, “What would we need to observe for this to become a real problem?”
4. Group and test causes
Combine genuine duplicates, but keep distinct causes separate. Label what is known, assumed and unknown. Replace statements such as “users will resist” with a mechanism: users may lack time to practice, face conflicting targets or depend on a workflow the new platform does not support.
5. Choose responses
Discuss consequence, plausibility, evidence and the time available to respond. A vote can help choose where to investigate first, but popularity is not a risk estimate. Preserve a serious minority concern even if it receives few votes. Agree which issues require a plan change, a test, monitoring or explicit acceptance.
6. Confirm follow-through
Assign an accountable owner and date to each response. Specify the warning signal and the decision it should trigger. Read back the changes before closing. If nobody can authorize a response, record the escalation owner and the deadline for obtaining a decision.
Premortem analysis template
Copy the fields below into your project document or collaboration tool. Complete the session header once, then repeat the concern record for each priority scenario. This format keeps the worksheet readable on a phone and avoids an oversized eight-column table.
| Field | What to record |
|---|---|
| Project and decision | Name the initiative and the commitment under review. |
| Outcome and horizon | Define success and the future date used in the scenario. |
| Imagined failure | Describe the outcome the exercise will investigate. |
| Participants and authority | Record represented perspectives, facilitator and decision owner. |
| Field | Prompt |
|---|---|
| Imagined failure | What has gone wrong for the project, customer or operation? |
| Plausible cause | What specific mechanism could produce that outcome? |
| Evidence to check | What supports the concern? What remains an assumption? |
| Early warning signal | What observable sign would tell us the concern is developing? |
| Response or plan change | What will we test, change, monitor or explicitly accept? |
| Accountable owner | Who will ensure the agreed response happens? |
| Review date | When will the evidence and response be reviewed? |
| Escalation trigger | What finding prompts which decision, and who can make it? |
Keep speculation visibly separate from evidence. “The vendor will fail” is an unsupported conclusion. “The critical interface has no agreed acceptance test” is a checkable condition. A useful record allows another person to understand why the concern matters and what happens next.
Blank copy-and-fill worksheet
Select and copy this worksheet into your working document. Complete the session header, then duplicate the concern record for each priority finding. Replace every bracketed prompt with your own information.
SESSION HEADER Project and decision: [initiative and commitment under review] Outcome and horizon: [success criteria and future date] Imagined failure: [the outcome we are investigating] Participants and authority: [participants, facilitator, decision owner] CONCERN RECORD Imagined failure: [what has gone wrong] Plausible cause: [how it could happen] Evidence to check: [known facts, assumptions and missing evidence] Early warning signal: [observable condition or threshold] Response or plan change: [test, change, monitor or accept] Accountable owner: [one person or role] Review date: [specific date or project-relative deadline] Escalation trigger: [condition, decision required and decision maker]
Worked example: a transformation rollout
Hypothetical example: an organization plans to introduce a customer-service platform across three business units. The initial plan launches all units together after training. The premortem imagines that service delays rise and staff return to old tools. The following findings illustrate how the team could revise its plan; they are not results from a real engagement. All deadlines, sample sizes and thresholds below are illustrative assumptions for this scenario, not universal readiness standards. “Business days” means the organization’s working days.
Concern 1: specialist capacity is overcommitted
Participants identify that the same subject-matter experts are expected to support configuration, migration and training. The evidence check compares their actual allocations with overlapping milestones. The warning signal is unresolved demand for the same people during the same period.
Decision: phase the rollout and protect named specialist capacity. The delivery lead owns the revised schedule and checks allocations at the next weekly review. For this example, each critical specialist’s allocation must be confirmed ten business days before pilot entry. If any allocation remains unconfirmed at that deadline, the delivery lead escalates to the sponsor for a scope or schedule decision within two business days.
Concern 2: integration work has no clear owner
Each team expects another team to validate a critical interface. The evidence check looks for an accountable owner, agreed acceptance criteria and a scheduled test. A missing owner or untested critical workflow is the warning signal.
Decision: assign integration ownership and run the agreed tests before expansion. The integration lead presents evidence at the readiness review. For this example, every agreed critical workflow must have a named owner and pass its end-to-end acceptance test by five business days before expansion. Any missing owner or failed test at that review pauses expansion; the sponsor and integration lead agree the revised plan before a new date is committed.
Concern 3: attendance is mistaken for adoption
Training attendance looks healthy, but nobody has checked whether users can complete essential tasks in realistic conditions. The pilot observes those tasks and records workarounds, errors and support needs. Repeated inability to complete essential work is the warning signal.
Decision: the operations lead owns task-based readiness checks and addresses blockers before expanding. At the next pilot review, this example uses 20 representative users across the three units, each attempting three agreed essential tasks. Expansion requires at least 18 of the 20 users to complete all three tasks without facilitator intervention, with no unresolved critical errors among the attempts. Falling below either condition triggers targeted changes and a repeat check before expansion. This small sample is an operational checkpoint, not statistical proof of readiness; real criteria must reflect the service’s risks. Attendance alone cannot establish operational readiness.
The revised plan now sequences deployment, protects capacity, assigns integration responsibility and tests real work. The premortem has produced choices that can be checked. It has not proved that the project will succeed or that these are its only risks.
Completed worksheet: specialist capacity
This record uses the same fields as the blank worksheet. Its project-relative deadlines are hypothetical; convert them to calendar dates before using the record.
SESSION HEADER Project and decision: Customer-service platform; approve pilot entry and the proposed three-unit rollout sequence. Outcome and horizon: Three months after launch, all three units use the essential workflows without increased service delays. Imagined failure: Service delays rise and two units return to old tools. Participants and authority: Delivery, integration, operations and unit representatives; a facilitator runs the session; the sponsor approves scope or milestone changes. CONCERN RECORD Imagined failure: The pilot starts without enough specialist support, so unresolved issues carry into the wider rollout. Plausible cause: The same experts are assigned to configuration, migration and training during overlapping milestones. Evidence to check: Compare the resource plan with team allocations; confirm actual availability with each expert's line manager. Early warning signal: Any critical specialist allocation is still unconfirmed ten business days before pilot entry. Response or plan change: Phase the rollout and protect named capacity; reduce scope or move the milestone if the gap cannot be resolved. Accountable owner: Delivery lead. Review date: Ten business days before pilot entry. Escalation trigger: Any critical allocation unconfirmed at review; sponsor decides on scope or schedule within two business days.
Turn premortem findings into delivery decisions
Move agreed responses into the place where delivery is actually managed. Use the risk register for risk ownership and review, the decision log for approvals, and the delivery plan for changed activities and dates. Link these records instead of creating competing versions of the same action.
At the next review, ask what evidence changed, whether the response happened, and whether its effect is adequate. Delivery assurance provides a natural context for checking whether those actions improve confidence in the intended outcome.
A concern about overloaded teams may require a portfolio decision. If several initiatives depend on the same specialists or operational teams, examine change saturation rather than asking one project manager to solve a shared capacity problem alone.
The exercise surfaces information; it does not decide every issue by consensus. Agree who can approve a change, who must be consulted and when escalation is required. See collective decision-making for choosing decision rules and retaining clear accountability.
Five checks before closing the session
- Specific scenario: is the possible failure clear enough to investigate?
- Evidence: which assumptions need testing before commitment?
- Response: what changes in scope, sequence, capacity or controls?
- Owner: who will carry out each response, and by when?
- Review: when will we revisit it, and what signal prompts action?
Common premortem mistakes
- The sponsor answers first. Collect independent input before discussing interpretations. Groupthink in the workplace can make an apparently unanimous discussion less informative.
- Silence is treated as agreement. Ask participants privately or in writing what reservations remain. The Abilene paradox is a useful reminder that visible agreement can conceal private objections.
- Concerns blame personalities. Describe conditions and behaviors that can be investigated: conflicting incentives, missing authority or unavailable capacity.
- Risk scores imply certainty. Record the basis and uncertainty behind judgments; distinguish a convenient rating from measured probability.
- The exercise generates only a longer list. Select concerns for action, retain unresolved items and make escalation explicit.
- No evidence changes the plan. Ask what the sponsor is willing to change before scheduling the session. Document accepted exposure if the plan stays unchanged.
A premortem can miss unfamiliar failure modes and can overemphasize vivid stories. Balance scenarios with delivery data, specialist review and evidence from comparable work. Use it as one input to judgment, alongside the analysis appropriate to the project.
Frequently asked questions about premortem analysis
What is a premortem in simple terms?
It is a rehearsal of possible failure before a decision is finalized. The team imagines the plan has failed, identifies plausible reasons and uses the findings to improve the plan.
How long should a premortem take?
A focused decision can use the suggested 60-minute agenda above, with preparation beforehand. A complex programme may need several sessions. Allow additional time to investigate assumptions and obtain decisions afterward.
Is premortem analysis the same as a risk assessment?
No. A premortem is a way to generate and examine possible failure scenarios. Risk assessment evaluates risks and informs responses. Premortem findings can become inputs to that broader process.
Can a premortem work for remote teams?
Yes. Share the scenario in advance, use a common document, allow quiet writing and collect contributions before discussion. Record decisions where participants can review and act on them afterward.
Can AI help with a premortem?
AI can suggest prompts or help organize a de-identified list of concerns. Treat its suggestions as hypotheses, not evidence. Preserve independent human input first, and have people with relevant context validate every proposed cause and action.
How do you know whether the premortem was useful?
Check whether it exposed an important assumption, led to a justified plan change, assigned a response or established a meaningful warning signal. A long list of risks is not sufficient evidence of value.
Use the findings to improve the system
When several scenarios point to the same constraint, examine that shared condition. Repeated capacity conflicts, filtered information or unclear decision rights may require changes beyond the individual project. That is where a premortem can inform a wider System Shaping inquiry.
Explore the System Shaping Library for the book and supporting resources on recurring organizational problems. Start with one decision your team can change, then check whether the change improves the conditions of delivery.
Sources and scope
- Gary Klein: Premortem method of risk assessment — primary explanation of the method.
- Atlassian Team Playbook: Pre-mortem — a practical facilitation resource and alternative workshop format.
The workshop timings, worksheet and hypothetical rollout example in this article are practical adaptations for project and transformation teams. They are not a validated scoring system or a guarantee of delivery success.