The template
Seven sections across 3 hours
Set the stage and ground rules (15 min)
Restate the purpose: learning, not blame. Establish the working agreement explicitly, with the blameless framing from Google SRE: 'We assume everyone acted in good faith with the information they had. We focus on systemic factors, not individual error.' Round-robin one-word check-in from each attendee. Confirm the time horizon being reviewed and the boundary of what is in scope.
Project timeline reconstruction (30 min)
Walk through the project timeline as a group: major milestones, key decisions, significant events. Use a visible timeline (whiteboard or shared document) that everyone can see. Each attendee adds events that they remember as significant, including events that may not have appeared in the formal project record (informal escalations, hallway conversations, late-night fixes). The reconstruction surfaces the actual project shape, which often differs significantly from the planned shape.
Outcomes versus plan (30 min)
Compare actual outcomes to original plan: scope delivered versus scope planned, schedule versus estimate, budget versus budget, quality versus target, stakeholder satisfaction versus expected. Quantify where possible. For each significant variance, surface the contributing factors without yet assigning lessons. This section produces the factual basis for the rest of the retro.
What went well (30 min)
Surface the things that worked: specific practices, decisions, people, tools, conditions. Use silent-write-first (10 min) then small-group sharing (15 min) then group cluster (5 min). The discipline of starting with what worked matters: retros that start with failures set a defensive tone that suppresses the positive lessons. Capture each in enough detail that other projects can repeat them.
What went badly (45 min)
Apply blameless post-mortem framing. For each issue, ask the 'five whys' to find systemic cause: why did the issue happen, why did the conditions that allowed it exist, why were the warning signals missed, and so on until you reach a systemic factor. Examples of systemic factors: process gaps, tool limitations, knowledge silos, communication patterns, decision authority unclear, time pressure. Avoid stopping at individual factors ('Person X should have done Y better'); that is not a lesson, that is an attribution.
Lessons and recommendations (20 min)
Convert each 'went well' and 'went badly' insight into a specific lesson: 'When [condition], do [practice], because [outcome].' Identify which lessons apply to: the team's next project, other teams running similar projects, the wider organisation. Prioritise 5-7 lessons worth formal documentation; the remaining stay in the retro notes.
Action commitments and close (10 min)
For the priority lessons, identify specific actions and owners: who will update the playbook, who will share with which other team, who will follow up to confirm adoption. Document the lessons in the project management office (PMO) repository or team wiki within 5 business days. Close with round-robin one-sentence takeaway from each attendee.
Blameless culture
The Google SRE blameless framing
The blameless post-mortem is the most important cultural element of a project retrospective. Without it, participants spend their energy defending themselves rather than analysing what happened. The Google SRE book chapters on postmortem culture (Chapter 15 of the first edition) document the practice in depth; the principles below are the operative summary.
Assume good faith
Start from the position that everyone acted reasonably given the information they had at the time. People rarely make mistakes because they wanted to; they make mistakes because conditions allowed it.
Focus on systems, not individuals
The lesson is never "Alice should have known better." The lesson is "the conditions that let Alice not know were [process gap, tool limitation, communication failure]." Systemic lessons can produce systemic fixes; individual lessons cannot.
Treat near-misses as data
The project may have ended without major failure. That does not mean there is nothing to learn. Near-misses (issues that could have caused failure but did not) are valuable data about what could go wrong on the next project.
Document for outsiders
Write the retro document for someone who was not in the room. The discipline forces the team to articulate context that insiders would gloss over and produces a document other teams can actually learn from.
FAQ
Common questions about project retrospectives
How is a project retrospective different from a sprint retrospective?
A sprint retrospective looks back at 2 to 4 weeks of work and focuses on team process. A project retrospective looks back at 3 to 12 months of work and covers project outcomes, stakeholder satisfaction, scope decisions, and lessons that span beyond the team. The longer time horizon and broader scope change the meeting structure: project retros need more pre-work, run longer (2 to 4 hours typically), and produce lessons useful to other projects, not just to the team's next sprint.
When should a project retrospective happen?
Within 2-3 weeks of project completion. Earlier and emotional reactions distort the discussion; later and memory has degraded too much. For projects that failed or were cancelled, hold the retro within 1 week while context is fresh. For long-running projects that span major phases, hold mini-retros at the end of each phase rather than waiting for total completion.
What is a blameless post-mortem?
A post-mortem (the term used in incident response and SRE practice) that focuses on systemic and process factors rather than individual error. The Google SRE book formalised the practice: assume that everyone acted in good faith with the information they had, focus on what made it possible for the failure to occur, and design countermeasures at the systemic level. Blameless framing produces more honest contribution because participants are not defending themselves; psychological safety produces better learning.
Should clients or external stakeholders attend the project retro?
Generally no for the internal retro, yes for a separate client-facing version. The internal retro needs psychological safety for the team to be honest about internal process and decisions; client presence changes what people are willing to say. Hold a separate client retro covering shared topics (scope outcomes, communication quality, what to do differently next engagement). PMI's PMBOK recommends this two-meeting pattern explicitly.
How long should a project retrospective be?
2 to 4 hours for the working session, plus 30 to 60 minutes of pre-work per attendee. The duration is longer than sprint retros because the time period reviewed is longer and the topic set is broader: project outcomes, stakeholder satisfaction, scope decisions, team dynamics, individual development, lessons for next project. Compressing the discussion to 90 minutes produces surface-level lessons that other projects cannot benefit from.
Where should lessons learned be stored so future projects can find them?
In a project management office (PMO) repository if one exists, in a team wiki tagged by project type if not. The PMBOK lessons-learned register convention is to tag each lesson with the project phase it applies to, the type of project it came from, and the specific action recommended for similar future projects. Lessons stored without searchable structure rarely get found by future projects, which means the retro produced no organisational learning.
Related
Related retro and review templates
Sprint retrospective (5 formats)
Shorter retro for 2-week sprint cycles. Different time horizon, different format choices.
Generic retrospective
Catch-all retro structure for events that are neither sprints nor full projects.
Full-day offsite
For very large projects where the retro deserves a full day rather than a half-day session.
Effective agenda principles
Five elements every agenda needs, with sources for what works in reflective meetings.