A pre-mortem is a forty-five-minute meeting, held before kickoff, where the team pretends the project has already failed and writes down why. I run one on every project now. It surfaces the risks that a normal planning session never hears, because "imagine it went wrong" gives people permission to say things they would not say as "I have a concern".
How does it actually run?
A pre-mortem runs in three moves: one framing sentence, five minutes of silent writing, then a round-robin readout. The framing is "it is six months from now, the project has failed badly, and we are explaining what happened." The whole thing takes forty-five minutes.
The full sequence:
- Read the framing sentence. No context-setting, no reassurance, nothing else.
- Five minutes of silent writing. Everyone lists their reasons alone, before anyone speaks.
- Round-robin, one reason per person per turn, until the lists are empty.
- Group them on a board and pick the five that would hurt most.
- Give each of the five an owner and a tripwire before anyone leaves the room.
The silence in step two is the part people want to skip and the part that matters most, because the moment someone senior talks first, the room converges on their view. I run a lighter, twenty-minute version with the client too, usually in the second week, once there is enough trust to say "here is how we think this could go wrong".
What comes out that planning misses?
Specifics. A planning session produces risks like "timeline pressure". A pre-mortem produces sentences describing something a person actually watched happen once, named in enough detail to be plannable, including the uncomfortable ones about how the team itself behaves when the schedule gets tight.
| The planning session says | The pre-mortem says |
|---|---|
| Timeline pressure | We said yes to the extra reporting module in week two and it ate the buffer |
| Integration risk | The courier API's documentation was wrong and we found out in UAT |
| Access dependencies | The client's IT team never gave us production access and we built the migration blind |
| Adoption risk | The model was accurate but the agents on the floor kept using the old form |
On one pre-mortem the most-voted failure reason was that first row, close to word for word. Everyone in the room had watched it happen on a previous project. Nobody had said it in the planning meeting.
Do AI projects need their own failure list?
Yes. AI projects fail in ways a room that has mostly shipped conventional software will not name unprompted: data that was never approved for use, an evaluation set nobody built, a working feature nobody owned once the build team left, and users who were never asked whether they wanted it.
So before an AI build I seed the exercise with that list, and I send round the frank teardown of what broke when someone tried to run a company on AI-agent departments a few days beforehand, because it is a catalogue of failures that look nothing like a missed deadline. People read it and arrive with their own version.
How does a list become protection?
Through tripwires. A risk with an owner is a hope. A risk with a tripwire is a plan, because a tripwire names an observable signal and a date: "if we do not have production-like data by day fifteen, Sonal escalates to the sponsor that week." Never "we will monitor it".
A specific thing, on a specific day, done by a named person. The tripwires go into the risk section of the weekly status report, so the client sees them and sees them being watched. Half the time the tripwire never fires and the risk quietly retires. The other half, we act in week three instead of week nine.
The exercise has also become the first thing I bring to a new software consulting engagement, ahead of the plan, because the plan reads better once the room has said out loud what could sink it.
At Shanti Infosoft the pre-mortem sits between the estimate and the kickoff on every project plan, and I treat skipping it the way I would treat skipping the estimate. Both are ways of choosing to be surprised later.
If your current project failed six months from now, what is the reason your team already knows and has not said out loud?
Sonal Jain heads project delivery at Shanti Infosoft, a CMMI Level 5 firm whose 80+ engineers ship client software week in, week out.
Top comments (0)