A project retrospective is useful when a finished piece of client work leaves you thinking, “We should handle that differently next time.” The difficulty is turning that thought into a change someone will actually try. A meeting full of sensible observations can still end with no owner, no date and no way to tell whether the next project was different.
This project retrospective template is for freelance collaborators and small creative studios reviewing how they worked together. It separates the record of what happened from possible explanations, then turns a selected lesson into an improvement action and a later check. It is not a delivery sign-off, an invoice checklist or a weekly client status report.
Download the project retrospective agenda and fictional example (TXT) and the improvement action tracker (CSV). They are manual working documents. Replace the bracketed fields and remove the fictional examples before using them for your own team.
Use a retrospective for learning, not project sign-off
Choose a completed project or a clearly defined phase to examine. Name the period and the work included so the discussion does not drift into every frustration the studio has ever had. The question is how the team worked and what it wants to change, rather than whether the client has accepted a deliverable.
Atlassian’s retrospective guidance, checked on 22 October 2026 Australian time, describes looking at what went well, where problems occurred and what to improve next. Its page concerns sprints. This guide adapts that basic learning pattern to a client project; it does not prescribe Scrum roles, meeting lengths or a particular software tool.
Keep the operational close-out separate. A missing approval, an outstanding file or an unfinished commitment still needs its normal owner and follow-up. Record it in the project’s working list instead of treating a retrospective discussion as proof that it is complete. The freelance project checklist addresses the practical work around delivery; this template addresses what the team learns from doing it.
Prepare a small record everyone can examine
Ask the people who did the work to bring a concrete example of something worth keeping and something that made the work harder. Useful records might include a versioned brief, a task history, a review request or an agreed date. Bring only material the participants are authorised to see. A client discussion should not become a way of exposing another client’s files or a colleague’s private messages.
Identify who will keep the notes and who will help the group stay on the chosen topic. These are working responsibilities, not a new job hierarchy. Agree how participants can correct an inaccurate note and what, if anything, may be shared outside the group. Do not promise anonymity if the example or small team would make the person obvious.
Check the previous improvement action before collecting a new list of lessons. If the team never tried it, record that honestly. It may have lacked an owner, depended on an unresolved decision or simply not fitted the next job. Adding another action without understanding that gap can make the tracker look active while the working method stays the same.
Separate what happened from why you think it happened
Start with an observation that another participant can inspect. “The request for approval did not identify the proof version” is different from “The client does not read our messages.” The first can be checked against a request; the second assigns an explanation that the record may not support. Keep the possible explanation in its own field.
| What we can show | Possible explanation to discuss | Question before choosing an action |
|---|---|---|
| The review request did not name the proof version | The team may not have had a shared request format | Did everyone know which version needed a decision? |
| Comments arrived in separate messages | The agreed feedback coordinator may not have been clear | Was one person asked to consolidate the response? |
| A reusable layout was easy for both designers to find | The shared reference may have helped the handover | What should we preserve in the next project’s setup? |
These are illustrative prompts, not findings about your project. Ask what else could explain the same event. An unclear request, an unavailable approver and a change in the client’s priorities call for different responses. If the evidence cannot distinguish them, leave the explanation uncertain and decide what you would need to check.
Discuss the working arrangement rather than using the meeting to rank people. A named owner can help explain what happened, but “be more careful” is not a useful process change. Keep a note of disagreement where it matters. Agreement reached by dropping an inconvenient example is a weak basis for the next experiment.
Run the discussion through a reusable agenda
The TXT supplies this sequence without a fixed duration. Let the amount of work and the participants’ availability determine the session. A smaller discussion of one real difficulty is more useful than a long agenda that nobody can finish.
- Confirm the project or phase, participants and boundaries of the discussion.
- Review the previous action and any evidence of what happened when it was tried.
- Collect examples of what helped and what got in the way, with their references.
- Separate observations from explanations and mark unanswered questions.
- Choose a change the team can realistically try, while recording other ideas separately.
- Agree the action owner, due date, opportunity to try it and next review point.
Keep a successful practice visible as well as a difficulty. If a shared reference made a handover easier, name the practice you want to repeat instead of recording only “communication was good”. A team can decide to preserve something deliberately; a retrospective does not need to invent a problem to justify meeting.
Leave with an action someone can own
Write the proposed change as something a person can do. “Improve feedback” is a topic. “Add a proof-version field and a named decision request to the next review message” is an action. The owner should be able to say what will exist when the preparation is finished and when the team will have an opportunity to use it.
Keep the action’s due date separate from the review point. A message template can be ready before the next proof is sent, while the evidence of whether it helped will only exist after someone uses it. If the next suitable project is not scheduled, name that dependency and set a date to check whether an opportunity has appeared. Do not invent a delivery date just to fill a cell.
| Action record | What to write |
|---|---|
| Change and observation | The proposed action and the specific event that prompted it |
| Owner and due date | One person coordinating the action, with an agreed date |
| Opportunity and evidence | Where it will be tried and what the team will examine afterwards |
| Review point and result | When to return to it, what was observed and whether to keep, adjust or stop the change |
Someone else may help, but a shared responsibility with no coordinating owner is easy to lose between projects. Confirm that the person has agreed to the task and can obtain the inputs it needs. If the action requires the client’s agreement, make that a separate step rather than assuming an internal discussion changes the client’s process.
A fictional brochure team chooses one experiment
The following completed note is an invented illustration. Paper Kite Studio, its client North Quay Books, the people and all project references are fictional. No customer result, time saving or improvement has been measured. The example deliberately leaves the outcome open until the team can try the change.
Review boundary: North Quay Books catalogue, design and review phase; reference NQB-CATALOGUE. Paper Kite Studio’s collaborators Ava and Leon review the way proof requests were prepared.
Keep: The agreed page list and latest proof were stored together. Both collaborators could locate the material without asking the person who prepared it.
Observation: The request for the second proof asked for approval but did not identify the proof version in its wording. Comments were later attached to an older proof.
Possible explanation: The collaborators did not share a standard way to name the version and the decision requested. They have not established whether this was the only reason for the mixed comments.
Chosen action: Ava will prepare a reusable proof-request note with a version field, the decision needed and the agreed feedback coordinator. Leon will check it against the next fictional proof before it is used.
Due date and opportunity: The note is due on 27 October 2026. The team plans to try it at its next suitable proof request after agreeing the arrangement with that project’s client.
Evidence and next check: Keep the sent request and its matching response reference. Review on 3 November 2026 whether an appropriate trial occurred. If it did, check whether both collaborators can match the response to the named proof; if it did not, record why and agree the next check.
Current result: Not tried. No decision to keep the change has been made. Other ideas remain in a separate list rather than being recorded as completed actions.
The preparation deadline and next check are different commitments. The note can be written on time even if the next client review has not happened. The team should be able to record that state without calling the experiment a success or assuming that the absence of complaints proves a better process.
Return to the evidence before carrying the lesson forward
At the agreed check, ask whether the action was prepared, whether it was used and what the record shows. Those are separate questions. If nobody used the new request, the team cannot evaluate its effect from that project. If it was used, look for the stated evidence rather than choosing a different measure after seeing the result.
Decide whether to keep, adjust or stop the change. Keep it when the observed evidence gives the team a practical reason to repeat it. Adjust it when the next attempt needs a specific correction. Stop it when it does not fit the work or adds an unnecessary step. An inconclusive trial can remain inconclusive; record the reason and the next decision rather than forcing a positive outcome.
Store the reviewed note and evidence reference where the collaborators can find them for the next project. A meeting notes record can help identify the agreed action, but the retrospective stays an internal learning record unless you have agreed to share it. A client status update still belongs in its own communication route.
You can record the preparation task and later review task against the relevant client project in TASKUL, with an owner and a date for each. Keep the retrospective and its source references in the team’s agreed document location. This is manual follow-through, not a promise that TASKUL analyses causes, generates meeting minutes, measures improvement or sends English task-due email. The useful finish is a change the team can examine again, rather than a meeting it merely remembers having.
