When a project fails, the instinct is to move on quickly and not dwell. That instinct wastes the single most valuable thing a failure produces: information. A well-run post-mortem, a structured look at what happened and why, turns a painful experience into shared knowledge. Run badly, it becomes a trial. The difference is almost entirely in how the leader sets it up.
Start with the purpose
Before anyone speaks, state what the meeting is for. The purpose is to understand what happened so that the next project goes better. It is not to decide who was at fault. Say this out loud, and mean it. People can tell within minutes whether a post-mortem is really a hunt for someone to blame, and if it is, they will protect themselves rather than tell the truth.
It helps to remind the room that the people who were closest to the failure usually understand it best, and that their honesty is the point of the exercise.
Build the timeline before the judgments
Begin by reconstructing what actually happened, in order, as factually as possible. When did the project start? What were the key decisions and when were they made? When did the first signs of trouble appear? What was done about them? Keep interpretations out of this part. The goal is a shared, accurate picture of events, because people often discover that they had different understandings of the same sequence.
Ask why, several times
Once the timeline is clear, look for causes. A useful habit is to keep asking why until you reach something structural. The deadline was missed. Why? A key dependency arrived late. Why? Nobody owned that relationship. Why? The project plan did not assign one. Stopping at the first answer usually lands on a person. Continuing usually lands on a process, and processes can be fixed without anyone being humiliated.
Most failures have several causes, and some of them were outside anyone’s control. Name those too. Pretending the team could have controlled everything is as dishonest as pretending they could have controlled nothing.
Separate accountability from blame
A blameless post-mortem does not mean nobody is accountable. People who made decisions should be able to explain them, and the team should be able to say honestly where judgment fell short. The distinction is in tone and purpose. Blame asks who ruined this. Accountability asks what each of us would do differently, and the leader goes first. When the person running the meeting names their own mistakes before anyone else’s, the whole room relaxes and gets honest.
End with specific changes
A post-mortem that produces only insight has done half its job. Close by agreeing on a short list of concrete changes: a new checkpoint, a clearer owner for a risk, a different way of estimating. Assign each one to a person and a date. Then, crucially, follow up. Teams learn to trust post-mortems when they see the changes actually happen, and they learn to dismiss them when the notes vanish into a folder.
Finally, acknowledge what went right. Even failed projects contain good work, and people who did it need to hear that it was seen. A team that has been through a failure and an honest reckoning together tends to come out stronger than one that never failed at all, because they now know they can survive it. That knowledge is the real product of the meeting, and it is worth far more than the project that was lost.
New messages, real moments from the road, and the All Is Well Project. Follow along and say hello.
The lessons behind everything Chris teaches. Start with three chapters, free.
Turn the lessons into your comeback.
Talk it through free with the Team Dorrity coach, or work with Chris one-on-one in The Better Than Back Experience.
