On this page (10 sections)
A project post-mortem looks back at a whole project once it's over, whether it shipped on time, late or not at all. The board moves from facts to lessons: Goals vs. what we delivered, What went well, What didn't go well, Root causes and Lessons for next time. The reader who matters most is the next project team.
The five columns
| Column | What goes here | Example note |
|---|---|---|
| 🎯 Goals vs. what we delivered | Each original goal next to the result, with numbers | "Goal: launch by Aug 1. Shipped Sep 12, six weeks late." |
| ✅ What went well | Practices, decisions and help worth repeating | "The weekly demo to sales kept scope honest." |
| ⚠️ What didn't go well | Problems, delays, surprises and rework | "Legal review of the new terms took four weeks." |
| 🔍 Root causes | Why the biggest problems happened, below the symptom | "Legal wasn't at the kickoff, so we found out about the review late." |
| 📘 Lessons for next time | What another team should do differently, written for them | "Invite legal and security to every kickoff, even if they decline." |
How the board maps to a classic post-mortem. A written post-mortem usually has a project overview, goals, what went well, what didn't, root-cause analysis, lessons learned and action items. The overview becomes the retro's name, and action items live in the Action Items panel with owners. Root causes get their own column because skipping them is how most post-mortems go wrong: lessons written straight from the problem list come out as wishes, like "communicate better".
Where it comes from. No single person is credited with the project post-mortem. Software teams were writing down post-mortem processes by the 1990s, such as Bonnie Collier, Tom DeMarco and Peter Fearey's "A Defined Process for Project Postmortem Review" (IEEE Software, 1996). Norm Kerth's Project Retrospectives: A Handbook for Team Reviews (Dorset House, 2001) covered the same ground under the name agile teams adopted, and gave us the Prime Directive: everyone did the best job they could with what they knew at the time.
In Retro Rabbit
The Project Post-Mortem template in Retro Rabbit
Pick Project Post-Mortem from the format library when you create a Team Room (or later in its Settings) and the board starts with its five columns. Your team adds notes during the sprint, with or without their name shown, then votes on what to talk about.
Project Post-Mortem · Sprint #14
Example notes
Goals vs. what we delivered
- Goal: launch self-serve onboarding by Aug 1. Shipped Sep 122 votes
- Goal: 30% lift in trial-to-paid. We're at 12% after 6 weeks4 votes
What went well
- Weekly demo to sales kept scope honest5 votes
- Design and eng paired on every screen, so almost no rework there3 votes
What didn't go well
- Legal review of the new terms took four weeks3 votes
- We rebuilt the plan picker twice2 votes
Root causes
- Legal wasn't at the kickoff, so we found out about the review late1 vote
- Nobody owned the success metric after the PM left in July1 vote
Lessons for next time
- Invite legal and security to every kickoff, even if they decline4 votes
- Name a metric owner who stays until the result is measured5 votes
- Goals vs. what we delivered
- What went well
- What didn't go well
- Root causes
- Lessons for next time
14-day free trial · No credit card
When to use it (and when not to)
Use it when:
- a project of a month or more has ended: a launch, a migration, a rebuild, a client engagement
- a project was canceled or failed, and you want the reasons on record before people move on
- a project went well and you want to know why, so the next one can copy it
Pick something else when:
- it's a regular sprint. Use What Went Well or Start Stop Continue.
- the project is still running. Sailboat checks the course while you can still change it.
- one outage overshadows the project. Run an incident review first, then the post-mortem a week later.
How to run it live (60 minutes)
| Time | Step |
|---|---|
| 0–5 min | Review open action items and read the original goals |
| 5–15 min | Goals vs. what we delivered, one goal at a time |
| 15–27 min | Silent writing: what went well and what didn't |
| 27–32 min | Group, then dot vote on what didn't go well |
| 32–47 min | Root causes for the top three problems |
| 47–60 min | Lessons for next time, and who shares them |
- Carry-over. Check Previous Retro and Old / Unresolved Items in the Action Items panel. Decide whether each open item closes with the project or moves to a team that's staying on.
- Goals first, from the source. Use the goals from the kickoff doc, not from memory, and add the result next to each. A goal nobody can find is a finding in itself.
- What went well and what didn't. Set the shared timer for 12 minutes. After a failed project people skip What went well. Insist on it: that's what the team should keep.
- Root causes. For each of the top three, keep asking why until you reach something a future team could change. If one needs more time, run a 5 Whys on it later.
- Lessons, written for strangers. Each lesson should make sense to someone who wasn't there. Decide who shares them, with whom, and when.
How to run it async over a sprint
Post-mortems suit async, because people have often moved on to new work.
- Last week of the project: start the retro with Project Post-Mortem (Try a different format in Start New Retro) and post the original goals in the first column.
- The week after: everyone adds what went well and what didn't. Ask people to skim old tickets and the project channel first; memory of a long project favors the last month.
- Midway: the facilitator asks the quieter roles, like design, QA and support, for their view.
- Before the meeting: everyone votes on What didn't go well.
- Meeting day: 30 to 45 minutes on root causes and lessons. Or the facilitator drafts root causes in writing and people add notes where they disagree.
See how to run an async retrospective.
9 example prompts
Goals vs. what we delivered
- What did we promise at kickoff, in writing?
- Which goal changed along the way, and who agreed to the change?
What went well 3. Which decision would we make the same way again?
What didn't go well 4. Where did we lose the most time? 5. What did we find out too late?
Root causes 6. Which problems share a cause? 7. What did we know at kickoff that we didn't act on?
Lessons for next time 8. What would you tell a team starting a similar project next month? 9. Which lesson from an earlier post-mortem did we ignore this time?
For more, see the complete guide to sprint retrospectives.
Facilitator tip and a common pitfall
Tip: hold it within two weeks of the end. Wait a month and the team has scattered and the story has settled. If results take longer, like an adoption goal, hold it now and add the final number to the Goals column later.
Pitfall: lessons nobody reads. Most post-mortems end with good lessons the next project never sees. Make sharing an action item with an owner: someone presents the lessons at the next similar kickoff, or brings them into that team's pre-mortem. Keep root causes about decisions and conditions, not people.
How AI helps with this format
On Pro AI (and during the free trial), CarrotIQ turns a big board into something you can send:
- Summaries. The Sprint Summary covers each column and the whole project. Send the Lessons summary to the next project team.
- Group names. Drag "legal review came late" onto "security review came late" and CarrotIQ names the group, for example "Late Stakeholder Reviews".
- Suggested action items. CarrotIQ Suggest drafts an action from the most-voted notes. Edit it so it helps the next project, not just this one.
Example action items
| Note | Action item |
|---|---|
| Root cause: "Legal joined after design was done" | "Nadia adds legal and security to the kickoff checklist template this week. Check: the next kickoff invite includes both." |
| Root cause: "Nobody owned the success metric after the PM left" | "Sam adds a metric owner, who stays until the result is measured, to the project brief template." |
| Didn't go well: "We rebuilt the plan picker twice" | "Elif tests a prototype with five customers before the next pricing screen goes into a sprint." |
| Lesson: "Weekly demo to sales kept scope honest" | "Omar presents this post-mortem's lessons at the Billing v2 kickoff on Nov 12." |
| Goals: "Trial-to-paid lift is 12%, goal was 30%" | "Ji-woo adds the 90-day number to the board and books a 15-minute review if it's still below 20%." |
More in retrospective action items that actually get done.
Use this template in Retro Rabbit
- Start a 14-day free trial. No card is needed.
- For one retro, click Try a different format in Start New Retro and pick Project Post-Mortem: it applies to that retro only, and your Team Room keeps its usual columns. To make it the room's format, choose it under "Browse all formats" when you create your Team Room, or later in the Team Room's Settings.
- Before anyone else writes, post the goals from the kickoff doc as the first notes in Goals vs. what we delivered, so the post-mortem starts from what was promised.
See pricing for plans.
Related formats
- Pre-mortem: run it at the next kickoff, with these lessons in hand
- Timeline retrospective: rebuild a long project in order first
- 5 Whys: dig into one root cause
- Release retrospective: for a single release
- More formats in Project retrospectives
- All retrospective templates
Frequently asked questions
What is a project post-mortem?
A review held after a project ends, win or lose. The team compares the original goals with what was delivered, lists what went well and what didn't, digs into the root causes, and writes lessons for the next project.
What's the difference between a post-mortem and a retrospective?
They're the same idea at different scales. A sprint retrospective looks at the last two weeks and happens every sprint. A project post-mortem looks at the whole project once, at the end, and its lessons are written for other teams as much as for this one.
When should you hold a project post-mortem?
Within two weeks of the project ending, while people remember and before they scatter to new work. If results take longer to arrive, hold it anyway and add the final numbers to the board when they land.
What questions should a project post-mortem ask?
Start with what was promised and what was delivered. Then ask where you lost the most time, what you found out too late, which decisions you'd make again, and what you'd tell a team starting a similar project next month. There are 12 more prompts on this page.
Should you run a post-mortem on a successful project?
Yes. Teams usually only review failures, so they never learn why the good projects went well. A successful project's post-mortem is often the most useful one to share.
How do you make sure post-mortem lessons get used?
Make sharing an action item with an owner: someone presents the lessons at the next similar project's kickoff, or brings them into that team's pre-mortem. Lessons that only live in a document rarely get read.
Run this retro in Retro Rabbit
Your team adds notes during the sprint, CarrotIQ groups and summarizes them and suggests action items, and unfinished items carry into the next retro.
14-day free trial · No credit card