The Ultimate Guide to Project Debriefs

Last weekend, we gathered to celebrate Grandpa’s 90th birthday. Ninety!

As the whole family was busy eating and laughing, I sat down with him for a few minutes.

In our conversation, I realized that this guy is basically ChatGPT.

Like AI, but funnier.

The wisdom, the experience. He’s seen it all!

Bought a house? Done that 5 times.

Built one? Done, twice.

He raised kids, fought in a war, shot a bear, sunk his boat - the list is endless.

And you know what he enjoys most? Telling his stories. To share what he has learned so that the people he cares about don’t make the same mistakes.

Imagine you had access to someone like that for your projects…

Someone who’s seen it all and is there to help you avoid the same mistakes.

You guessed it. It exists.

It’s not a person; it's a knowledge base of successful strategies and past mistakes culled from previous projects within a company or your career.

It won’t come with the charm and jokes of a 90-year-old, but it’s equally valuable.

And yet, 90% of project managers I work with sleep on this idea.

How do you build this wisdom? Document your lessons learned, by having a proper debrief as part of your project closure.

It’s simple and crazy effective.

Here’s how you do it:

Project debriefs: what & why

Let’s start with a quick definition: a debrief is a meeting held shortly after your project is done to discuss what worked, what didn’t, and how these lessons can be applied in the future.

Some call it a post-mortem, a retrospective, a recap, a lessons-learned meeting - all different names for the same concept.

It sounds obvious, but very few project managers actually do this.

While a project is unique by definition, success within the same context comes from many repeatable elements. By taking the time to look back with your team, you can improve your process and approach for your next project.

To make sure you get the most learning out of it, here are my lessons learned about lessons learned 😉.

Preparing your debrief

Let your team know you’ll be doing a debrief early on in the project, and encourage them to keep track of things they’d like to bring up. Plan the meeting as you’re wrapping up the project, as part of your project closure.

Don’t wait. Do it as you’re wrapping up. Otherwise, people will move to a new project, both mentally and physically.

As part of the preparation, I often send out a simple survey to the team a week in advance. I use Google Forms for this, which is free, fast, and super simple. (Here’s how you make a Google Form).

The reason for the survey is twofold: it provides a chance for the quiet people on your team to be heard, and it gives you input in advance to prepare for the meeting.

I usually ask a few simple questions like:

1. How do you feel about the completed project?

2. What do you wish you knew when we started?

3. What parts were most successful?

4. What were the major misses?

5. What frustrated you most?

Encourage them to stick to observations and feelings - things that can’t be argued about. This helps you to keep this meeting out of a right vs wrong conversation (more on that later).

I always urge people to contact me in advance with anything they’d like to discuss but don’t feel comfortable sharing with the whole team.

In the ideal world, there would be enough perceived safety to say anything out loud, but we have to be realistic here. Let’s not let our ideal view of a team get in the way of learning.

The debrief meeting

Before the meeting, make sure everyone replied, and go through the responses. Your goal here is to group them, to spot the patterns.

Group them on a slide or whiteboard, and start the conversation by thanking everyone for their input. Explain that the goal of this meeting is to:

1. Revisit what you were trying to achieve

2. Look at what actually happened

3. Figure out why

And only once you understand why those things happened, can you move on to recommendations for your future self.

Take the input from the survey one by one, and start digging for gold.

“Three of us mentioned that we were late on milestone X. Why do we think that happened?”

“Disagreement over the scope.”

Why?

“The scope was not clearly communicated with everyone.”

Why?

Don’t settle for the first answer. Dig deeper.

Think like a toddler here. The annoying and cute one that asks “Whyyyy?” all day. As you can see in the example above, this could go in many different directions.

Was the team Slack channel chaos? Did the client not understand the technicalities enough to agree on the scope?

Keep asking why until you’re at the root cause. Only that is something you can learn from for the future. “Better scope statement” Is not a lesson. Educating a client on technicalities to make better scope decisions, that’s something you can work with.

Simple, but definitely not easy.

I’ll be honest with you: this meeting is a hard one to run.

In some cases, no one talks. They’ll sit there, arms crossed, hoping someone else addresses the elephant in the room.

Other times, it escalates into a blame game.

This is your moment to step up as a leader. Keep the conversation calm and constructive.

Mistakes were made as a team, so solutions should also be sought as a team.

This conversation is not about individual performance - that’s your job 1:1. Saying that out loud can be a powerful way to diffuse a conversation that becomes personal.

The meeting output

The output of the meeting can be as simple as a one-page document. Don’t get caught up in doing it perfectly, building databases, or using the lack thereof as an excuse for not doing it at all.

The document you make is a letter to your future self, and answers one single question:

What do you know now that you wish you knew at the start of this project?

It explains the gap between what you tried to accomplish and what actually happened, and why the team thinks that is.

It then makes a few simple recommendations along the lines of:

• What worked well and would you absolutely do next time

• What did not work well, and what would you do instead

• What did you not do, and should you have done

These recommendations can be about virtually anything: your project management method, technical details, communication, team dynamics, risks, resources, you name it.

There's no right or wrong, no checklist. It's about what's relevant for you or a colleague in a similar position in the future.

Bringing it all together

Most readers will read this, nodding in agreement.

“Yep, this is super important.”

And then? Nada. As soon as the last deliverable is signed off, they rush off to the next shiny object.

Don’t be that PM. Make this one of the secret weapons in your toolkit.

It’s a very professional way to close a project and shows you’re serious toward your team, your sponsor, and all other stakeholders.

If you follow this playbook, you’ll go well beyond the dreaded “So, how do you think it went?” and actually learn from your mistakes.

Here's a final tip for big projects: conduct a debrief after each major milestone, not just at the end. You’ll uncover gems that you can implement right away to boost your team’s effectiveness.

Good luck with your next debrief meeting!

Cheers,

Jasper