A project plan usually describes how work should go. A premortem asks a different question: suppose the effort ended badly—what plausible events might have caused that outcome? Used carefully, the exercise can surface concerns that enthusiasm or hierarchy might otherwise keep out of the conversation.
Define the project and the imagined outcome
Start with a shared understanding of the scope and timing. Name a specific disappointing result: the guide was published late, the event confused participants or the handoff left the support team unprepared. A vague statement such as “everything failed” invites equally vague answers.
Keep the exercise proportionate to the project. A small content release may need a short discussion; a complicated operational change may require specialist review and a more formal risk process. A premortem is a planning aid, not a substitute for required technical, legal or safety checks.
Invite concerns before debating solutions
Give participants a little time to think independently, then collect possible causes. Ask about missing dependencies, unclear approvals, access, capacity and assumptions about the audience. Avoid making the first person’s answer the framework for everyone else’s thinking.
The Atlassian premortem play offers a structured approach to anticipating project risks and revisiting them. The short exercise described here is an editorial adaptation for everyday project work. Its value depends on honest participation and follow-through, rather than on completing a template.
Separate plausible risks from general anxiety
For each concern, describe a mechanism. “The launch will be stressful” is understandable but hard to act on. “The final approver is away during the only review window” identifies a dependency that the team can address. Ask what evidence supports the concern and what remains uncertain.
Do not require false precision. If the team cannot credibly estimate a probability, use a qualitative discussion of likelihood, impact and ability to respond. A numbered score is only useful when participants understand what it means. It should not disguise disagreement or lack of information.
Choose a small set of responses
Prioritise risks that could materially change the result and that deserve action now. Assign an owner to each chosen response. An action might be arranging a backup approver, testing access, reducing scope or scheduling a release check. Include a date or trigger when timing matters.
Consider a small website launch. One risk is that local pages work while public links still show an old version. A useful response is to check the public domain after deployment and verify a representative article and its assets. “Be careful during launch” would not provide an equivalent safeguard.
Leave room for change
Save the remaining risks without treating them all as immediate tasks. Identify signs that would make them more urgent. This protects the project from both extremes: ignoring uncertainty and expanding the prevention work until it becomes larger than the project itself.
Revisit the selected risks at a natural decision point, such as a scope change or the final preparation meeting. Close those that no longer apply and update those whose conditions have changed. Record actual observations rather than carrying forward a stale list because it looks thorough.
Finish by asking whether the exercise changes the plan. If it produces no actions, clearer assumptions or decisions, it may have remained too abstract. Put the chosen responses into the one-page brief and preserve important tradeoffs in the decision log. The purpose is a more workable project, not a convincing catalogue of everything that might go wrong.
Keep ownership practical
Choose one person to track the selected responses and make sure each action has a clear home in the existing plan. Avoid creating a separate risk document that no one sees after the meeting. If a preventive action takes substantial effort, include that effort in the schedule rather than expecting it to happen between other commitments.
Ask whether the action reduces the cause of the risk or merely adds another reminder. A backup approval owner addresses availability; a repeated request to approve on time may not. Where prevention is impossible, define how the team would recognise the problem early and who would decide what to do next.