The plan is approved. The launch date is in the calendar. Everyone is busy closing actions. Yet a few people have a quiet concern: training may not reach night-shift staff, the support team may not be ready, or the new process may create extra work at the worst possible time.
Those concerns often surface in side conversations, not in the risk register. By the time they become official issues, the team has fewer choices and every fix costs more.
A project pre-mortem gives the team permission to say the uncomfortable things early. It is a short, structured exercise that imagines the change has already failed, then asks what caused the failure. The aim is not pessimism. It is to find preventable problems while there is still time to act.
Why This Matters
Most projects do some form of risk management, but the quality of the conversation varies. A long risk register can create the appearance of control without improving a decision. Labels such as “stakeholder risk” or “technology risk” do not tell the team what might happen, why it matters or what to do next.
Good risk management supports better decisions. Australian Government guidance says risk management should be embedded in work practices and tailored to the nature and severity of the risk. Finance’s RMG 211 guidance also connects effective risk management to governance, assurance, change, business improvement and project planning.
This matters in service operations and digital transformation. A technically correct change can still fail because roles are unclear, information misses the right people, local workarounds are overlooked, or support is too thin. A pre-mortem exposes these weak points before launch pressure makes honest discussion harder.
What a Pre-Mortem Is, and Is Not
A post-mortem or retrospective looks back after work is complete. A pre-mortem looks forward by pretending the future outcome is already known. The facilitator might say: “It is three months after launch. This change did not deliver the expected result. What happened?”
Instead of asking whether failure is likely, this wording asks people to explain an imagined failure. Team members can raise awkward possibilities without declaring that the approved plan is wrong. Atlassian’s public pre-mortem play similarly explores what could go wrong, what could go right and what the project needs.
A pre-mortem does not replace a formal risk process, specialist assurance, privacy assessment, clinical governance, cybersecurity review or change approval. It is an input to those processes: a fast way to generate clearer risks, controls and questions for the right decision-makers.
How to Run a Useful Pre-Mortem in 45 Minutes
1. Pick the Right Moment and a Narrow Scope
Run the session when the team knows enough to imagine real failure modes but still has room to change the plan. Good moments include the end of discovery, before a pilot, before a major release or when direction changes.
Define one outcome and one time horizon. “Our new referral workflow failed within eight weeks” is more useful than “the transformation failed.”
2. Bring in People Close to the Work
Include people who will deliver, support and use the change, not only those approving it. Depending on the work, invite operations, frontline representatives, digital staff, data or privacy specialists, communications, training and service support.
Six to ten participants is usually enough. If a key group cannot attend, collect its input beforehand.
3. Create Safety Before Asking for Honesty
Open with three rules:
- we are testing the plan, not judging people
- concerns should be specific
- raising a risk does not mean opposing the project
Ask senior leaders to contribute after others so the first confident opinion does not set the direction.
4. Start With Silent Writing
Give everyone five minutes to answer the imagined-failure question independently, one idea per note. Silent writing helps quieter participants contribute and reduces groupthink.
Useful prompts include:
- What did users or staff find confusing?
- Which assumption turned out to be false?
- Where did work queue up or fall between teams?
- What information, approval or capability was missing?
- What happened outside normal business hours?
- What privacy, security, safety or equity concern did we overlook?
5. Group Causes, Not Just Symptoms
Read each note without debating it. Group similar ideas, then rewrite vague items as a cause-event-impact statement: “Because casual staff were not included in training, they used the old workflow after launch, creating duplicate records and rework.”
This is more actionable than “poor training.” Separate risks that may happen from issues already requiring action. If the discussion uncovers assumptions or choices that must not be lost, add them to a decision log while the context is still fresh.
6. Prioritise the Few That Deserve Action Now
Do not score every note with false precision. Ask:
- How serious would the impact be?
- How plausible is the scenario?
- How much influence do we have over it?
Use a quick vote, then discuss the top three to five risks. Record other credible items for normal risk review.
7. Turn Risks Into Controls, Triggers and Contingencies
For each priority risk, agree a preventive control, an early warning trigger and a contingency if the trigger is reached.
“Improve communications” is not a control. “Send the new procedure to all rostered staff, require acknowledgement and sample completion before go-live” is.
If failure scenarios reveal weak hand-offs or unclear roles, pause and map the workflow before automating or launching the change.
8. Finish With Ownership and Review
Every action needs one accountable owner and a due point linked to the plan. Add priority risks to the normal risk register or assurance record. Set a follow-up before launch and another after the first operating period.
A workshop without ownership is simply a collection of worries.
A Realistic Workplace Example
Imagine a team introducing an online form for internal service requests across several sites. Testing is complete and the launch plan looks sound. In the pre-mortem, the group imagines that demand has become chaotic six weeks after launch.
A coordinator says staff may keep emailing because they cannot tell whether the form was submitted. A service officer worries urgent requests will be mixed with routine work. An analyst notes that free-text fields could collect unnecessary personal information. A manager points out that the support mailbox is not monitored on weekends.
The team groups these into three priority risks: low confidence in the new channel, unclear urgency rules and inappropriate information collection. It adds a submission receipt and status message, defines an urgent escalation path, removes the unnecessary free-text field and tests the weekend support message. Each control has an owner and is checked before launch.
If the same demand and prioritisation problems keep appearing, the team may also need a clearer work-intake system, not just another launch action.
The exercise did not predict the future. It made hidden assumptions visible and gave the team cheap opportunities to strengthen the service.
Where AI Can Help, and Where It Should Stop
An approved workplace AI tool can expand the brainstorm after the team produces its own ideas. Give it a de-identified description of the change, intended outcome, constraints and categories already considered. Ask for additional scenarios across people, process, technology, data, governance and support.
Treat the output as prompts, not findings. People who understand the work must decide what is credible, check evidence and own every response. Do not paste personal, sensitive, confidential or security-relevant information into an unapproved tool. Australian privacy guidance warns against entering personal or sensitive information into publicly available generative AI tools, while government AI guidance emphasises accountability, transparency and safety.
Common Mistakes to Avoid
- Turning it into a complaint session. Rewrite complaints as specific failure scenarios tied to the outcome.
- Letting seniority shape the list. Start silently and hear all notes before leaders give their view.
- Treating every idea as urgent. Focus immediate action on a few credible, high-impact risks.
- Writing controls that cannot be verified. Use observable actions, owners and triggers.
- Ignoring upside. Ask what unexpected success might look like and how to capture it.
- Using AI as the risk owner. AI can widen questions; accountable people validate and decide.
Try This This Week
Choose one upcoming change with a real decision still open. Invite five to eight people for 45 minutes. Send this sentence in advance: “Imagine it is six weeks after launch and this change has failed to deliver its intended outcome. Write down three reasons why.”
Spend five minutes setting the scene, five minutes writing silently, ten minutes sharing and grouping, ten minutes prioritising, ten minutes choosing controls and five minutes confirming owners.
Leave with no more than five priority risks, each with a control, warning trigger, contingency and owner.
Key Takeaway
A pre-mortem cannot make a project failure-proof. It creates a brief, safe pause before commitment hardens and launch pressure takes over. By imagining failure together, teams can turn quiet concerns into visible choices and act while the fixes are still small.
If this approach would help your team, connect with Raf on LinkedIn or follow rafsanga.com for practical ideas on project delivery, service improvement and responsible workplace AI.
AI tools assisted with research and drafting. The final article was reviewed and approved by the author.
Sources and Further Reading
- Atlassian Team Playbook: Pre-mortem project management strategy
- Australian Government Department of Finance: Commonwealth Risk Management Policy
- Australian Government Department of Finance: Implementing the Commonwealth Risk Management Policy (RMG 211)
- Office of the Australian Information Commissioner: Privacy and commercially available AI products
- Digital Transformation Agency: AI technical standard for responsible government adoption
Comments
Post a Comment