Delivery misses happen. A scope that grew without corresponding timeline adjustment. A requirement that was agreed upon but not understood the same way by both parties. An integration that worked in the test environment and failed in production for a reason nobody had considered. A dependency that was tracked and still delivered late because nobody had the standing to escalate the delay when it first became visible.
The miss itself is rarely the most expensive part. The most expensive part is not learning from it. A team that delivers a project late and doesn't understand why delivers the next project late for the same reason, slightly rephrased. The post-mortem is the instrument for interrupting that pattern.
What a post-mortem is not
A post-mortem is not a performance review dressed in retrospective language. The moment participants believe that the session's output might affect their evaluation, they stop sharing the information that's most useful to surface. The objective is not to assign accountability for what went wrong: accountability for specific decisions already exists elsewhere in the organization. The objective is to understand why the delivery differed from the plan, so that the process can be improved.
It's also not a venting session. Expressing frustration about the project has legitimate value and belongs in its own space. The post-mortem is structured time with a specific output, and letting it become unstructured prevents that output from emerging. The facilitator's most important job is keeping those two things separate.
And it's not a formality. A post-mortem that produces a document nobody reads, with findings nobody acts on, that gets filed next to the last project's post-mortem with identical findings, is not a learning culture. It's a documentation habit wearing the clothes of one. The check for whether a post-mortem is real is simple: name one thing the next project will do differently as a result of this one, and name the person responsible for making that happen.
The timeline reconstruction
The first step in any post-mortem I facilitate is building a shared, evidenced timeline of what happened. Not what was planned. What happened, in order, with dates and references.
This matters because the project's history is distributed across the team. The project manager knows the schedule story. The developer knows the technical story. The BA knows the requirements story. The client knows the delivery story. Each of those stories is real and partial. The reconstruction assembles them into a single sequence, and it almost always produces surprises: a decision made in week three that nobody remembered affected the delivery in week eleven. A risk that was logged but never escalated became the critical path failure. A change request that seemed minor in isolation was the fourth scope addition in three weeks and the one that pushed the timeline over.
The timeline is built from artifacts, not from memory. Meeting notes, change logs, email threads, risk registers, the project plan itself. Memory fills the gaps between artifacts and is labeled as interpretation, not fact. The discipline of keeping the reconstruction evidence-based is what makes the analysis possible: a finding based on evidence can be examined and challenged; a finding based on collective memory can only be believed or doubted.
The five whys applied to process failures
Once the timeline exists, the analysis applies a structured root-cause approach to the gaps: places where the plan and the reality diverged. The five whys is a simple recursion: ask why the gap occurred, then ask why the answer to that question occurred, until you reach a cause that, if addressed, would have prevented the gap.
The important constraint is that the five whys is applied to process failures, not to people. "Why was the delivery late?" leads to "the integration test environment wasn't ready." "Why wasn't it ready?" leads to "it was provisioned in the last week before testing began." "Why was it provisioned so late?" leads to "the environment request process requires a two-week lead time that wasn't built into the project schedule." "Why wasn't the lead time in the project schedule?" leads to "the team didn't know about the lead time requirement."
That chain ends at a process failure (missing information in the planning phase) rather than a people failure (someone didn't plan well). The process failure is actionable: add environment provisioning lead time to the project checklist. The people failure is not actionable in the post-mortem context, and pursuing it sends the session in a direction that produces defensiveness rather than learning.
The one-page format I use
Post-mortem documents that run to fifteen pages get read once, by the person who wrote them, to check the formatting. The format I use fits on one page and has five sections. Brevity is enforced: if a finding doesn't make the cut in a sentence or two, it's either not clear enough to be actionable or not important enough to be here.
What we expected. The scope, timeline, and quality targets as stated at project kickoff. One paragraph.
What we delivered. The actual scope, timeline, and quality outcome. The gap between this and the previous section is the subject of the rest of the document.
Root causes. Three to five findings from the five-whys analysis, each stated as a process or system condition, not a person or decision. Each finding identifies the point in the project timeline where it first became visible and whether it was identified at the time.
Contributing factors. Conditions that made the root causes more likely or more damaging, without being the primary cause. An unrealistic initial schedule is a root cause if the team knowingly committed to it; it's a contributing factor if it was inherited from a fixed external deadline and the team then made decisions that assumed it was achievable.
Commitments. Three to five specific changes to process, tooling, checklist, or governance that the team or organization will implement before the next project, each with an owner and a target date. Not recommendations. Commitments, with names attached.
The two failure modes
Post-mortems fail in two distinct ways, and both are common enough to be worth watching for.
The first is stopping at symptoms. "The delivery was late because the integration was delayed" is a symptom, not a root cause. "The delivery was late because integration dependencies are not tracked in the project plan until they become critical path issues, by which time they're too late to mitigate" is a root cause, and it implies a specific change to the project planning process. Post-mortems that stop at symptoms produce commitments to "communicate better" and "identify risks earlier," which don't change anything because they don't specify what communication or risk identification will look like differently next time.
The second failure mode is not acting on the findings. The commitments are written, the document is filed, and the next project begins without any change to the planning checklist, the risk escalation process, or whatever the post-mortem identified. This is partly a discipline failure and partly a structural one: commitments in a document nobody is accountable for enforcing don't get enforced. The check is whether the commitments show up in the onboarding materials for the next project, or in the kickoff agenda, or in someone's objectives for the quarter. If they don't appear anywhere, they don't exist.
Making it safe
The facilitator's job is to create the conditions under which people will say what they actually think about what happened, rather than what they think it's safe to say. That requires a few structural choices before the session begins.
Executives and senior stakeholders either participate on equal terms with the team or are not present. A hierarchy in the room produces the wrong conversation: people describe what happened from the perspective of what sounds defensible rather than what's accurate. The person best positioned to explain a decision is often the person who made it, and they make better decisions in retrospect when they don't believe the analysis will be used against them.
The facilitator is not a participant in the timeline being analyzed. Someone who has a stake in the findings has a conflict in the facilitation. This is often difficult in small teams where the project manager would naturally facilitate: the answer is to rotate the role, use an external facilitator for the most sensitive retrospectives, or have someone from a different team facilitate in exchange for the same service on their next project.
A project team that runs honest post-mortems and acts on the findings gets better at delivery. Not dramatically, in one cycle, but measurably, over the course of a year: the same failure mode appears once, not three times. The cost of the post-mortem is two hours and a document. The value is the compound interest on not repeating the same lesson.