Premortem analysis: find project risks before work starts

A premortem analysis asks a team to imagine that a planned project has failed, then work backwards to explain how it happened. The useful output is a set of plausible risks, assumptions to test and practical responses. Run it while there is still time to change the plan, and finish by deciding who will check the most important concerns and when.

The exercise gives people a concrete way to discuss uncomfortable possibilities before money, time and reputation become harder to recover. Its scenarios are hypotheses. A vivid story about failure does not establish that the failure is likely, and agreement in the room does not prove the proposed response will work.

This guide explains the method, where it fits alongside other project practices, and how to turn a useful discussion into decisions. The worked example is fictional and concerns an ordinary business project.

What is a project premortem?

In a project premortem, participants temporarily treat a future failure as something that has already happened. Rather than asking a general question about what might go wrong, the facilitator specifies an outcome and invites explanations for it. Gary Klein describes this basic approach in his 2007 Harvard Business Review article on project premortems.

For example: “It is three months after the new client onboarding process launched. Clients are still waiting for access, support requests have increased, and the team has returned to the old process. What contributed to this result?”

That prompt is easier to investigate than “Any concerns?” It points to an outcome, a timescale and consequences. Participants can examine dependencies, incentives, workload, decisions and assumptions instead of searching for a generic list of dangers.

Keep the distinction between the imagined outcome and current evidence visible throughout. Someone might suggest that clients will ignore an invitation email. The team then needs to ask whether existing support tickets, delivery problems or past onboarding experience support that concern. The imagined failure starts an enquiry; it does not settle it.

Premortem, postmortem, retrospective and risk register

These practices can support the same project at different points.

• A premortem explores how a future plan could fail so the team can reconsider assumptions and prepare responses.

• A postmortem examines an actual failure or incident using what happened and the evidence available afterwards.

• A retrospective considers work already done and changes the team wants to make to its way of working. It need not follow a failure.

• A risk register keeps track of identified risks, responsibility, responses and review. A premortem can supply new entries or challenge existing ones.

Choose the practice around the question. If a delivery has already gone wrong, begin with the actual sequence of events. If the plan is still adjustable and the team is unsure what it has overlooked, a premortem may be useful. For learning from completed work, see the distinction between an after-action review and a retrospective.

Avoid treating a premortem as a replacement for ongoing risk management. A discussion on Monday will not cover every change in a supplier, budget or customer requirement over the following months.

When is a premortem worth running?

Consider one before a meaningful commitment: launching a new service, changing a recurring process, beginning a cross-team project or choosing an implementation approach. It is particularly useful when the plan depends on several assumptions that different people understand differently.

There must be enough of a plan to challenge. If the purpose, audience and intended result are all undefined, clarify them first. Otherwise, participants may imagine failures of completely different projects.

There must also be room to act. If the decision is irreversible tomorrow and no one can alter scope, resourcing or timing, say so. A shorter discussion about contingency and escalation may be more useful than pretending the whole plan is open.

Set a boundary around the exercise. The approach below supports ordinary project planning. Specialist safety, security, clinical or regulatory assessments need the appropriate experts, evidence and established procedures; a workshop cannot stand in for those assessments.

Prepare a specific scenario and the right group

Share a short description of the plan before the session. Include the intended result, main milestones, known constraints, important dependencies and decisions that are still open. Make clear which assumptions have evidence and which remain guesses.

Invite people who see different parts of the work: those doing it, those receiving the result and those responsible for a dependency. For the onboarding example, that could include client services, support, an account administrator and the person approving the process. A large group is not automatically more informative; missing a crucial perspective matters more than reaching a headcount.

Choose a facilitator who can keep explanations separate from blame. If the project sponsor is also facilitating, ask them to hold back their own scenario until others have contributed. Give people a way to raise a concern privately if the hierarchy makes open discussion difficult, while being honest about who will see it.

Agree how notes will be kept and who may receive them. If you record the discussion, obtain the required agreement and follow your organisation’s rules. A private concern should not unexpectedly appear in a widely circulated transcript.

A practical premortem method

The following sequence is a suggested facilitation approach, rather than a claim that every premortem follows one standard agenda. Adjust the time to the complexity of the decision and the number of participants.

1. Describe the failure clearly

Set a future date and a recognisable outcome. Avoid “the project was a disaster”, which leaves each person to invent a different definition of failure.

For the onboarding project, use: “By the end of the first month, new clients are still waiting more than two working days for access, and the support team is handling the same setup questions repeatedly.” These are fictional targets for the example, not industry benchmarks.

Check that everyone understands the imagined outcome and the current plan. Do not spend the opening arguing about whether the failure will happen; the premise is a temporary tool for generating possibilities.

2. Let people think independently

Ask each participant to write possible causes before the group discusses them. One cause per note makes later grouping easier. Encourage specific mechanisms: an approval sits with someone who is away, an invitation expires, or a required client detail is missing.

Prompts can cover different parts of the plan:

• Which dependency arrived late or changed without warning?

• What did the plan assume about capacity, access or knowledge?

• Which handoff looked complete to one team but incomplete to another?

• What warning did people see without knowing where to raise it?

• What would the recipient find difficult even if the internal process ran as designed?

3. Share explanations without defending the plan

Hear from each person and clarify what their scenario means. Group similar explanations, but retain meaningful differences. “Clients did not get access” might conceal separate problems with email delivery, permissions and account ownership.

Rewrite blame into a process question. “Support did not care” is difficult to act on. “Support had no agreed owner or capacity for first-week onboarding questions” identifies something the plan can address.

Record disagreement. If one person thinks a dependency is secure and another doubts it, note the evidence each has rather than compressing both views into false agreement.

4. Separate evidence, assumptions and unknowns

For each important explanation, ask what is already known. Mark it as supported by current evidence, a plausible assumption, or an unknown requiring investigation. Do not add precise probabilities simply because a spreadsheet has a column for them.

A concern with weak evidence can still deserve attention when the consequence is serious and checking it is cheap. Conversely, a memorable but remote story should not automatically outrank a mundane dependency that repeatedly causes delays.

5. Choose a small number of responses

Consider consequence, warning time, the team’s ability to influence the cause and the effort needed to investigate or respond. Voting can reveal which concerns people want to discuss first, but a popular concern is not necessarily the most consequential one.

Select a response appropriate to each concern: test an assumption, reduce exposure, change the plan, prepare a fallback or accept a risk with a clear reason. Give each response an owner, a check date and evidence that would justify the next decision.

6. Review the plan after the workshop

Read back the selected actions and unresolved questions. Confirm what changed, what still needs a decision and who has authority to make it. Transfer continuing risks into the project’s usual tracking system, then choose a review point linked to a milestone or an observable warning.

The UK government digital health team’s account of its premortem workshop offers a concrete example: the team developed practical next steps and subsequently linked action cards to risk and opportunity cards in its planning system. That is an account of one team’s practice, rather than evidence of a guaranteed project outcome.

Worked example: a client onboarding change

Imagine a small service business replacing an informal onboarding process with a standard sequence. The proposed result is that each new client can access the shared workspace and knows where to ask for help.

During the premortem, the team identifies three plausible explanations for the imagined failure.

Missing client information delays setup. The team knows that two different forms currently request different information. The response is to test one agreed intake form against several fictional client scenarios. The operations lead owns the check before the pilot begins. The question is whether an administrator can complete setup without chasing an unstated prerequisite.

Invitations arrive, but recipients cannot use them. This is a hypothesis, not an observed failure of the new process. The account administrator will run a test with a colleague outside the project team, using the same instructions planned for clients. If the recipient needs verbal help, the instructions or access steps need revision.

No one owns the first-week questions. The proposed support arrangement has not yet been agreed. The project sponsor must confirm an owner and available capacity before expanding the pilot. If capacity cannot be provided, the team will reconsider the rollout size.

These responses produce different kinds of evidence: a checked input, an observed walkthrough and an explicit resourcing decision. “Be more careful at launch” would leave all three problems unresolved.

Keep the fictional failure narrative in the workshop notes, but make the working actions readable without it. A colleague should be able to tell what to do next without reconstructing an hour of discussion.

Turn the discussion into reviewable notes

Capture enough context to connect each response to its reason. A concise follow-up should distinguish the imagined scenario, evidence discussed, decisions actually made, proposed actions and open questions. Confirm names and dates with the people concerned before treating an action as accepted.

If you use Weeve to work with a recording, Chat with recordings can help produce a draft follow-up from the captured discussion. Ask it to keep suggestions separate from agreed commitments, and check the result against the recording. An assistant can omit a caveat or misattribute a statement; the team still needs to approve the final account.

The genuine app image shows a menu for drafting follow-up outputs using demonstration content. It does not show actions being assigned or executed in another tool.

For ongoing tracking, use a project risk register to retain the risk statement, response, ownership and review decision. Avoid copying every speculative workshop note into a list that nobody maintains.

Common ways a premortem loses its value

The scenario is too broad. Narrow the outcome and timescale until people are examining the same plan. Several separate projects may need separate discussions.

The sponsor answers every concern immediately. Collect and clarify explanations before debating solutions. Ask for the evidence behind reassurance as well as the evidence behind concern.

The team confuses imagination with prediction. Label hypotheses and test the assumptions that matter. Do not turn the number of ideas generated into a forecast of project failure.

Every risk receives an action. A long list can exceed the team’s capacity. Prioritise, record why some risks are being accepted or deferred, and revisit that decision when conditions change.

Nothing changes afterwards. Before closing, identify the first decision or check that the workshop has created. If there is none, revisit whether the discussion found an actionable concern or whether its scope was wrong.

A useful premortem leaves the team with a clearer plan and a small set of accountable enquiries. Start with one adjustable project, define the failure you want to examine and reserve time to decide what the discussion changes.