project retrospective
Also called: blameless retrospective, project retro, post-project review
A meeting at the end of a project or a stage where the team looks at what happened, why, and what to do differently next time. It is blameless: it asks what in the plan, process or information led to a result, not who to blame, and it ends with a few changes that have owners.
A project retrospective is a meeting at the end of a project or a stage where the team looks at what happened, why it happened, and what the next project should do differently. Its output is not a feeling of closure but a small number of concrete changes with owners.
A good retrospective is blameless. It looks at facts and decisions rather than at people: what did we know at the time, what did we choose, and what in the plan, process or information made this outcome likely? The reason is practical. When a retrospective looks for someone to blame, people learn to hide problems, and the plan that produced the problem stays the same. Judging a decision by what was known when it was made, not by how it turned out, also avoids hindsight bias.
A useful order: gather the facts (a timeline, the data), look at the key decisions and the information behind them, find the causes in the plan or process, and agree at most three actions, each saying what changes, who owns it and by when. "Communicate better" and "test more carefully" are not actions; "the launch checklist adds a check X at stage Y, owner Z, by date D" is.
Lessons that stay on a slide are forgotten by the next project. Lessons written into templates, checklists and estimation data are used even by people who never attended the meeting. Estimates versus actuals from past retrospectives are among the most useful inputs for planning the next project.
Example
Klasna's physics launch opened on 1 February 2027, but three days before opening, on 28 January, the team found that the diagnostic test broke on phones with a dropped connection. In February only 35 % of tests started on phones were completed, against 64.71 % on computers, and phones were 67.92 % of all starts.
A blaming question would be "Why did Danylo miss it?". The blameless version: what did we know in November, and why did the plan put the phone check in the last week? The answer is about the plan: nobody (not Danylo, not Vira, not the plan) wrote outages and weak connections down as a test condition, and acceptance testing was scheduled at the very end.
Draft notes rewritten as actions:
Klasna's earlier retrospectives already show why the second action matters: across three past launches, 142 estimated days became 168 actual (168 ÷ 142 = 1.18), and reviews overran most, by a factor of 1.688.
Common mistakes
- Looking for a culprit. Blame teaches people to hide problems and leaves the plan unchanged; ask what the plan made likely.
- Judging with hindsight. Judge decisions by what was known when they were made.
- Too many actions. Twelve actions mean none; keep three at most.
- Vague actions. "Communicate better" has no owner or date; write what changes, who and by when.
- Leaving lessons on a slide. Put them into the checklists, templates and estimation data the next project will use.
Learn it in the course
- The benefits check and a blameless retrospective · Check the result weeks after launch against the success criteria, run a retrospective on facts and decisions, turn lessons into owned actions and close with a one-page report.