End-of-Project Review

Review a whole project once, at its end: reconstruct what happened, explain it, and commit to changes that travel to the next project. The metrics table, quality check and personal reflection are in the optional sections at the end.

Strong research support for structured debriefs of this kind; the common formats (Kerth, 2001; Derby & Larsen, 2006) are practitioner codifications. The Kolb cycle is a widely used heuristic whose logic has been criticized and revised, and the why chain is contested for complex problems. Treat both as scaffolding.

Use it when:

• A project of weeks or months has finished, or been stopped, and you want lessons that outlive the team.
• You are about to start a similar project and have no written account of the last one.
• You are leaving a role or a client and want to hand over what you learned.

Skip it when:

• You want a quick, regular look at how a team works while the project is running: use 8.12 Project Retrospective.
• The question is your own growth rather than the project: use 1.12 Kolb Cycle Learning Sheet or 1.13 Gibbs Deep Reflection Template.

Experience does not teach by itself. Teams turn a project into capability only when they reconstruct what happened, explain it and commit to changes. Structured debriefs of that kind have strong research support, and the usual formats (Kerth, 2001; Derby & Larsen, 2006) are practitioner codifications of the practice. The reflective backbone comes from experiential learning, where experience becomes learning through reflection, generalization and renewed action (Kolb, 1984); read it as scaffolding, not settled theory. The why chain (Ohno, 1988) is contested for complex problems where single root causes rarely exist, so expect several causes and stop where the explanation genuinely ends.

The order follows that loop. Planned versus actual comes first, so interpretation cannot soften it. Both worked and failed need causes, not verdicts. The payoff is the lessons: each must name who needs to know, because a lesson that stays in the room changes nothing.

Write down what you set out to do and what happened, with numbers.

Strong answer: (illustrative numbers) "Planned 14 weeks and 2.1 MSEK, actual 18 weeks and 2.2 MSEK; four of five deliverables handed over, the fifth moved to the next phase." Not: "A bit late but fine."

Project, dates and owner (a role):

Original goal (SMART):

Delivered: (fully, mostly, partly, not delivered)

Illustrative example: the company and the numbers are made up.

A Swedish building contractor renovates a school kitchen. Planned 14 weeks, actual 18; budget 2.1 MSEK planned, 2.2 actual. What worked: the pre-start walkthrough with the kitchen staff, which caught a wrong door width early. What did not: the ventilation unit arrived six weeks late, with part of the delay absorbed by re-sequencing.

Why chain: it was ordered after the building permit. The permit was applied for after design freeze. Design freeze was set from a delivery promise made in the tender. Root cause in the setup: the schedule was built from the tender promise, with no permit time in it.

Lesson: start the permit at design freeze, in parallel with ordering. Who needs to know: the estimators and the next two project leads. Action: add "permit lead time" to the estimating checklist (owner: estimating lead, by 15 June). The review also feeds the next reference class in 8.22.