Project Post Mortem Template

Review any project or incident, capture lessons learned

Try this retrospective live

Project overview, goals and scope

What did the project set out to do, and by when?

The goal was to move all customer billing onto the new platform by end of Q3 with zero downtime for enterprise accounts.
We shipped the customer portal three weeks later than the original date, with two of the five planned features cut.
Success criteria were never written down anywhere I could find, so I had my own version in my head.
What went well

Which wins and processes are worth repeating?

Daily fifteen minute syncs during the crunch period kept everyone aligned without adding meeting load.
Our on-call runbook was accurate, which meant the fix took minutes rather than hours to apply.
Pairing the new developers with reviewers early got them productive faster than I expected.
What didn't go well

Where did we stall, break or miss targets?

Requirements kept shifting and nobody was clearly accountable for deciding when they were final.
Testing was squeezed into the last few days, which is why two defects reached customers.
Our monitoring did not cover the queue depth, so we were blind until things had already backed up.
Root cause analysis

Why did it go wrong, not just that it did?

The root cause was a config change deployed straight to production because our pipeline had no mandatory review step.
We under-estimated because the estimate was made before the technical spike and then treated as a commitment.
Nobody owned the integration between the two teams, so the gap was invisible until integration week.
Lessons learned

What are the key takeaways we carry forward?

Run the technical spike before we commit to any dates, then re-estimate in the open.
Write down success criteria at kickoff. If we cannot agree on them, we are not ready to start.
Scope changes need a written checkpoint rather than being quietly absorbed by the team.
Action items, owners and deadlines

Who is doing what, and by when?

Add a mandatory review step to the production deploy pipeline. Owner: Priya. Due: end of next sprint.
Draft a one page project charter template with success criteria. Owner: Sam. Due: 15th.
Add queue depth and error rate alerts routed to the on-call rotation. Owner: Dev. Due: this week.
Team appreciation and kudos

Who deserves recognition before we close out?

Thanks to Priya for staying calm on the bridge call and keeping everyone focused on the fix.
Kudos to the support crew who absorbed the customer contacts with almost no notice.
Big appreciation for Sam, who quietly wrote the runbook nobody asked for and then saved us with it.

What is a post-mortem retrospective?

A post-mortem is the conversation your team has after something ends. Sometimes that something is an incident: a system broke, a release went sideways, a customer felt the pain. Just as often it is a normal project that has simply wrapped, and you want a clear postmortem template to run the review meeting without inventing an agenda from scratch. This format handles both. You set the frame with the project's goals and scope, walk through what went well and what didn't, dig into root causes where it matters, and turn the honest bits into lessons learned your organisation can actually reuse. Here is how it works in TeamRetro. Everyone adds their own observations privately first, so the loudest voice in the room does not set the narrative before quieter people have written anything down. Ideas are then grouped, discussed and voted on, which lets you prioritise the handful of themes that genuinely matter instead of chewing through forty comments in no particular order. That is the difference between this and a static post mortem template you fill in alone: it is a live team debrief your whole group runs together, and it ends with owners and due dates attached to real actions rather than a document nobody opens again. Use it as your default project review at the close of a delivery, a campaign, a migration or a quarter, and as your incident review when something has gone wrong and you need a blameless account of the timeline and its causes. The final topic makes space for kudos, because recognising the people who carried the work is part of closing it out properly. Either way the goal is the same. You want the team to leave knowing what to repeat, what to stop, and who is doing what next. Your report is exported automatically, so the lessons learned stay searchable for the next team that walks into the same situation.

Post-mortem retrospective format

Project overview, goals and scope

What did the project set out to do, and by when?

This topic sets the frame before anyone judges anything. Ask for the original objective, the scope as agreed, the timeline and the success criteria, plus what was actually delivered against them. For an incident review, use it for the timeline facts instead: what broke, when it was detected, who was involved and how it was resolved. Keep interpretation out of this column and park opinions for the topics that follow. If people disagree on what the goals or success criteria even were, that disagreement is itself a finding worth capturing.

What went well

Which wins and processes are worth repeating?

Teams rush past this topic, especially after a difficult project or a stressful incident, so protect the time for it. You are looking for repeatable practices, not compliments, and kudos have their own topic later. When someone posts praise, ask what specifically made it work so the answer can be reused. Watch for wins that came from individual heroics and name them as risks rather than successes.

What didn't go well

Where did we stall, break or miss targets?

This is where the real value sits, so set the blameless ground rule out loud before you start: you are examining systems and decisions, not people. Encourage specifics over vague grumbles, since 'communication was bad' cannot be actioned but 'we found out about the deadline change in a hallway conversation' can. Use voting here to stop the discussion sprawling across every irritation of the last three months.

Root cause analysis

Why did it go wrong, not just that it did?

Optional for a straightforward project review, essential for an incident. Take the top voted problems from the previous topic and keep asking why until you reach a condition rather than a person: a missing guardrail, an unclear owner, a schedule pressure, an assumption nobody tested. Five Whys works well here, and so does asking what made the wrong action look reasonable at the time. Stop when you reach something you can actually change, and note contributing factors separately from the trigger.

Lessons learned

What are the key takeaways we carry forward?

This is the 'so what' that turns observations into reusable knowledge. Push each idea until it names a behaviour, a trigger or a guardrail, so it can survive contact with the next project. Distinguish between things this team can change itself and things that need to go up to a manager or another group, and be honest about the second category. Phrase takeaways so someone outside the room could read them in the exported report and understand them without you there to explain.

Action items, owners and deadlines

Who is doing what, and by when?

A post-mortem without assigned actions does not count, so leave real time for this rather than squeezing it into the last two minutes. Convert the top voted lessons into a small number of specific actions, each with a named owner and a due date recorded in TeamRetro so they surface at your next session. Two or three well owned actions beat ten aspirational ones. If an action belongs to someone outside the room, agree who will take it to them and by when.

Team appreciation and kudos

Who deserves recognition before we close out?

Close on the people, not the problems. Invite everyone to name a specific person and a specific thing they did, which is far more meaningful than general thanks and works well even after a difficult project. This matters most when the review has been hard going, because it reminds the team that examining a failure is not the same as blaming each other. Keep it quick, read a few aloud, and let the exported report carry the rest.

When to use this retrospective

  • A project, delivery, migration or campaign has just wrapped and you want a structured project review rather than an informal chat that fades away.
  • An incident, outage or failed release needs a blameless post-mortem covering the timeline, root causes and preventative actions.
  • A long running programme has finished a phase and you want lessons learned captured while the details are still fresh.
  • A cross-functional group is disbanding, and this is your last chance to run a team debrief and recognise contributors before people scatter to new work.
  • Something went unexpectedly well and you want to understand why, so the practice can be repeated rather than treated as luck.

Suggested icebreaker questions

  • In one word, how did this project or incident feel while you were in the middle of it?
  • If you could send one sentence of advice back to yourself on day one, what would it say?

Want a warm-up your team plays, not just answers out loud? Browse free icebreakers →

Ideas and tips for your retrospective meeting

  • Run it within a week or two of the project closing or the incident being resolved. Memories fade fast and the useful detail goes with them.
  • State the blameless rule at the start. You are looking at decisions, systems and pressures, not searching for someone to hold responsible.
  • Spend a few minutes agreeing the project overview before opinions start. A shared frame stops the session becoming a debate about what the goal even was.
  • Skip or shorten root cause analysis for a clean project review, and lean into it for incidents where prevention is the point.
  • Prioritise with voting, then do not let the meeting end without owners and due dates on the top actions, otherwise your lessons learned stay theoretical.
  • Bring the previous post-mortem's actions into the room and review them first. Nothing improves follow-through like knowing it will be checked.

Frequently asked questions

What is a project post-mortem?
A project post-mortem is a structured review your team runs once a piece of work is finished, whether that is a product launch, a migration, a campaign or a client delivery. You look at the original goals and scope, what went well, what didn't, and the lessons learned worth carrying forward. Unlike an incident postmortem, nothing has necessarily gone wrong. The trigger is simply that the work has ended and there is knowledge worth keeping.
How is a project post-mortem different from an incident post-mortem?
The format is similar but the focus differs. An incident post-mortem is triggered by a failure, so it leans heavily on timeline reconstruction, detection, response and root cause analysis, with prevention as the aim. A project post mortem is triggered by completion, so it covers goals, estimation, scope, collaboration, handover and delivery, with improvement on the next project as the aim. Both should be blameless and both must end in owned actions.
What should you include in a project post-mortem?
Start with the project overview: goals, scope, timeline, success criteria and what was actually delivered. Then cover what went well, what didn't go well, and root causes for the problems that matter most. Finish with lessons learned, action items with owners and deadlines, and a round of team kudos. All seven topics sit in one TeamRetro session, and voting helps you prioritise instead of leaving with forty unranked observations.
Do I have to use the root cause analysis topic?
No, it is optional. It earns its place in incident and outage reviews where understanding why something failed is the whole point, and in projects that missed significant targets. For a smooth delivery you can skip it, or simply take the two most voted problems and ask why a few times before moving on to lessons learned.
How long does a post-mortem take?
Allow sixty to ninety minutes for most projects and incidents. Contained incidents or small projects can be reviewed in forty-five minutes if you skip root cause analysis. Large programmes often need two hours or a pair of sessions, one for the factual overview and causes and one for improvements and actions. Because everyone brainstorms in parallel in TeamRetro, the collection phase stays short.
Who should attend a post-mortem?
Include the people who did the work and the people affected by it: the delivery team, the product or project lead, and representatives from support, design or operations who inherited the outcome. For an incident, include responders, on-call staff and anyone who handled customer communication. Keep the group small enough for honest conversation, and brief any senior attendees to listen rather than defend decisions.

Related templates

New Year Kickoff Retrospective

Reflect on successes and challenges from the holidays

End of Year Retrospective

Reflect on the past year's achievements, challenges, and lessons learned.

Project Kickoff Planning

Align the team on project goals and plan execution.

Fiscal Year-End Review

Evaluate financial performance and plan for the upcoming year.

Ready to run this retrospective?Try this retrospective live