“Does anyone see a risk?” often produces a short discussion and a reassuring answer. A project premortem asks a sharper question: “Imagine the project has already failed. What happened?” That change in perspective gives people a concrete story to examine while there is still time to alter the plan.
The workshop should lead to a small number of changes to the project: an assumption to test, a safeguard to add, a warning sign to watch, or a commitment to renegotiate.
When to run a project premortem
Run the exercise after there is a recognizable plan but before expensive or difficult-to-reverse commitments. A new rollout, migration, event, or cross-team launch can be a useful candidate. If the project changes substantially, revisit the relevant risks rather than repeating the whole workshop mechanically.
A premortem looks forward through an imagined failure. A retrospective examines work that actually happened. A risk register stores and tracks risks over time. The workshop can feed that register, but it is not a substitute for technical testing, contractual review, or specialist safety analysis.
Atlassian's premortem play uses individual idea generation, discussion, and owned actions to explore project risks. The format below applies that general approach to a launch scenario with particular attention to early warning signals.
Write a failure scenario people can picture
Avoid “The project went badly.” Name a time horizon and an outcome that matters. For a customer-support migration, try: “It is one month after rollout. Customers are still contacting old inboxes, agents cannot find previous conversations, and the team has restored the old system.”
This is a hypothetical scenario for the exercise, not a forecast. It supplies a shared starting point without telling participants which causes to invent. A scenario limited to “we missed the date” can hide a project that launches on time but fails its users.
Share the current project plan, the intended outcome, and known constraints beforehand. Invite people who deliver the change and people who must live with it. For the support migration, agents and administrators may notice failure paths that the project sponsor cannot see.
Run the workshop without turning it into a debate
Start by saying that criticism concerns the plan, not the competence of its authors. Ask everyone to write possible causes independently. Give each cause its own note. Leaders should hold back their preferred explanation until others have contributed; otherwise the board can become a list of reasons that support the first senior opinion.
Read the notes before grouping them. “Training incomplete” and “agents cannot answer unusual questions” may be related, but they are not identical. One concerns attendance; the other concerns capability. Combining them too early can lose the actionable detail.
For each group, ask how the failure would unfold. Replace “poor communication” with a chain such as “the new contact address is announced only in a newsletter; customers reuse old threads; nobody monitors the old inbox after cutover.” That gives the team several places to intervene.
Worked example: migrating a support operation
The following hypothetical board shows how a failure story becomes a set of decisions. Names and dates would be added by the actual project team; the roles shown are examples of where ownership might sit.
| Possible cause | Early warning signal | Proposed response | Owner to confirm |
|---|---|---|---|
| Old conversation history is incomplete | Sample migrated cases lack attachments or links | Reconcile representative cases before approving cutover | Migration lead |
| Customers continue using old inboxes | Pilot users reply to previous email threads | Plan a monitored transition route and clear customer messages | Support operations |
| Agents know the interface but not exception handling | Practice cases repeatedly require administrator intervention | Rehearse unusual cases and define an escalation route | Training lead |
| Rollback is described but not usable | No one can explain how new conversations would be preserved | Test the recovery procedure before launch approval | Technical owner |
Notice that “the migration fails” is an outcome, not a cause. Likewise, “monitor the project” is not a response until someone specifies what to observe and what decision follows.
Prioritize without pretending to know exact probabilities
Discuss consequence, evidence that the risk is plausible, and how late the team could still respond. A risk that is easy to reverse next week is different from one that becomes visible only after an irreversible cutover. If participants lack a basis for a probability estimate, mark it unknown rather than inventing a precise percentage.
Voting can identify concerns worth discussing, but it should not determine the final response by itself. A specialist may recognize a serious failure mode that receives few votes because nobody else understands it. Ask for the reasoning and route the issue to the appropriate expert.
Choose actions that fit the decision. Testing a sample migration may be worthwhile before approving a large rollout. Rewriting every training document might be wasteful if a short practice session first reveals that the main problem is access permissions.
Distinguish prevention from contingency
A preventive action reduces the chance of a failure or its impact before it occurs. A contingency says what the team will do if a trigger is reached. The support team can reconcile migrated records before launch as prevention. It can also define conditions for delaying rollout or restoring service as contingency.
Keep the trigger observable. “If things look bad” forces people to negotiate under pressure. “If a required case type cannot be processed in the rehearsal” gives the launch owner something concrete to evaluate. The threshold should reflect the project's service requirements, not an arbitrary number copied from an example.
Record consequential choices in a decision log, including who may accept residual risk. The workshop should not quietly transfer that authority to whoever facilitates the meeting.
Keep difficult concerns visible after the session
Some participants may be reluctant to criticize a sponsor's timeline in a group. Offer a way to contribute concerns before the meeting and follow up on unresolved disagreements. Do not promise anonymity unless the collection method actually provides it.
Use a RACI matrix if responsibility for an action remains unclear. On the premortem board, keep the simpler view: risk, signal, response, owner, and next decision date. Link the actual delivery task so progress is not tracked in two competing places.
Open Boardmix and put the support-migration failure scenario across the top of the canvas. Underneath, create the four columns from the example: Possible cause, Early warning signal, Proposed response, and Owner to confirm. Keep each cause and its response in the same row. For missing conversation history, connect the failed sample-case check to a reconciliation task owned by the migration lead. Before approving cutover, review that task and the other unresolved signals. If required attachments are still missing, the launch owner has a concrete reason to delay.
![How to Create Mind Map in Google Drive [3 Methods]](https://cms.boardmix.com/images/article-image/mind-map-google-drive.png)
