# What is a project post-mortem? A checklist for running one > A post-mortem is a short, blameless review of what went well, what did not, and what to change. Here is a checklist. By Austin DeBerry, Founder, Coastline CRM --- A post-mortem is a short, blameless review you run after a project to capture what went well, what did not, and what you would change next time. That is the entire definition. It is not a performance review, it is not a search for someone to blame, and it is not a status meeting. It is a deliberate hour where the team looks back honestly so the next project goes better. Done right, it turns a finished project into something the whole team actually learns from. Done wrong, it turns into a blame session everyone dreads and nobody tells the truth in. ## Why "blameless" is the whole game The word blameless does a lot of work here, and it is the part people skip. The moment a post-mortem feels like it is hunting for a culprit, everyone clams up and starts protecting themselves. You stop hearing what actually happened and start hearing the defensible version. And the defensible version is useless, because it hides exactly the information you ran the meeting to find. So you set the tone explicitly, out loud, at the start: we are here to understand the system that produced this outcome, not to grade individuals. When something went wrong, the question is "what made that the easy or obvious thing to do," not "who did it." Most failures are process failures wearing a person's name. The same root causes that sink projects in the first place tend to be structural, and you will recognize a lot of them from the [usual reasons projects fail](/blog/why-do-projects-fail): unclear scope, optimistic estimates, fuzzy ownership. Those are fixable. "Dave messed up" is not, because Dave will be on the next project too. ## When to run one Run a post-mortem after any project worth learning from, while the details are still fresh. Within a week of finishing is ideal; wait a month and people only remember the ending. You do not need a disaster to justify one. Some of the most useful post-mortems happen after projects that went well, because "why did this go right" is just as instructive as "why did this go wrong," and a lot harder to answer than people assume. ## A checklist for running one Keep it to an hour. Here is the structure I use: - **Before the meeting:** ask everyone to jot down, on their own, what went well and what did not. Independent notes first means you hear honest opinions instead of whatever the loudest person says. - **Set the frame (2 minutes):** state plainly that this is blameless and that the goal is changes, not blame. - **Recap the project (5 minutes):** the original goal, the timeline, what actually shipped. A one-page [project charter](/blog/what-is-a-project-charter) from kickoff is the perfect baseline to measure against. - **What went well (15 minutes):** go around the room. Name the things worth repeating, not just polite filler. - **What did not go well (15 minutes):** same format. Push past symptoms to causes. "We were late" is a symptom; "we never re-estimated after scope changed" is a cause. - **What we change (15 minutes):** turn the findings into concrete actions. Each one gets an owner and a due date or it does not count. - **Write it down (3 minutes):** capture the decisions somewhere the next project will actually find them. The trap is the last two steps. A post-mortem that produces a warm conversation and zero changes is theater. The output is a short list of specific changes with names attached, not a feeling that you talked it through. ## Make the lessons survive Findings that live in one person's notebook die there. Store post-mortem outcomes somewhere your team consults at the start of the next project, the same place you keep your planning templates and your [estimation approach](/blog/how-to-estimate-project-timelines). The point of looking back is to change what you do going forward, and that only happens if the lessons are in front of you when you plan the next thing. Otherwise you will rediscover the same mistake every quarter and call it bad luck. A few habits keep post-mortems healthy over time: keep them short so people do not dread them, rotate who facilitates so it does not become one person's pulpit, and actually revisit last project's action items at the start of this one. Nothing builds trust in the ritual faster than seeing a change you suggested last time get implemented. ## The takeaway A post-mortem is a short, blameless look back that captures what went well, what did not, and what to change. Run it soon after the project, protect the blameless frame so people tell the truth, push past symptoms to causes, and walk out with a handful of owned, dated changes. Skip the blame and keep the lessons, and every project quietly makes the next one better.