On this page
Project debriefs have a reputation problem. The word itself suggests a bureaucratic obligation, a meeting that needs to happen before the project is officially closed, producing a document that will be filed somewhere and not consulted again. Most organisations intend to do them, relatively few do them well, and the ones that do often find the results are too vague to be useful.
A debrief that works does one specific thing: it produces concrete changes to how you’ll approach the next project. Not observations, not general reflections, actual changes to decisions, processes, or approaches. If you get to the end of a debrief and you haven’t identified at least two or three things you’ll do differently, the debrief was probably too polite.
Why debriefs get skipped
The most common reason is timing. By the time a project ends, the team is already on to the next thing. The debrief keeps getting deferred until it’s too late, too long after the project for people to remember the specific decisions and moments that are most worth examining. The fix is to schedule the debrief before the project ends, as part of the project plan, rather than waiting until everything is wrapped up.
The second reason is that debriefs can feel threatening. Asking “what didn’t work?” in a team context requires psychological safety, the confidence that identifying failures is treated as useful information rather than blame. If the culture doesn’t support that, debriefs tend to stay superficial.
What a good debrief covers
A useful structure works through: what you set out to do, what you actually did, what the results were, what worked well, what didn’t, and what you’d do differently. In that order, because the “what worked” and “what didn’t” sections are more honest when they follow a clear-eyed look at the results rather than preceding it.
The “what we’d do differently” section is the one to spend most time on. Push for specifics. “Better planning” is not useful. “Brief the designer three weeks earlier, not two, to allow for revision rounds” is useful. “More stakeholder engagement” is not useful. “Hold a stakeholder review at the end of week two before production starts” is useful.
Making the learning stick
The debrief conversation is only valuable if it produces something that changes future practice. That means writing up a short summary, what was discussed, what the key findings were, and what will change, and sharing it with anyone who needs to know. It also means being explicit about who is responsible for the changes and when they’ll be reviewed.
If the same lessons come up in every debrief without anything changing, the problem is not the debrief. It’s that the outputs aren’t being acted on. The template helps you identify lessons; acting on them is a separate organisational habit.
A template to work from
The project debrief template gives you a structure for a 60–90 minute debrief conversation covering results, what worked, what didn’t, and concrete lessons and actions. Comes as an editable Word document and a PDF reference version.
Project Debrief Template
Editable Word document and PDF reference version.
Download the project debrief template,