A project debrief helps a team understand what happened and decide what to carry into the next piece of work. Its value lies in the improvements that follow, not the length of the meeting or the number of observations collected.
Arrange the discussion while the experience is reasonably fresh, with enough information to examine the work fairly. Include the people who delivered it and those affected by important handovers or decisions.
Set a clear purpose
Explain that the debrief will examine the project, its conditions and the choices made. It should not become a public performance review of individual employees. Serious conduct or safety concerns still need the appropriate process outside a general learning discussion.
Share the intended outcomes, timeline and relevant records beforehand. Invite people to add examples of what helped and what made the work harder. Give them a way to contribute if they cannot attend.
Reconstruct what happened
Begin with the original aim and the actual result. Build a short timeline of important decisions, changes and dependencies. Distinguish information that was available at the time from information learned later.
This helps avoid hindsight becoming a judgement of character. A decision that now looks obvious may have involved uncertainty, limited time or a constraint that has since disappeared.
Questions for the discussion
| Question | Useful follow-up |
|---|---|
| What were we trying to achieve? | Did people understand the same objective? |
| What actually happened? | Which records or examples help explain it? |
| What helped? | What should we repeat deliberately? |
| What made the work difficult? | What conditions or decisions contributed? |
| What should change? | Who can make that change, and how will we check it? |
Look for causes you can act on
“Communication was poor” is a starting observation, not a finished explanation. Ask which information was missing, who needed it and when. You may find an unclear approval owner, a late scope change or a handover with no agreed format.
For a fictional website project, a launch delay might be linked to content approval arriving after development was complete. A useful improvement could be an earlier named approval checkpoint, with a clear route for unresolved decisions.
Choose a small number of improvements
Prioritise changes that address a significant cause and have a realistic owner. Some changes sit within the team; others need a decision from elsewhere. Record that dependency rather than assigning an employee an action they cannot deliver.
Describe the intended effect and how it will be checked. “Use the revised handover on the next project and ask the receiving team whether the information was complete” is more useful than “Improve handovers”.
Keep the learning available
Write a concise record of the context, the useful practices and the agreed changes. Store it where the next project team will look, and incorporate relevant changes into the actual template, checklist or process.
A long debrief document that nobody consults creates little value. Before the next project begins, review the relevant lessons and confirm which actions have been implemented.
Close the loop
At the next checkpoint, ask whether the change helped and whether it created a new problem. Keep what works, adapt what does not and acknowledge the people who contributed useful observations.
This is a practical THELM discussion framework, not a substitute for a formal investigation or specialist review where those are required. Its purpose is to make ordinary project learning specific enough to improve the next piece of work.
Related guides
- How to Run a 15-Minute Team Meeting
- How to Follow Up on an Employee Survey
- How to Make a Staff Suggestion Scheme Worth Using
Published as part of THELM's guide library on 2 November 2026. The archive date places this guide within the series; advice and sources were reviewed on 2 November 2026.