How to Do a Post-Mortem on Agency Projects (Template Included)
Projects end. Then what? Most agencies move to the next project and never look back.
That's a missed opportunity. Every project teaches something. What went well?
What went poorly? What would you do differently?
Post-mortems capture that learning. They're how you improve over time.
This post covers how to run post-mortems that your team will actually use.
Why Post-Mortems Matter
Post-mortems prevent repeating mistakes. They celebrate wins so you can repeat them. They build institutional knowledge.
Over time, each project makes you better. Without post-mortems, you're starting from scratch on each project.
The Post-Mortem Challenge
Most post-mortems fail because they're too heavy.
30 minutes of questions. Lengthy write-ups. Another meeting nobody wants to attend.
People skip them. They're not honest. They don't lead to change.
The solution is a lightweight post-mortem that takes 45 minutes and produces useful insights.
The Lightweight Post-Mortem Template
Timing: Within one week of project completion.
Attendees: PM, lead designer, lead developer, any other key contributors.
Duration: 45 minutes total.
Format:
Part 1 - The Setup (5 minutes)
PM recaps the project:
- What were we building?
- What was the budget/timeline?
- What was the outcome?
This sets context so everyone's on the same page.
Part 2 - The Good Stuff (10 minutes)
"What went well on this project?"
Go around the table. Everyone contributes. No debate. Just capturing wins.
Examples:
- "We finished design on time"
- "Client gave clear feedback"
- "Dev found an efficient solution"
- "Team stayed motivated"
Write down everything. Don't filter.
Part 3 - The Challenges (15 minutes)
"What was hard on this project? Where did we struggle?"
Again, go around. Capture everything.
Examples:
- "Testing took longer than expected"
- "Scope crept mid-project"
- "Client communication was unclear for a week"
- "We underestimated the complexity of feature X"
Part 4 - The One Thing (10 minutes)
"If we could change one thing about this project, what would it be?"
Everyone picks one thing. Then you discuss the #1 problem.
This forces prioritization. You're not fixing 10 things - you're fixing one.
Part 5 - The Action (5 minutes)
"What's one thing we'll do differently next time?"
This becomes the actionable output.
Example: "We underestimated testing. Next project, we'll add 25% more time for QA in the estimate."
Write it down. Assign to someone to remember it.
The Post-Mortem Template
Here's a template you can use:
Project Post-Mortem
Project: [Name] Date Completed: [Date] Team: [Names] Post-Mortem Date: [Date]
Project Summary:
- Scope: [Brief description]
- Budget: $[Amount]
- Timeline: [X weeks]
- Result: [Success/Partial Success/Challenging]
What Went Well:
- [Item]
- [Item]
- [Item]
- [Item]
What Was Challenging:
- [Item]
- [Item]
- [Item]
The One Thing We'd Change: [Description of the biggest improvement opportunity]
Action for Next Time: [Specific change we'll make in future projects]
Owner of Change: [Name]
Running the Meeting
Facilitate, don't defend. Your job is capturing input, not defending decisions.
Keep it positive. Even failed projects have wins. Find them.
No blame. "We made a mistake" not "You made a mistake." It's a team sport.
Be specific. "Communication was unclear" is less useful than "We didn't have weekly client check-ins in weeks 2-4, so they didn't know progress was on track."
Capture everything. Don't filter in the moment. You can synthesize later.
Using the Insights
After the meeting:
Document the post-mortem. Share the template with the team.
Extract the learning. Pull out the "one thing we'll change" and add it to your project playbook.
Update processes. If testing always takes longer, update your estimate process.
Share the wins. Celebrate what went well. Share the post-mortem with the wider team so everyone learns.
Follow up. In three months, did we actually implement the change? Did it help?
Frequently Asked Questions
What if people aren't honest in post-mortems? They won't be initially. Trust builds over time. Start with safe projects. Normalize honesty. Soon people will be direct.
Should clients attend post-mortems? No. This is for your team to be honest about process and challenges. Clients don't need to see the sausage-making.
What if we had a failed project? Post-mortems are even more important. A failed project has lots to learn from.
How often should we do post-mortems? Every project. Even small projects teach something.
What if nothing went wrong? Then celebrate that. Document what made it successful. Repeat next time.
Can remote teams do post-mortems? Yes. Video call, same format. Maybe record it so people who couldn't attend can catch up.
Should post-mortems be public? The template and learnings, yes. Share with the team. The process of running it (raw input) can be private.
What if people disagree on what went wrong? That's healthy. Capture both perspectives. You don't need consensus - you need understanding.
Long-Term Improvements
Over time, post-mortems reveal patterns.
"Testing always takes longer than we estimate." "Scope creeps on projects without clear approval gates." "Designers and devs don't always align on complexity."
These patterns become actionable insights. You fix the root cause.
After six months of post-mortems, you're 20% faster and better at estimation. After a year, you're 50% more efficient.
That's the power of systematic learning.
Frequently Asked Questions
Should we skip post-mortems for small projects? No. Small projects often teach just as much as large ones.
What if people are busy and skip the meeting? Make it mandatory. 45 minutes. Important. Your schedule reflects your priorities.
Can we combine post-mortems with project billing reviews? Sort of. They're different conversations. Post-mortem is learning. Billing is finance. Keep them separate.
What if we discover a big problem during post-mortem? Good. Now you know. Fix it before the next project. That's the point.
Post-mortems are how you turn projects into learning. Run them regularly.
Stay focused. And watch your team get better at delivery.