Project retrospective

You help the team learn from a project so the next one goes better. A useful retrospective is grounded in what actually happened (dates, numbers, decisions), hears from everyone rather than the loudest, looks for causes in how work was set up rather than in who slipped, and produces a handful of actions that someone owns and that are checked later. A retrospective whose actions are never followed up is a meeting, not a retrospective.

When to use

• "The launch is done, let's do a retro."
• "What did we learn from the office move?"
• "Why did this project run three weeks late?"
• "Quarter's over, review how we worked."
• At the end of any project, phase or quarter; schedule it before the team disperses.

What you need

• The plan and baseline (dates, budget, scope), the final actuals, status reports and the change log.
• The risk register and issue log: which risks happened, which issues were unexpected.
• Metrics that show the outcome: success measures from the charter, quality (defects, rework, complaints), cost.
• Everyone who was involved, including the owner and any outside parties who are willing: reach them with ask_teammate or brief_team.
• Last retrospective's actions (session_search, memory), to check whether they were done.

Method

1. Set the frame. State the purpose (learn and improve, not judge) and the principle often called the Retrospective Prime Directive, from Norm Kerth: assume everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available and the situation. Say it at the start of every retrospective.
2. Build the factual record first (with execute_code from the plan and status history):
   • Timeline: key events, decisions, changes, surprises, with dates.
   • Plan versus actual: each milestone's baseline and actual date, budget versus spend, scope changes approved, success measures hit or missed.
   • Which risks materialised, which issues were not foreseen. Share it with the team before collecting views, and ask for corrections.
3. Collect views individually before any group discussion. Send the prompts in references/retro-formats.md to each person separately. Pick one format and rotate formats between retrospectives: Start / Stop / Continue; Went well / Didn't go well / Puzzles / Ideas; Sailboat (wind, anchors, rocks, island); the timeline with energy levels.
4. Cluster into themes. Group similar points, count how many people raised each, and pull the facts that support or contradict them. Keep what went well: it is what to repeat.
5. Find causes for the top 2 or 3 themes. Ask "what made this possible?" and "how did the way work was set up lead here?" rather than "who". Use 5 whys sparingly and check each step against the record. If an answer is "someone made a mistake", ask what made the mistake easy to make and hard to catch.
6. Agree 3 to 5 actions, each specific, owned by one person, with a date and a way to tell it is done ("Add supplier lead times to the plan template by 30 Nov: Ops lead"). Prefer changes to templates, checklists, defaults and decision rights over reminders to "communicate better". Focus on what the team controls; route anything outside it to the owner as a proposal.
7. Write it up (template in the reference) and share with everyone who contributed and the owner.
8. Follow up. Put each action in the team's tracker or todo, set a cronjob reminder for the action dates, and open the next retrospective by reviewing these actions. Save lessons that apply to future projects in memory (for example "Supplier contracts here take 3 weeks, not 1").

Worked example: a late go-live

Facts first:

• Go-live baselined for 18 Nov, actual 25 Nov (+5 working days).
• Budget 42,000, spend 44,100 (+5%). Scope delivered in full.
• Error rate in month one 0.6% against a target of under 1%: met.
• Risks that happened: the supplier's test environment arrived late (R1 on the register). Not foreseen: each API question took 9 days to answer. Individual replies, 7 of 8 people: 5 raised supplier dependencies, 4 praised the training, 3 said the status report came too late in the week to act on. Themes by weight: supplier deliverables planned as if they were in our control; training worked (repeat it); status timing. Cause for the top theme: the plan carried no lead times or service levels for supplier deliverables, and the contract set no response times during implementation. Not "the supplier was slow". Actions:
• Add supplier deliverables with lead times and named contacts to the plan template (Ops lead, 30 Nov; done when template v2 is in the shared folder).
• Put implementation response times into future supplier contracts (owner, at the next contract).
• Move the status report to Wednesday (project lead, from the next project). Saved to memory: "Supplier test environments here take 3 weeks from request, not 1."

Prompts that get useful answers

Send to each person separately, with the timeline attached, and ask for bullet points by a date:

• What went well that we should repeat?
• What cost us time, money or quality?
• What puzzled you, or still feels unresolved?
• If you could change one thing about how we run the next project, what would it be? Ask people not to compare notes until everyone has replied. Formats to rotate between, and the write-up template, are in references/retro-formats.md.

Running a live session (if the owner hosts one)

Sixty minutes for a project of a few weeks, ninety for longer:

1. Purpose and the principle (5 minutes).
2. Timeline review and corrections (10).
3. Themes from the individual input (15).
4. Causes for the top two or three themes (15).
5. Actions with owners and dates (10).
6. Read the actions back (5). Keep the discussion on what the team controls; note the rest as proposals for the owner. You prepare the pack and take the notes; the owner or project lead facilitates.

Output

• Retrospective document (2 to 3 pages): purpose and scope, timeline, plan versus actual table, what went well, what did not, themes with causes, actions table, lessons for future projects, last retrospective's actions with status.
• A show_card with plan versus actual headline numbers and the actions table.

Checks before you finish

• Facts in the timeline and numbers have a source and were checked by the team.
• Every contributor was asked individually; you note who did not respond.
• No individual is blamed in the write-up; causes are about conditions, process and decisions.
• 3 to 5 actions, each with one owner, a date and a "done" test.
• Previous retrospective actions are reported as done, not done, or dropped with a reason.
• Lessons that should change future plans are saved where future planning will find them.

Pitfalls

• Skipping the facts. Without the timeline, the retrospective becomes the loudest memory.
• Group brainstorming first. Senior voices anchor everyone. Collect individually.
• Fifteen actions. None get done. Pick the few that matter.
• Vague actions ("improve communication"). Change something concrete.
• Only the negatives. What went well is the cheapest thing to repeat.
• No follow-up. The next retrospective starts with last time's actions, every time.
• Blame in disguise. "Sam didn't escalate" becomes "there was no agreed point at which a slipping task is escalated".

See also

• project-status-report, project-risk-register, operational-root-cause-analysis, process-improvement.