It’s Tuesday morning. You open your project tracker and see the little green circle next to the “API Integration” epic. All looks good. Then a Slack message from the lead engineer pops up: “Hey, got a minute? The platform team just told us their service is delayed by three weeks.”
The little green circle was a lie. Not a malicious lie, but a useless one. Your weekly report, dutifully sent out last Friday, assured everyone that progress was steady. Now you have to send a follow-up, full of apologies and revised timelines. You’re not managing the project; you’re a historian documenting its slow-motion collapse.
Most project reporting is reactive. It’s a rearview mirror, telling stakeholders what already happened. By the time a risk turns a status from green to red, the damage is done. The fire is already burning.
We need to trade our historian hats for firefighter helmets. Better yet, for architect blueprints. We need a report that anticipates the fire and prevents it from ever starting. This is the Pre-Mortem Report.
From Autopsy to Blueprint
A standard project pre-mortem is a brainstorming exercise where a team imagines a project has failed and works backward to figure out why. It’s effective for surfacing risks. The Pre-Mortem Report turns that exercise into a living document that becomes the true source of stakeholder confidence.
It’s not a risk register buried in Confluence. It’s a concise, opinionated document you create before a project kicks off or a new phase begins. It becomes the contract between you and your stakeholders about what you’re actually worried about and what you’re doing about it.
Here’s how to create and use one.
Step 1: Host the "Project is Dead" Meeting
Get the core team together. Not the whole company, just the engineer lead, the designer, the marketing lead—the people whose work determines success or failure.
Your opening prompt is simple and dramatic: “It’s two months from now. The project is a complete disaster. We missed the deadline, the feature is buggy, and leadership is furious. What happened?”
This framing is critical. It bypasses our natural optimism bias. Instead of asking “What are the risks?”, which encourages timid or vague answers, you’re asking for a fictional history of a catastrophe. The answers will be more honest and specific.
- “The designs kept changing after the sprint started.”
- “We got blocked waiting for the legal team’s approval on the copy.”
- “The third-party API we rely on had a major outage the week before launch.”
Capture every reason on a virtual whiteboard. Don’t judge or solve yet.