Run a post-mortem within one to two weeks of a project ending, while memory is fresh and before people are absorbed in the next thing. Send a short questionnaire beforehand so the meeting starts with data rather than a blank room, allow 60 to 90 minutes, and keep it blameless - the session looks for systemic causes, not individual fault. The most common failure is not a bad meeting; it is a good meeting that produces a list of insights nobody converts into a changed process, so every retrospective surfaces the same three problems for two years running.
Most agencies do not run post-mortems. The ones that do frequently run them badly, and the failure has a specific shape.
The meeting itself goes well. People are candid, the discussion is useful, someone takes notes. And then nothing changes, because the output was a list of observations rather than a change to how the next project runs. Six months later the same three problems surface in the next retrospective, and the team quietly concludes these meetings are performative.
That conclusion is fair, and it is fixable. The fix is almost entirely in what happens in the last fifteen minutes and the week afterwards.
This guide covers when to run one, how to prepare, the agenda, keeping it blameless, and - the part that actually matters - converting findings into changed practice.
Why they get skipped
Three reasons, all understandable. The project is finished, so there is no deadline. The team has moved on to the next thing. And if the project went badly, nobody is enthusiastic about revisiting it.
The result is that the most expensive lessons an agency generates are the ones it consistently fails to collect.
When to run one
Within one to two weeks of the project ending. Asana's guide to project post-mortems and Productive's walkthrough both land on roughly this window, and the reasoning is straightforward: earlier and people are still finishing; later and the specifics have gone, leaving only general impressions.
Run one on successful projects too. Agencies run post-mortems after disasters and skip them after wins, which means the entire learning corpus is failure. You learn as much from understanding why something went unusually well, and it is much easier to have the conversation when nobody is defensive.
Run one on long retainers annually, not only at the end. A retainer that runs for three years and is never reviewed accumulates habits nobody chose.
What a retrospective is not
It is not a performance review. Conflating them means people stop telling the truth in both.
It is not blame allocation. The question is what in the process allowed this, not who did it.
It is not a status update. The project is finished; nothing needs reporting.
It is not optional when things went well. Agencies run post-mortems after disasters and skip them after wins, which means their entire learning corpus is failure. Understanding why something went unusually well is both more useful and considerably easier to discuss, because nobody is defensive.
It is not a document. A retrospective that produces a written summary and no change to how the next project runs has cost ninety minutes and bought nothing.
Prepare, or the meeting starts cold
The single biggest improvement to a post-mortem happens before it.
Send a short questionnaire two or three days ahead. Four or five questions, ten minutes to complete:
- What went better than expected?
- What went worse?
- What surprised you?
- What would you do differently on a similar project?
- What is one thing we should change as a team?
Two benefits. People arrive having thought, which raises the quality of the discussion enormously. And if several people independently raise the same issue, you know before the meeting what the real topic is - that becomes the agenda item you protect time for.
Pull the numbers. Planned hours against actual. Budget against spend. The delivery date against the original. Scope changes raised and absorbed. Project margin, calculated properly as covered in agency profit margins.
Data changes the conversation. "It felt like we did a lot of extra work" is a position. "We logged 340 hours against an estimate of 240, and eleven out-of-scope requests were absorbed" is a fact everyone can reason from.
Who should be there
Everyone who did substantial work on the project, including contractors. Not stakeholders who want visibility - their presence changes what people are willing to say, which is the entire input the meeting depends on.
Keep it under eight. Beyond that it becomes a presentation, and presentations do not surface anything anyone was reluctant to say.
The agenda
Sixty to ninety minutes. Name a facilitator and a scribe up front - the facilitator keeps time and protects the tone, the scribe captures decisions rather than transcribing discussion.
1. The numbers (10 min)
Present without commentary. Estimated versus actual, budget, dates, scope changes, margin.
Let people see the shape of the project before anyone characterises it. Frequently the numbers contradict the mood - a project everyone remembers as painful was on budget, or one everyone remembers fondly lost money.
2. What went well (15 min)
Genuinely first, and genuinely fifteen minutes.
Teams rush this to get to the problems, which is a mistake for two reasons. It is where you find practices worth codifying - something that worked is a candidate for becoming standard. And starting with what went well sets a tone that makes the harder section possible.
Push for specifics. "Good communication" is not actionable. "Sending the Wednesday update even in quiet weeks meant the client never chased us" is something you can make standard practice.
3. What went badly (25 min)
The bulk of the time.
Use the questionnaire themes as the starting structure rather than opening the floor, which tends to surface whatever is most recent rather than most important.
For each issue, push past the symptom to the mechanism. "The client kept changing their mind" is a symptom. "We never named a single approver, so we were reconciling feedback from four people" is a mechanism - and mechanisms can be fixed.
A useful discipline: for each problem, ask "what would have had to be different for this not to happen?" That reliably moves the discussion from characterising people to changing systems.
4. What we change (20 min)
The section everything else exists to produce, and the one most often compressed into the last four minutes.
For each significant issue, decide one of three things:
- A specific process change, with an owner and a date.
- A documented note - something to watch for, added to a checklist.
- Nothing. Some problems are one-offs and not worth systematising against. Saying so explicitly is a legitimate outcome and it stops the change list becoming unusable.
The rule that makes this work: no more than three process changes per retrospective. A retrospective producing eleven actions produces zero, because nobody can absorb eleven. Three, owned and dated, actually happen.
Timebox it properly
Ninety minutes, hard stop, with the last twenty reserved for deciding what changes. Retrospectives that run long almost always do so by borrowing from that final section, which is the only part that produces anything.
Keeping it blameless
The tone determines whether you get truth or performance, and it does not maintain itself.
State the frame at the start, every time, even with a team that knows: we are looking for what in our process allowed this, not who did it.
Model it early. The most senior person in the room should be the first to name something they got wrong. This costs very little and it is the single most effective thing available - a team will not be candid before their manager is.
Redirect person-directed comments to the system. "Designs went out late three times" invites "why did the client keep changing their mind." Redirect: "what in our process meant we were absorbing changes that late?"
Separate performance conversations entirely. If someone genuinely underperformed, that is a management conversation on a different day. Conflating the two makes every future retrospective a performance review, and people stop telling the truth in performance reviews.
The NOBL guide to retrospectives and post-mortems and Planio's post-mortem guide both emphasise the same point: a retrospective is only useful if the tone holds, and the tone is the facilitator's responsibility rather than an ambient property of the team.
The rule that makes it stick
Three changes maximum, each with an owner and a date, reviewed at the start of the next retrospective.
A session producing eleven actions produces zero, because nobody absorbs eleven. Three, owned and revisited, actually happen - and the revisiting is what stops the meeting becoming theatre, because it makes non-delivery visible.
Converting findings into changed practice
This is where post-mortems succeed or become theatre. Five things.
Write the change, not the insight. "We should communicate scope changes earlier" is an insight. "Any out-of-scope request over two hours gets a written estimate before work starts, raised by the delivery lead" is a change. Only the second alters anything.
Give each change an owner and a date. Unowned actions do not happen, and this is not a comment on anyone's diligence - it is that nothing without a name attached competes with client work.
Put it where the work happens. A change that lives in a retrospective document is invisible. A change that becomes a line in the kickoff agenda, a field in the project template, or an item on the QA checklist is unavoidable. The best process changes are the ones nobody has to remember.
Review the last retrospective's actions at the start of the next one. Two minutes. This single habit is what stops the meeting becoming performative, because it makes non-delivery visible.
Keep a running log across projects. The individual retrospective tells you about one project. The log tells you that estimation on integration work has been wrong five times, which is a much more valuable finding and is invisible from any single session.
Log them across projects
A single retrospective tells you about one project. A running log across ten tells you that integration work has been under-estimated five times, which is a far more valuable finding and is invisible from any individual session.
Keep one document, add three lines after each retrospective, and read it annually. It is the cheapest institutional memory an agency can build.
The patterns that keep recurring
Across agencies the same handful of root causes account for most retrospective findings. Recognising them early saves discovering each one the slow way.
No named approver, so feedback arrived contradictory and rework followed. Fixed at kickoff.
Scope absorbed without a change order. Individually small, collectively a third of the project. Fixed with a light change process.
Estimates based on the happy path. Almost every overrun traces to work that was estimated as though nothing would need revisiting.
Client dependencies with no dates. Content, access and approvals that were assumed rather than scheduled.
The problem was visible in week two and raised in week six. The most common finding of all, and the subject of our guide to difficult client conversations.
If your retrospectives keep producing these, that is not a failure of the meeting - it is the meeting doing its job and the changes not being implemented.
Getting people to say the real thing
The hardest part of a retrospective is not the agenda. It is that people say the safe version of what they think, and the safe version is rarely useful.
Ask for written input first. The questionnaire is partly about preparation and partly about candour - people write things they would not say first in a room, and once it is written down it can be raised without anyone having to be the one who brought it up.
Surface themes anonymously. "Three people mentioned that approvals were unclear" invites discussion of the issue rather than a defence by whoever owned it.
Go first, specifically. The most senior person naming something they got wrong, with a concrete example rather than a general admission, sets the ceiling for everyone else. Vague self-criticism from leadership produces vague criticism from everyone.
Ask the negative question directly. "What did we do that made your job harder?" gets better answers than "what could be improved," because it gives permission rather than requesting diplomacy.
Do not defend anything in the meeting. Even when the criticism is unfair. Explaining why something happened, however reasonably, teaches the room that raising things produces an argument. Note it, and address it separately if it matters.
What to do between retrospectives
The meeting is a checkpoint, not the mechanism. Two habits matter more.
Capture observations as they happen. A running note per project - what went well, what went badly - added to in the moment rather than reconstructed at the end. Retrospectives held six weeks after a project rely on memory, and memory over-weights the last fortnight.
Track the actions where the work is. Three changes agreed in a retrospective should appear as tasks with owners, in the same place as everything else. Actions that live only in a retrospective document are actions that do not happen, and after two cycles of that the team correctly concludes the meeting is theatre.
Formats worth knowing
The agenda above is a general-purpose structure. Three alternative formats suit particular situations.
Start / Stop / Continue. Three columns: what to start doing, what to stop, what is working and should continue. Fast, produces action-shaped output naturally, and the "continue" column is genuinely valuable because it forces a team to name what is working rather than treating it as invisible. Good default for shorter sessions.
Timeline retrospective. Draw the project as a timeline and have everyone mark the moments that stood out, good and bad. Then discuss the clusters. Better than a general discussion for long projects, where the early phases are otherwise forgotten entirely by the time you meet.
Five whys, on one issue. Pick the single biggest problem and ask "why" repeatedly until you reach something structural. Slower, covers less ground, and goes considerably deeper. Worth using when the same issue has appeared in three consecutive retrospectives, because that pattern means the previous sessions stopped at the symptom.
Rotating the format occasionally is worth doing for its own sake. A team that has run the same three questions for two years stops thinking and starts reciting.
Running one on a retainer
Long-running engagements need retrospectives too, and they rarely get them because there is no natural end point to trigger one.
Run it annually, at minimum. A retainer that has been going for three years without review has accumulated habits nobody chose - work that crept into scope, reporting that stopped being useful, a cadence that suits nobody.
Look at drift rather than delivery. The question is not "did we do the work" but "is this still the engagement we priced." Compare the hours actually spent by category against what the retainer was scoped for. The gap is usually substantial and usually invisible.
Include the commercial review. Effective hourly rate, overage absorbed, whether the allocation still matches reality. Our guide to retainer models covers the numbers worth checking.
Ask whether the client would buy it again today. Uncomfortable and clarifying. If the honest answer from your side is no, that is worth knowing before they reach the same conclusion.
When the project failed badly
A genuinely bad outcome - a client lost, a serious overrun, a public mistake - needs handling differently.
Wait slightly longer. Two to three weeks rather than one. Emotions are higher and the discussion is worse when people are still upset.
Separate the commercial review from the learning review. What it cost and what happens with the client is a management conversation. What we learned is a team conversation. Combining them means nobody says anything useful in either.
Have leadership go first and be specific. The tone requirement described above is doubled here. If the team believes the meeting is looking for someone to blame, you will get a carefully rehearsed account and no information.
Expect the root cause to be upstream. Serious failures rarely originate in delivery. They usually trace to something that was accepted at sale - an unrealistic date, an unclear scope, a client who was wrong for you - which means the useful output is frequently a change to qualification rather than to execution.
A note on client-facing retrospectives
Consider running a short version with the client, separately from the internal one.
Different agenda, and it is not the internal session with the criticism removed. Ask what worked for them, what was frustrating, what they would want done differently. Offer your own observations gently - late approvals, unclear decision-making - framed as helping their next project rather than defending your last one.
Two benefits. Clients are rarely asked, and being asked is itself valuable to the relationship. And it surfaces things your internal session cannot see, because your team only observed half the project.
Run it at the wrap-up session covered in our guide to client offboarding, where it fits naturally alongside the handover.
Review last time's actions first
Two minutes at the start of every retrospective: what did we agree last time, and did it happen? This single habit is what stops the meeting becoming theatre, because it makes non-delivery visible to everyone in the room.
The minimum viable version
If ninety minutes is unrealistic, a thirty-minute version still beats nothing:
- Five minutes on the numbers - estimated versus actual.
- Ten minutes on what worked.
- Ten minutes on the single biggest problem, pushed to its mechanism.
- Five minutes to agree one change, with an owner and a date.
One change, implemented, per project. Over a year that is eight or ten real improvements to how you work, which is considerably more than most agencies achieve from a heavier process they abandon by March.