Collect private input, examine decisions with the information available at the time, and carry selected changes into the next project.
When the next project reaches discovery, somebody asks whether legal should join earlier, whether the estimate needs a complexity sample, or whether the same handoff will work again. If the answer lives only in a finished project's debrief notes, the team starts over.
A debrief should examine one completed project or milestone while its decisions can still be reconstructed. Its questions differ from a weekly status discussion because the group can compare a finished outcome with the decisions that shaped it. A lesson such as “involve legal earlier” usually disappears with the closed project. A change to the kickoff checklist, with an owner and a trigger, has somewhere to live. This template is designed to produce that second kind of output.
Project debrief template and example
Download the free project debrief template as a PDF. The pages below show its sections in order, from the private pre-debrief input and the project snapshot to the lesson transfer card and the sixty-minute agenda.
The project debrief template: input, snapshot, gap, and transfer card on the first page, the sixty-minute agenda on the second.
What is a project debrief template?
A project debrief template is a repeatable structure for examining one completed project or milestone while its decisions can still be reconstructed. It collects private input first, compares the planned outcome with the actual one, examines the decisions behind the biggest gaps, and ends with lesson transfer cards that name the artifact to change.
A project debrief examines a completed outcome and the decisions behind it. It should end with a change the next project can use: an owner, a trigger, and a checklist, brief, estimate sheet, or routine to update. A lesson phrased only as a behaviour is much harder for the next team to apply.
Use Plaud to capture an approved debrief and review the evidence
An AI meeting recorder gives the team a source to revisit when it needs to separate the outcome from the information available when a decision was made.
Root-cause conversations move quickly, and the facilitator still needs to challenge vague explanations. With everyone's permission, Plaud can preserve the wording around a decision, disagreement, or proposed change. The transcript gives the team a source to check while it decides which explanation is supported and which change belongs in the next project.
1. Capture the debrief with Plaud Desktop or a Plaud device
Record with Plaud Desktop
Record with a Plaud device
A debrief may run in a meeting room, on a video call, or as a hybrid of both. Plaud Desktop can capture the computer meeting, while Plaud Note Pro can capture the room. Reviewing the related recordings in one Plaud library makes it easier to check how a decision, disagreement, or handoff was described across the project.
For a hybrid debrief, keep one shared evidence board and one facilitator. Avoid running separate in-room and remote conversations, since the people outside the room will otherwise contribute to a different record.
Plaud One
Voice-led capture and retrieval for work that continues after the conversation.
Shop now
Plaud Note Pro
Team meetings in the room or on a call, with every decision, owner, and date on record.
Shop now
Choose the capture method around where the debrief happens. Use Plaud Note Pro, a physical AI note taker, for a debrief around a table where the facilitator needs to return to the wording of a decision. Use Plaud One, a wearable AI earbud, when the conversation continues away from a desk and you need to check the original wording later.
Use a recording to create the first draft, then check the decisions, owners, dates, and conditions that require human judgment.
2. Review the recording with Plaud Web or Plaud App
Pick the template and generate
Ask Plaud any question to modify the template
Open the recording in Plaud Web or Plaud App and use the transcript and summary to find the wording around each decision, disagreement, or proposed change.
After the session, use the transcript to verify dates, evidence, and agreed owners. Then complete the transfer cards as a team. The transcript records what people said; the group still has to decide which explanation is supported and which change should enter the workflow.
3. Find the evidence through Plaud MCP
Connect Plaud MCP to Claude or ChatGPT
Ask the assistant for the evidence
Plaud MCP lets a connected AI assistant search Plaud recordings and retrieve a transcript or summary. Use it to find the evidence behind a decision, and keep the lesson transfer cards for the team to write.
Find the [project name] debrief from [date]. For each decision discussed, list the evidence cited and the information the team had at the time. Quote the wording around any proposed change. If an owner or date was not stated, mark it as “to confirm.” Do not write conclusions or lesson transfer cards.
Check each quote against the recording before it goes onto a transfer card.
Collect evidence before people start agreeing with one another
Send three prompts privately one or two days before the session. Private input reduces the chance that the first confident answer becomes the room's answer. It also gives people who need time to look through their own work a way to arrive with evidence rather than a vague impression.
The facilitator groups overlapping responses without removing minority views. “Four people mentioned handoff delays” adds useful context, but a fifth person's security concern still belongs in the record. Start with private writing, then read and cluster the responses together. Keep the session tied to one completed project or milestone, rather than turning a routine weekly meeting into a retrospective.
Use the debrief to explain one selected gap
Begin by putting the original goal beside the actual result, then choose the two or three gaps worth understanding. A complete chronology would consume the time needed for diagnosis. If the group cannot name the project outcome and the gap it wants to examine, the item belongs in a weekly team discussion rather than in this debrief.
Record what the team knew at the time of the decision. A sensible decision can still lead to a poor result, while a careless decision can appear successful by chance. Separating decision quality from the outcome gives the next team a more reliable lesson.
Turn one finding into a change that can survive
Each selected lesson becomes a transfer card. It links the insight to a working artifact and to the moment someone will need it.
“Improve estimation” leaves the next estimator alone with the same process. “Add a five-page complexity sample to the migration estimate sheet before pricing” changes the process they will actually use.
Worked example: a late website migration
The team planned a 14-week migration and finished in 19 weeks. It still met the mobile performance target and came in under budget, so “the project failed” would flatten a mixed result.
The largest gap was content migration. The estimate used page count, yet 90 of the 420 pages had custom layouts requiring individual work. At estimation time, the team knew the total page count but had not sampled complexity. The delay came from using the wrong unit, not simply from working too slowly.
This record preserves the reasoning and gives the next team a checkable change. It also retains what worked: the content freeze prevented late scope churn and should remain in the launch checklist.
Run the debrief in 60 minutes
Send the pre-debrief prompts early enough for people to answer independently. During the session, spend the time on differences and causes rather than reading every response aloud.
0 to 5 minutes: Restate the original goal, outcome, and review rules 5 to 15 minutes: Compare planned and actual outcomes 15 to 25 minutes: Read and cluster the private input, including clear and unresolved items 25 to 45 minutes: Examine decisions, available information, and mechanisms 45 to 55 minutes: Write up to three lesson transfer cards 55 to 60 minutes: Edit the target artifacts or assign the edits
The facilitator should stop a chronology once the group has enough evidence to explain a selected gap. Capture another issue in the record and return to it only if it changes a decision or a future working practice.
Decide which lessons deserve action
Score a proposed change against four practical questions:
- Is there concrete evidence that the issue affected the outcome?
- Does the change address the mechanism rather than its visible symptom?
- Can it be placed in a document, system, or recurring event that already exists?
- Will the team be able to tell whether it helped on the next project?
Observations can remain documented without entering the action list. Reserve that list for changes the team has capacity to own and a clear way to test.
End the session by editing the real artifact
If possible, open the checklist, brief, estimation sheet, or kickoff agenda before everyone leaves. Add the approved change and link back to the debrief. Assigning “update the process” as a later task creates another place for the lesson to disappear.
Keep the transfer list short. Three changes added to future work are more likely to be used than fourteen observations left with the closed project. Keep unselected observations in the record without presenting them as commitments.
The final debrief should contain:
- the measured outcome against the original goal,
- the few gaps examined and the evidence behind them,
- what the team knew when each important decision was made,
- successful practices worth preserving,
- transfer cards for approved changes, and
- unresolved questions that require more evidence.
More meeting templates
Related templates for planning work, recording group decisions, and separating external commitments from internal follow-up.
Team meeting agenda template
Decide what deserves shared time before the meeting, and record the outcome in the same document.
View template →Meeting minutes template
Record decisions, owners, due dates, and open questions from a group meeting.
View template →Client meeting notes template
Keep the client-facing recap separate from the internal account note.
View template →
