Project Post-Mortems for Agencies: The Debrief Habit That Makes Teams Better

A post-mortem is a meeting where the team that just finished a project talks about what went wrong, what went right, and what they’d do differently. In engineering culture, post-mortems are standard practice after incidents and outages. In agency work, they’re rare.

This is a mistake. Agency projects are how agencies learn. Every project contains information about how well you scoped, how well you communicated, where your process broke down, and what your team is good at. Running a project without a debrief is like running an experiment without reading the results.

The challenge is that post-mortems feel optional when you’re busy. There’s always a new project waiting. The information from the last one fades as you shift context. And some project endings are painful enough that everyone would rather not revisit them.

These are exactly the reasons to make post-mortems mandatory, not optional.

What a Post-Mortem Is Not

First, clear up two misconceptions.

A post-mortem is not a blame session. “The project went over budget because the client kept changing their mind” is not a useful finding. “The project went over budget because we didn’t have a formal change request process and accepted verbal scope changes” is useful. The difference: the first one puts the agency in the role of victim, the second identifies something the agency can actually fix.

A post-mortem is also not a celebration meeting. Some teams end project with “good job everyone” sessions that feel nice but produce nothing actionable. A retrospective that only surfaces what went well is half a retrospective.

The purpose is to generate specific, actionable findings that improve how you run the next project. If you leave the meeting without any changes to your process, tools, or templates, the meeting was probably too comfortable.

The Structure That Works

Keep post-mortems short. 45-60 minutes for most projects. Longer only if the project had significant problems worth a deeper investigation.

Participants: the core project team: developers, designers, and the project manager. Include the account manager if there were significant client communication issues. Do not include the client. This is an internal process review.

The agenda in four sections:

1. What did we intend?

Start by anchoring to the original scope. Pull up the statement of work or the project brief and spend 5 minutes reading the key commitments: what you promised to deliver, by when, for how much. This is the baseline you’re comparing actual against.

Teams often lose track of the original scope as projects evolve. Returning to the original document before discussing what happened grounds the conversation in specifics rather than impressions.

2. What actually happened?

Go through the project timeline. Hit the major milestones: project kick-off, first design review, development start, client reviews, launch, post-launch support. For each one: was it on time? Were there blockers? What surprised us?

Document the actual numbers:

• Planned hours vs actual hours by role
• Planned timeline vs actual timeline
• Budget spent vs budget scoped
• Number of revision rounds vs what was included in scope
• Number of client-requested changes after scope was signed

Don’t reconstruct from memory. Pull the actual data. Your project management tool, time tracking system, and email threads have the real numbers.

3. What are the root causes?

This is where the meeting earns its time. For each gap between plan and actual, ask why. Then ask why again. The first answer is rarely the root cause.

Example:

The project was two weeks late. Why? Because development took longer than estimated. Why? Because we underestimated the complexity of the third-party API integration. Why? Because we didn’t do a technical spike during scoping to validate the API’s capability.

Root cause: no technical spike in the scoping process for projects with API dependencies. That’s something you can change.

Another round:

The client requested six rounds of design revisions when our contract included two. Why did we accept them? Because the account manager was worried about the client relationship. Why? Because there was no clear process for how to handle out-of-scope revision requests.

Root cause: missing change request process. That’s something you can add.

Run this for the three to five most significant gaps. Don’t try to diagnose everything. Focus on what would have the biggest impact if fixed.

4. What changes are we making?

Each root cause should produce one specific, assignable action. Not “we should communicate better” but “we will add a technical spike task to the scoping template for projects with API integrations, assigned to a senior developer, due before the proposal is sent.”

Vague commitments don’t get implemented. Specific changes with owners and deadlines do.

A good action item has:

• What specifically will change (a template update, a new step in the process, a new document)
• Who owns implementing it
• A date by which it will be done

Capture these in writing and review them at the start of the next project. If an action item from last month’s post-mortem hasn’t been completed, someone needs to explain why before you move on.

The Documentation

The post-mortem is only useful if it’s documented and findable. A well-structured post-mortem document takes about 30 minutes to write after the meeting and becomes the institutional memory of what your team learned.

A simple template:

Project: [Name]
Date: [Post-mortem date]
Team: [Names]
Meeting duration: [X minutes]

ORIGINAL SCOPE
- Deliverables: [list]
- Timeline: [dates]
- Budget: [$amount]

ACTUALS
- Deliverables: [what shipped]
- Timeline: [actual dates]
- Budget: [$amount spent]
- Hours: [planned vs actual by role]

WHAT WENT WELL
- [specific finding]
- [specific finding]

WHAT DIDN'T GO WELL
- [specific finding]
- [specific finding]

ROOT CAUSES
1. [Issue] → [root cause analysis]
2. [Issue] → [root cause analysis]

ACTION ITEMS
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [change to template X] | [name] | [date] | pending |
| [add step Y to process] | [name] | [date] | pending |

Store these in a shared place: Notion, Confluence, a shared Google Drive folder. After a year of consistent post-mortems, you have a searchable record of everything your team learned. New hires can read three months of post-mortems and understand more about how the company works than they’d learn from any onboarding doc.

The Pattern That Appears in Agency Post-Mortems

After running this process with enough projects, patterns emerge. The same issues tend to recur:

Scoping gaps. The most common cause of over-budget projects is scope that was underestimated at the proposal stage. The fix is usually a more rigorous scoping process: more detailed requirements questions, technical spikes for uncertain areas, explicit contingency in the estimate.

Revision scope drift. Client feedback rounds expand beyond what’s contracted. The fix is a defined change request process that makes it easy for the account manager to say “this is a change to scope” without it feeling like a confrontation.

Internal communication breakdowns. Developer builds something the designer didn’t intend because they didn’t talk during the build phase. The fix is explicit check-ins between disciplines at defined milestones, not just at deliverable handoffs.

Technical assumptions made without validation. A third-party API doesn’t work the way the estimate assumed. A library doesn’t support a required feature. The fix is technical spikes during scoping for anything you haven’t built before.

Knowledge that left with the project. Three months after a project ends, nobody remembers why a specific technical decision was made. The fix is lightweight architectural decision records during the project, not after.

When you see a pattern across three or four post-mortems, you’ve found a systemic process issue. A single occurrence might be a one-off. Multiple occurrences pointing to the same root cause is evidence that your process has a consistent weak point.

Making It a Habit

The obstacle to consistent post-mortems is not complexity. It’s scheduling. Projects end, everyone disperses, the next thing starts. Two weeks later, the information has faded and nobody has scheduled the meeting.

The fix: schedule the post-mortem before the project starts. Put it on the calendar for one week after the expected go-live date. It may move if the timeline slips, but the default expectation is that it happens.

Make it a line item in the project budget. If post-mortems happen on team members’ own time, they feel like extra work. If they’re in the project hours, they’re part of how the project is run.

Hold the meeting before the project is fully invoiced. This creates a practical reason to complete it: the final invoice isn’t processed until the post-mortem is done and documented.

Agencies that run consistent post-mortems get better at estimating, better at scoping, and better at handling the situations that used to catch them off guard. The improvement isn’t dramatic project-to-project. Over a year, it’s significant. The information is there in every project you ship. The question is whether you capture it.