How to run a project retrospective
The project is delivered, the final invoice is sent, and the lessons are already evaporating. That evaporation is the problem a retrospective solves. Run one within a week of delivery — while the messages, the dates and the invoice still say what actually happened — and it answers a single question: what will you change before the next project starts? Keep it to an hour, keep it to four questions, and hold it to one rule. A retrospective is a fix list, not a feelings exercise, and never a blame session. A finding that does not end as a changed artefact — a template line, a clause, a price, a checklist step — is not a finding. It is a diary entry, and diary entries do not protect the next project.
1. The four questions, in order
The four questions are this guide's own — no framework borrowed, nothing to be certified in. They work in one order: promise, events, money, surprises. Each is answered from records, not recollection, because recollection is the least reliable document in the business.
What was promised? Open the scope as signed — the document the client agreed to, drafted with the scope of work generator or from your own template — not the scope as you now remember it. Memory edits agreements, always in somebody's favour, and a retrospective built on the remembered scope audits a project that never existed. Lay the signed deliverables, dates and exclusions beside what was actually delivered. The gaps between those two columns are the raw material of the whole hour.
What actually happened? Build the timeline from evidence: the message thread, the calendar, the invoices. When the assets arrived, when approvals landed, when the work moved and when it waited. Impressions compress waiting and expand effort; dates do neither. Most projects contain a week nobody remembers choosing — the timeline finds it, and names what it was spent on.
Where did the money move? This is the verdict the other questions serve. Set the hours the project actually took against the fee it actually paid: the project profitability calculator returns the margin and the effective rate, and where extras piled up, the scope creep cost calculator separates the creep's share from the base job's. A project can end with a delighted client and a fee quietly worked at half your rate. Only this question notices — and it notices in numbers, which is why it comes before the last one.
What surprised you? The unknowns the project revealed: something about this client (assets arrive as phone photos; decisions need a second person), something about the work (the “simple” migration never is), something about yourself (you estimate design well and calls badly). Surprises are the most valuable findings in the hour, precisely because your system had no line for them. A known problem already has a price or a process. A surprise is a hole in both.
2. Blame-free, on purpose
Blame is the failure mode that empties retrospectives. The moment the hour becomes a trial — of the client, of a subcontractor, of yourself on a tired Friday — the findings turn into verdicts about people, and verdicts about people produce no fixes. So hold one rule: name processes, never people.
“The kickoff skipped the asset checklist” is a finding: it points at a step that can be made un-skippable. “I am disorganised” is not: it points at a person, and nothing in the business changes because of it. The same discipline covers the client's part. Record it as a risk fact, in the flattest language you can find: “approvals at this client take a week”. That is not a grievance. It is a planning constant, as neutral as their time zone — and unlike a grievance, it can be priced, buffered and planned around next time.
This is not politeness; it is engineering. Every sentence in the retro should be one a stranger could act on without knowing who was at fault — because the person acting on it, three months from now, will effectively be a stranger: you, with this project's heat long gone.
3. Every finding becomes an artefact
The hour ends with conversions, not conclusions. Each finding leaves as a change to a document the business already owns:
| The finding | The artefact it becomes |
|---|---|
| A scope gap the client walked through | A new exclusion line in the scope template — the most-edited citizen of your freelance template library |
| Approvals that ate a week | A milestone buffer in the next quote, counted honestly with the working days calculator |
| A phase priced on hope | A note on the rate card: this phase, this many hours, this price from now on |
| A clause that failed when tested | The clause rewritten in your contract basics before the next signature |
| A client pattern worth remembering | A line in that client's notes from the client-list audit, where the next verdict will read it |
Then make the changes now, in the same sitting, while the evidence is open on the desk. A fix list that goes home as intentions joins the archive of good intentions. And cap the list: if everything was a finding, nothing was. The two or three changes that would have moved this project's money or its calendar are the retrospective. The rest is colour.
4. The 30-day check
A retrospective nobody revisits is theatre. So the hour ends with one calendar line, thirty days out, asking a single question: did the fixes survive contact with the next project? The new scope line — was it in the next proposal, and did it hold? The buffer — was it quoted, or quietly dropped the first time a client pushed back? A fix that dies at first contact was a wish, and the check is where you find out while the lesson is still warm enough to fix properly.
File each retro with the project's records, one page per project. They accumulate into something larger than any single job: the solo quarterly business review harvests the year's retrospectives, turning four quarters of fix lists into the year's pattern — the same surprise three times is no longer a surprise; it is a price or a policy waiting to be set. The annual sitting, the freelance year-end admin checklist, then reads the summaries instead of reconstructing the year from memory. Project by project is where the lessons are; quarter by quarter is where they become the system.
5. When not to run one
Three exceptions, all of them about proportion. The tiny job: a one-day engagement does not need an hour of anything — it gets the two-line minimum, what moved the money and one thing you will change, written the week it ends. Mid-project: a retrospective needs an ending to examine; held mid-flight it becomes a status meeting in costume and spends its hour on this week's fire instead of the pattern — let the project finish, the evidence keeps. While angry: a project that ended badly deserves its retro most, and deserves it after forty-eight hours, not during. Heat writes grievances, and grievances fail the test of section 2 — they name people and produce nothing. The messages, dates and invoices are not going anywhere. Wait until you can read them as records, then hold the hour. Honesty without heat is the whole method.
Questions
Related: where the fixes land
The artefacts live in the freelance template library, are priced by the rate card, protected by contract basics and harvested by the solo quarterly business review. One hour, four questions, a short list of changed documents — run it while the evidence is still warm. One of its outputs faces outward: the two-week client check-in promised by the project wrap-up email gets its calendar date in this sitting. And when the evidence arrives uninvited — a bad review names the failure before your retrospective does — our guide to how to handle a bad review covers the reply, the unconditional fix, and how the lesson feeds back into this hour.