Vact Project Post-Mortems: Turning Completed Projects into Organizational Learning
A project post-mortem is a structured review conducted after project completion to capture lessons learned, document what worked well, and identify improvements for future projects. Unlike sprint retrospectives which focus on process within a sprint, post-mortems examine the entire project lifecycle from kickoff to delivery.
Project Post-Mortems: Turning Completed Projects into Organizational Learning
When to Conduct Post-Mortems
Run a post-mortem within two weeks of project completion. Waiting longer causes memories to fade and reduces the accuracy of observations. Every significant project deserves a post-mortem — successful and unsuccessful ones alike. Teams learn as much from success as from failure.
Post-Mortem Agenda (90 Minutes)
| Time | Topic | Duration |
|---|---|---|
| 0:00 | Set context: project summary, goals, outcomes | 10 min |
| 0:10 | What went well? (silent brainstorm + discussion) | 20 min |
| 0:30 | What did not go well? (silent brainstorm + discussion) | 25 min |
| 0:55 | Root cause analysis of top issues | 20 min |
| 1:15 | Action items for future projects | 15 min |
Facilitation Guidelines
Establish safety. Apply the same blameless principles from incident postmortems. Focus on systemic issues, not individual failures. “Our estimation process consistently underestimated backend work” is systemic. “John underestimated his tasks” is blame.
Include diverse perspectives. Invite team members from all disciplines and roles. Developers, designers, QA, the Product Owner, and stakeholders each experienced the project differently. A post-mortem with only developers misses the product and stakeholder perspective.
Use data. Bring project metrics: velocity trends, defect rates, milestone adherence, and budget performance. Data anchors the discussion in facts rather than feelings.
Key Questions
Scope and Planning:
- Was the project scope well-defined?
- How accurate were our initial estimates?
- Did scope changes follow our change control process?
Execution:
- Were sprint goals consistently achieved?
- What were the biggest blockers and how quickly were they resolved?
- Was technical debt managed effectively?
Communication:
- Were stakeholders appropriately informed?
- Did team communication work well?
- Were decisions documented?
Quality:
- What was the defect escape rate?
- Was the definition of done appropriate?
- How did the final deliverable compare to expectations?
Capturing Lessons Learned
Document post-mortem findings in a standardized format stored in the team’s documentation system:
| Category | Lesson | Evidence | Recommendation |
|---|---|---|---|
| Estimation | Backend work underestimated by 40% | Sprint data | Add 1.4x factor for backend estimates |
| Dependencies | External API delivery delayed 3 sprints | Milestone log | Require API contracts earlier, use mocks |
| Communication | Stakeholder surprise at demo | Meeting notes | Weekly async updates |
Making Lessons Stick
The most common post-mortem failure is capturing lessons but not acting on them. Strategies to ensure lessons are applied:
- Add improvement actions to the team backlog
- Review lessons from past projects during kickoff meetings
- Assign an owner for each action item with a deadline
- Track action completion in subsequent retrospectives
- Build a searchable lessons-learned database that project managers consult when planning new projects
A lesson learned that changes no future behavior is not a lesson — it is a note.