A retrospective is a genuinely useful tool, and it runs after the damage is already done. A pre-mortem asks the same honest question, what went wrong, before the project even starts, while there's still time to actually change something about how it's run.
A pre-mortem isn't about assuming the worst for its own sake. It's about surfacing the risks people already sense but rarely say out loud until after they've happened.
A retrospective happens after it's already too late to prevent
By the time a retrospective happens, whatever went wrong already went wrong, and the conversation becomes about damage control and lessons for next time rather than prevention this time. A pre-mortem moves that same honest conversation to the one point where it can still change the outcome.
Assume the project already failed, and work backward from there
Ask the team to imagine the project has already failed, six months from now, and describe why. This framing surfaces specific, concrete risks far more effectively than a general "any concerns" question, because it removes the awkwardness of predicting failure directly.
In Stelaah, a project's risks and open questions can be logged directly on the record from day one, so a pre-mortem's findings stay visible throughout the engagement instead of being forgotten after the kickoff meeting. See how projects works.
Make it genuinely safe to name an uncomfortable risk out loud
The most useful risks in a pre-mortem are often the ones nobody wants to say first, a stakeholder who's historically difficult, a timeline everyone privately doubts. Make it explicitly safe, even anonymous if needed, to name those risks without it feeling like a criticism of the plan or the people who made it.
Turn each identified risk into an owned action, not just a note
A pre-mortem that produces a list of risks and stops there hasn't actually changed anything about the project. Assign a specific mitigation or a specific person watching for each real risk identified, so the exercise changes what actually happens, not just what's on record.
Revisit it at a real milestone, not just at kickoff
A pre-mortem run once at kickoff and never revisited misses risks that only become visible partway through. Bring the same exercise back briefly at a major milestone, when there's still enough runway left to act on what it surfaces.
A simple checklist
If you do nothing else, do these five things:
- Ask the team to imagine the project already failed and explain why.
- Make it genuinely safe to name uncomfortable risks out loud.
- Assign a real owner or mitigation to each identified risk.
- Revisit the exercise at a real milestone, not just at kickoff.
- Keep the findings visible throughout the project, not filed away after the meeting.
Do that, and a pre-mortem becomes a tool that actually changes how a project runs, not just a record of what everyone worried about.
Run your client work in one place. Stelaah keeps projects, clients, contracts, and invoices together, with Aria for the busywork.
Start freeWe build Stelaah, the workspace for client work. We write about running teams, agencies, and venues without the busywork.
