How to Run Effective Project Post-Mortems at Your Agency

Why post-mortems matter more than you think

Most agencies finish a project, send the final invoice, and move on to the next one. The lessons from that engagement, what worked, what didn't, what nearly derailed the whole thing, evaporate within a week. The same mistakes get repeated on the next project. Same surprises. Same scramble.

This is the knowledge loss problem, and it's one of the most expensive inefficiencies at growing agencies. Every project contains data about your processes, your estimates, your client management, and your team's capabilities. Post-mortems are how you extract that data before it disappears.

We started running them consistently about two years ago and the difference was obvious within two quarters. Estimates got more accurate. Timelines slipped less. Client satisfaction scores went up. Team morale improved because people felt heard and saw their feedback being acted on.

The compounding effect is real. Each post-mortem makes the next project slightly better. Over a year, those incremental improvements add up to a fundamentally more capable agency.

When to run a post-mortem

Timing matters. Run it too early and the project isn't finished. Run it too late and people have forgotten the details.

The sweet spot is one to two weeks after project completion. Close enough that memories are fresh, but with enough distance that emotions have cooled. Nobody gives objective feedback the day after a stressful launch.

Not every project needs a full post-mortem. For small, routine engagements, a quick five-minute team retro is enough. Save the full session for:

• Large or high-budget projects. Any engagement over a certain budget threshold. Set this based on your agency's size, it might be $20,000 or $100,000.
• Projects that went a lot over budget or timeline. Understanding why is key to stopping a repeat.
• Projects with real client friction. If the relationship was strained, understanding the root causes protects future engagements.
• Projects that went exceptionally well. This one gets overlooked. Understanding what made a project successful is just as valuable as understanding what went wrong.
• New types of engagements. The first time you deliver a new service offering, run a post-mortem to refine the process for next time.

Who should attend

The post-mortem should include everyone who had meaningful involvement in the project. Usually that means:

• Project manager. They have the most complete view from start to finish.
• Key team members. The lead designer, lead developer, and any other significant contributors. Don't invite every junior developer who touched the codebase. Include the people who can speak to decisions and process.
• Account manager or sales lead. They can speak to how the project was sold, whether expectations were set correctly, and client feedback they've received.
• Agency leadership (optional). For major projects, having a principal or director in the room signals that the agency takes learning seriously. But their presence should be as a listener, not a judge.

Keep the group to six to eight people max. Larger groups become unwieldy and people hold back. If you need input from more people, gather it asynchronously before the meeting and share it during the session.

One important rule: the client isn't invited. The post-mortem is an internal process where your team needs to speak candidly. If you want client feedback, gather it separately through a survey or a dedicated client retro conversation. (We actually send a short Typeform survey to every client at project close. Takes them three minutes and the data is gold.)

Building a no-blame culture

This is the single most important factor in whether your post-mortems produce useful findings or devolve into finger-pointing. I can't stress this enough.

Post-mortems are about processes and systems, not about individual failures. When a deadline was missed, the question isn't "who dropped the ball?" It's "what about our process allowed this to happen?"

Set this expectation explicitly at the start of every post-mortem. A simple statement from the facilitator works: "The purpose of this meeting is to improve our systems. We're looking at what happened and why, not who's at fault. Assume everyone was doing their best with the information and resources they had."

Practical ways to reinforce this:

• Focus on systems. Instead of "Sarah missed the deadline," say "the QA phase ran over because we didn't allocate enough time for cross-browser testing."
• Use neutral language. "The timeline slipped" rather than "the developers were slow."
• Celebrate honesty. When someone admits a mistake, thank them for the openness. This encourages others to be candid.
• The facilitator should redirect blame. If someone starts pointing fingers, gently steer the conversation back to process. "Let's focus on what we can change systemically so this doesn't happen again regardless of who's on the project."

If your team doesn't trust that post-mortems are blame-free, they'll give surface-level input and the exercise becomes a waste of time. Building this trust takes consistency. Run several post-mortems where the follow-up actions are clearly about process improvements, not personnel consequences, and the culture will shift.

A step-by-step framework for running the session

Block 60 to 90 minutes. Have a dedicated facilitator, ideally someone who wasn't deeply involved in the project so they can remain neutral. The PM can facilitate if no one else is available, but they should be aware of their bias.

Step 1: Set the stage (5 minutes). The facilitator outlines the purpose, the no-blame ground rules, and the structure of the session. Give a brief project overview: what was the engagement, who was the client, what was the timeline and budget.

Step 2: Review the facts (10 minutes). Walk through the project timeline with objective data. What was the original timeline vs. actual? What was the budget vs. actual hours? Were there any change requests? What were the key milestones and when were they actually hit? Present this data without interpretation. Just the facts.

Step 3: What went well (15-20 minutes). Start with positives. What aspects of the project worked smoothly? Where did the team excel? What tools or routines helped? What would you repeat on future projects?

This isn't just a morale exercise. Identifying what works well is important because those are the practices you want to standardize and replicate. If the design phase went smoothly because the designer created a detailed brief before starting, that's a process worth baking into your templates.

Step 4: What didn't go well (20-25 minutes). This is where the real learning happens. What caused delays? Where did communication break down? What was harder than expected? Where did estimates miss the mark?

Encourage specifics over generalities. "Communication was bad" isn't actionable. "We didn't have a defined process for collecting client feedback, so it came in piecemeal over two weeks and contradicted itself" is actionable.

For each issue raised, dig into the root cause. Use the "five whys" technique: keep asking why until you get to a systemic cause rather than a surface symptom. Actually, scratch that, you don't always need all five. Sometimes two whys is enough. The point is to go deeper than the obvious answer.

Step 5: What should we change (15-20 minutes). Based on the discussion, identify specific, actionable changes. Each change should have an owner and a timeline. "Improve communication" isn't an action item. "Create a standard client feedback form and implement it on all new projects starting next month, owned by [name]" is an action item.

Limit yourself to three to five changes. If you try to change everything at once, nothing changes. Pick the highest-impact items and commit to them.

Step 6: Wrap up (5 minutes). Summarize the key takeaways and action items. Confirm owners and timelines. Thank everyone for their candor.

Documenting and acting on findings

The post-mortem is only valuable if the findings are documented and the action items are completed. We've seen too many agencies run great sessions and then let the notes collect dust in a Google Doc somewhere.

Within 48 hours of the session, the facilitator should distribute a written summary covering:

• Project name, date, participants
• Key facts (timeline, budget, client satisfaction)
• What went well (top three to five items)
• What didn't go well (top three to five items with root causes)
• Action items with owners and deadlines

Store these documents somewhere accessible, a shared drive, your project management tool, a wiki. Over time, this becomes a searchable knowledge base. When you're about to start a project similar to one you've done before, reviewing past post-mortems is incredibly valuable preparation.

Action items should be tracked like any other task. Add them to your project management tool with due dates and owners. Review progress in team meetings. If action items from post-mortems consistently go unfinished, people will stop taking the process seriously. We track ours in Nymble alongside regular project tasks so nothing falls through the cracks.

Feed learnings back into your operational systems. If a post-mortem reveals that your website project timeline always underestimates QA, update your website project template to allocate more time. If client feedback consistently takes longer than expected, adjust your standard timeline assumptions. If a particular type of dependency keeps causing delays, add it to your project kickoff checklist as a risk to manage proactively.

A simple post-mortem template

To make it easy to start, here's a template your team can use right away:

Project: [Name] Client: [Name] Dates: [Start] to [End] Budget: [Planned] vs [Actual] Timeline: [Planned] vs [Actual] Team: [Names and roles]

What went well:

1. [Item]
2. [Item]
3. [Item]

What didn't go well:

1. [Issue] -- Root cause: [Why] -- Impact: [What it cost in time/money/satisfaction]
2. [Issue] -- Root cause: [Why] -- Impact: [What it cost]
3. [Issue] -- Root cause: [Why] -- Impact: [What it cost]

Action items:

1. [Specific change] -- Owner: [Name] -- Due: [Date]
2. [Specific change] -- Owner: [Name] -- Due: [Date]
3. [Specific change] -- Owner: [Name] -- Due: [Date]

Overall project health: [Green/Yellow/Red] Would the client rehire us: [Yes/No/Uncertain] Key lesson for the agency: [One sentence summary]

Start running post-mortems on your next completed project. Takes an hour. The returns accumulate with every engagement. Agencies that learn from their work systematically outperform those that repeat the same patterns hoping for different results. That's not opinion. That's what we've seen play out across dozens of agencies over the last four years.