Retrospective and Evaluation
Most retrospectives produce a page of true, agreeable statements that nobody acts on. The difference between those and the ones that change something is almost entirely in the form of the output, not the sincerity of the meeting.
In short
- The output must be instructions, not observations. An action, a number, and when it applies.
- Two different questions: how did we work? (retrospective) and did it solve the problem? (evaluation).
- Safety determines the quality of the input. A retrospective that names people teaches everyone to say less.
- Three to change, three to keep. A twelve-page report is a report nobody opens.
Two questions that get conflated
A closing review is usually asked to answer two quite different things:
| Question | Asks | When it can be answered |
|---|---|---|
| Retrospective | How did we work, and what should the next team do differently? | Immediately after handover, while it’s fresh |
| Evaluation | Did the project actually solve the problem it was funded for? | Weeks or months later — the outcome needs time |
Doing both in one meeting produces a muddle, because the second question usually cannot be answered yet. Run the retrospective now; put the evaluation in someone’s calendar for three months from now, with the success measure from the charter attached. Most organisations never do the second one at all, which is why they cannot distinguish a project that worked from one that merely shipped.
The form the output has to take
Getting from left to right is mostly a matter of asking two follow-up questions in the meeting: “what would we do instead?” and “how much did it cost us?” Both are easy to answer in the room and nearly impossible to reconstruct a month later, which is why the meeting has to produce the finished form rather than raw notes to be tidied up.
Running it
Ninety minutes, six to ten people, one facilitator who isn’t the project manager if you can manage it. A workable shape:
- Establish the facts first (10 min). The timeline: what actually happened, when. Not opinions — dates. This prevents the whole session being reconstructed from the most confident memory in the room.
- Gather silently, then share (20 min). Everyone writes their own points before anyone speaks. Otherwise the first opinion voiced sets the frame and the quietest person — often the one closest to the problem — agrees with it.
- Group and pick (20 min). Cluster the themes, then choose the three or four worth working on. Trying to fix everything is how nothing gets fixed.
- Turn each into an instruction (30 min). This is the bulk of the time and the part usually cut short. Action, number, moment.
- Assign and schedule (10 min). Each instruction gets an owner and a place it will be applied. A lesson with no owner is a note.
Formats like Keep / Problem / Try are useful scaffolding, particularly for teams new to this — they give people permission to raise problems by making it a named category rather than a complaint. Any structure works if it gets you to step 4.
Safety is the input quality
The most detailed process in the world produces nothing if people won’t say what they actually think. Three things determine whether they do:
Discuss causes, not people
“The review took three weeks” is workable. “Marco was slow reviewing” ends the useful part of the meeting and teaches everyone present to contribute less next time.
The most senior person goes last
Or better, admits a mistake first. Whichever happens in the opening five minutes sets the ceiling for everyone else’s honesty.
Something visibly changes
The strongest predictor of a good second retrospective is whether anything from the first one actually happened. Nothing kills participation faster than a pattern of no consequences.
Don’t only review failures
A retrospective held only when things went badly becomes an inquest. Running them after successes is what makes the practice normal rather than threatening.
Making the lessons survive
A perfect retrospective stored somewhere unsearchable has produced nothing. Three rules that decide whether anyone ever reads it:
- Store it with the project, not with a person. The next team will search the project’s name. They will not know your folder structure.
- Make it short enough to read in three minutes. Three things to change, three to keep, with their numbers. Everything else is context nobody needs.
- Push it, once, to where it applies. A lesson about vendor lead times belongs in the next project’s planning checklist, not only in an archive. The most reliable version of this is a habit at kickoff: read the retrospectives of the two most similar past projects. It takes ten minutes and it is the entire return on all of this.
Which suggests the honest test of a retrospective: not whether the meeting was good, but whether a future project’s plan is different because of it.
How this looks in AB
In AB Projects, a Retrospective page in the project Wiki holds the lessons in a format the next team can search, captured as Keep / Problem / Try. Pinning it from the project home makes it the first thing anyone sees when they open the archived project later — which is the moment it needs to be visible.
Tasks tagged as lessons carry individual takeaways with owners, which is how an instruction becomes something with a date rather than a line in a document. And because the change-history tab on every task records what moved and when, the factual timeline in step 1 above can be assembled rather than remembered — an AI assistant connected through the MCP server can be asked to summarise that history into a draft to seed the discussion.
One habit worth adding by hand: put the three or four instructions somewhere the next project will look, not only in this project’s Wiki. A lesson filed only under a completed project is a lesson depending on somebody being curious.
Terms used on this page
- Retrospective
- A structured review of how the work went, aimed at changing what the next team does. Its output should be instructions, not observations. More →
- Post-mortem
- A review held after something went wrong, usually focused on a single incident. A retrospective covers the whole project regardless of outcome. More →
- Benefits realisation
- Checking, months after delivery, whether the project produced the outcome it was funded for. The only real test of whether it succeeded. More →
- Lessons learned
- The reusable conclusions from a project, recorded where a future team will find them. Stored somewhere unsearchable, they are lessons unlearned. More →
- Psychological safety
- The shared belief that raising a problem or admitting a mistake won’t be held against you. The input-quality control on every review you will ever run. More →
- Keep / Problem / Try
- A simple retrospective format: what to keep doing, what caused problems, what to try next. Scaffolding that makes raising a problem a named category rather than a complaint. More →
Related reading
7.3 Knowledge Transfer
Getting the lessons out of this project and into the next one’s plan.
8.2 Lessons from Failed Projects
What retrospectives look like when they have something serious to explain.
3.4 Risk Management
Where a previous project’s lessons become the next one’s risk register.