PROJECT RETROSPECTIVE TEMPLATE
Internal learning record. Not delivery acceptance or a client status report. Replace bracketed fields and remove the fictional example before use.

PROJECT OR PHASE
Project/reference: [name/reference]
Review boundary and period: [what is included]
Participants and note keeper: [names]
Material participants are authorised to see: [agreed references]
Sharing boundary and correction process: [agreement]

AGENDA
1. Confirm the project/phase and discussion boundary.
2. Review the previous improvement action and what happened when it was tried.
3. Collect examples of what helped and what got in the way.
4. Separate observations from explanations; mark unanswered questions.
5. Choose a realistic change; keep other ideas in a separate list.
6. Agree an owner, due date, trial opportunity and next review point.

LEARNING NOTES
What to keep and reference: [practice/evidence]
Observation and source reference: [what can be checked]
Possible explanation and uncertainty: [hypothesis, not established cause]
Alternative explanation or missing evidence: [question]

IMPROVEMENT ACTION
Chosen change: [specific action]
Coordinating owner and agreement: [person]
Preparation due date: [agreed date]
Opportunity to try it and dependencies: [project/event/required agreement]
Evidence to examine afterwards: [what will be retained]
Review point: [date or explicit agreed trigger]
Current result: [not tried / what was actually observed]
Review decision: [pending / keep / adjust / stop the change]
Next check if no suitable trial occurs: [owner/date]

FICTIONAL COMPLETED NOTE
Paper Kite Studio, North Quay Books, the people, references and dates below are invented illustrations, not customers or measured results.

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.