In short
A review is worth running only if it ends with one change, one owner and one date. Everything before that is preparation. Keep the session short, ask what surprised people rather than what went well, separate causes from incidents, and then pick a single thing to change rather than agreeing to five. Reviews fail when the output is a document: nobody owns a document, and the next project starts before anyone reads it.
Key takeaways
- One change, one owner, one date. A review producing five actions produces none.
- Ask what surprised people. It surfaces the assumptions that caused the trouble.
- Run it within a fortnight, while memory is specific rather than general.
- Blameless is not politeness; it is the only condition under which people report accurately.
- Check the previous review's action first. It is the only thing that makes the next one credible.
Why most reviews change nothing
The lessons-learned session is one of the most widely practised and least effective rituals in professional work. A group meets, discusses what happened, someone writes a document, the document is filed, and the next project reproduces the same problems.
Three specific reasons, all fixable.
The output is a document. Documents have no owner and no deadline. A finding recorded is a finding parked, and everyone in the room knows it, which is why the discussion has a slightly performative quality.
Too many findings. A good review generates ten observations. Agreeing to act on all ten guarantees acting on none, because there is no first move and no capacity behind any of them.
Incidents rather than causes. “The client changed the brief in week four” is an incident. The cause is that the brief was never confirmed in writing, which is fixable, and the incident is not.
A review that produces a list has produced homework nobody has been assigned. A review that produces one change has produced a change.
Timing and length
Within two weeks of finishing, and under an hour. Both constraints do real work.
The two-week window exists because memory degrades into narrative fast. Ask in month three and you get “it was a difficult project, the client was demanding,” which is a summary rather than information. Ask in week one and you get “we waited nine days for the brand assets and started without them, which is why the first version was wrong,” which is something you can act on.
The hour limit prevents the session from becoming a general discussion of everything the team finds frustrating. It also makes the meeting cheap enough to hold routinely, which matters more than any individual session being thorough.
One exception: if a project ended badly and people are still upset, wait a week. A review held while the argument is live becomes the argument.
Four questions worth asking
The standard what-went-well and what-went-badly format produces polite answers to the first and cautious answers to the second. These four work better.
| Question | What it surfaces |
|---|---|
| What surprised you? | The assumptions that turned out to be wrong, which is where most trouble originates |
| Where did we wait? | Elapsed time lost to queues rather than to effort, usually the largest recoverable amount |
| What did we do twice? | Rework, and its cause. Frequently the most actionable finding in the room |
| What did you work around? | Process failures that everyone has quietly adapted to and nobody has reported |
The first question is the strongest opener, because surprise is specific and memorable in a way that judgement is not. People who cannot say what went badly can always say what they did not expect, and the two overlap almost entirely.
The fourth is the highest-yield and needs the safety described below. A workaround is a functioning solution to a real problem the official process does not handle, which makes it the best evidence available, exactly as in an internal operations audit.
Blameless as a mechanism, not a courtesy
Blameless review is often framed as a cultural nicety. It is better understood as a precondition for getting accurate data.
If describing what happened might reflect on someone present, accounts get shaped. Not dishonestly, but selectively: the delay is attributed to circumstance, the error is described passively, and the specific decision that caused the problem goes unmentioned. The resulting review is comfortable and contains nothing.
Three things establish it practically:
- Talk about conditions, not people. Not “Ben missed the deadline” but “the deadline was set before the dependency was known.” Almost every individual failure has a condition behind it that would have caught out most people.
- The most senior person goes first and names something they got wrong. Nothing else establishes the norm as quickly.
- Nothing from the session appears in a performance conversation. Stated explicitly, and honoured, or the second review will be silent.
End with one change
The final fifteen minutes are the point of the meeting, and they are the part most often lost to overrunning discussion. Protect them.
From the findings, group by cause and pick one to act on. The selection criteria are the same as anywhere else in operations:
- Is it upstream of other findings? One cause frequently explains three observations. Fixing it removes all three.
- Will it recur? A one-off circumstance is not worth process change, however painful it was.
- Can it be done in a fortnight? Anything larger becomes an initiative and needs to compete for a slot, as covered in too many priorities.
Change, with a named owner and a date, is the entire deliverable. A review that agrees five improvements has agreed a wish list, and everyone leaving the room already knows which four will not happen.
Write the change as a specific behaviour, not an intention. “Communicate better with clients” is not a change. “The brief template now requires a named decision-maker before work starts, and Amara updates it by Friday” is.
The bit that makes the next one credible
Open the next review by checking the previous one's change. Did it happen? Did it work?
This single habit determines whether reviews are taken seriously. A team that has watched three consecutive commitments quietly evaporate will attend the fourth session and contribute nothing of substance, correctly identifying it as theatre. A team that has seen one change land will bring real material.
Expect some changes not to survive. The change that was agreed enthusiastically and abandoned in the first busy week failed for structural reasons rather than motivational ones, and the diagnosis is in why process changes don't stick: the old route was still available, or nobody owned it, or it was announced rather than built into the tools.
Reporting that honestly at the next review is more valuable than reporting a success, because it identifies why your changes do not hold, which is a more important finding than any individual improvement. The Mayim Ops assessment is built around the same discipline: it produces one prioritised first move rather than a findings list, on the grounds that a business acting on one thing will finish it.
Frequently asked questions
What is a project retrospective?
A short structured review after a piece of work, examining what happened and why, in order to change something before the next one. It differs from a status review in that its output is a change rather than a record, and from a performance review in that it examines conditions rather than people.
How do you run a retrospective that actually leads to change?
Keep it under an hour, focus on causes rather than incidents, and finish with exactly one change that has a named owner and a date. Reviews that produce a list of five improvements reliably produce none, because nothing on the list is anyone's specific responsibility.
When should you hold a post-project review?
Within two weeks of finishing, while people still remember specifics. Later than that and recollection collapses into general impressions, which produce general conclusions and no actionable change. Immediately afterwards is also poor if the project was difficult and feelings are still raw.
Should retrospectives be blameless?
Yes, and for practical rather than cultural reasons. People describe what actually happened only when doing so carries no personal cost. A review where the accounts are guarded produces a tidy narrative and no information, which is worse than not holding one.
What should you do with retrospective findings?
Convert one of them into a change with an owner and a date, and check at the next review whether it happened. Findings recorded in a document and left there teach the team that reviews are ceremonial, after which attendance becomes compliance rather than participation.