Lessons Learned Template (Post-Mortem)
A project post-mortem / lessons-learned document — what went well, what did not, root causes, and recommended action items with owners, captured after a project or incident so the team improves next time.
Live preview
LESSONS LEARNED / POST-MORTEM
Website Relaunch — Q2
Review date: May 23, 2026 Facilitator: Sample Lead
Participants: Product, Eng, Design, Marketing
SUMMARY / OUTCOME
Launched 1 week late but with no major incidents. Traffic and conversion met targets within two weeks; a few rough edges in the CMS workflow.
WHAT WENT WELL
- Cross-team standups kept everyone aligned
- Staging environment caught major bugs early
- Clear rollback plan reduced launch-day stress
- Design system sped up page building
WHAT DID NOT GO WELL
- Scope crept after kickoff; no formal change control
- Content wasn't ready until the last week
- Load testing started too late
- Unclear ownership of the CMS migration
ROOT CAUSES
- No agreed change-control process for new requests
- Content timeline not tied to the build schedule
- Performance work treated as "later," not a milestone
RECOMMENDATIONS / ACTION ITEMS
[ ] Adopt a lightweight change-request form for scope changes
Owner: Priya Due: next sprint
[ ] Lock content deadlines 2 weeks before launch
Owner: Marco Due: ongoing
[ ] Add load testing as a required milestone
Owner: Dana Due: next project kickoff
[ ] Name a single owner per workstream
Owner: Lead Due: immediately
Share this with the team and revisit the action items at the next kickoff so the
lessons actually change how the next project runs.
About this template
A lessons-learned document (or project post-mortem) captures what a team should keep doing and what it should change, while the memory is fresh — its entire value is in making the next project go better, not in assigning blame. The most effective ones are **blameless**: they focus on systems and processes ("there was no change-control process") rather than people ("X kept adding scope"), because a blameless tone is what gets people to speak honestly, which is the whole point. Structure the discussion in four parts: **what went well** (so you deliberately repeat it — wins are as instructive as failures), **what did not go well**, the **root causes** behind the problems (push past symptoms — "content was late" is a symptom; "content deadlines weren't tied to the build schedule" is a cause), and **recommendations/action items**. That last part is what separates a useful post-mortem from a venting session: each action needs a **single owner and a due date**, or it will not happen. A few facilitation tips: hold it soon after the project or incident (within a week or two), invite the people who actually did the work, capture the spread of views rather than just the loudest, and time-box it. Crucially, **close the loop** — store the document where the team can find it and revisit the action items at the next project kickoff, otherwise the same lessons get "learned" again and again. For incidents specifically, keep it strictly blameless and factual (timeline, impact, root cause, corrective actions), since the goal is reliability, not punishment.
When to use it
- After a project ships (or an incident is resolved).
- To capture what worked, what didn't, and why.
- To turn problems into owned, dated action items.
- To build organizational memory across projects.
What to include
- Project/event, date, facilitator, and participants.
- A short summary/outcome.
- What went well and what did not.
- Root causes (beyond surface symptoms).
- Recommendations/action items, each with an owner and due date.