Why We Hate Project Debriefs (But Love Project Retrospectives)

by Katy French

If you’re like us, the word “debrief” can give you a little PTSD, especially when it comes to projects. Sometimes they’re helpful, but they can often just devolve into rehashing or project recapping without any real valuable insight. We know this because we found ourselves in debrief hell for years, creating way more work for ourselves (with little reward) until we realized we could do something more effective, something that would serve a genuine purpose and help our team improve. That’s why last year we decided to turn our project debriefs into project retrospectives.

We know there are plenty of agencies and organizations drowning in debriefs, so today we’re sharing a little bit about how we’ve been experimenting with the way we give and receive feedback, how these tweaks have benefited our team, and how it might help yours, too.

But First, Let’s Talk About How We Got Here

We swear our intentions were good. Years back, when Column Five first began to take on more clients, we needed a way to solicit feedback, improve our processes, and grow. So, we made debriefs a requirement. Before projects could be marked officially closed, our team (usually producers) would fill out a formal debrief questionnaire and, in theory, this would help us all learn how we could improve.

It seemed like a good idea, but it eventually became clear that these debriefs were ineffective for several reasons:

  1. We were wasting precious time. Our original debrief survey consisted of a few questions. Now, that doesn’t sound like a lot in theory, but our producers juggle dozens of projects and clients at a time. Filling out debriefs for a month’s worth of projects could (and sometimes did) take days.
  2. The questions weren’t insight-driven. Eventually, we tried to reduce the debrief drama by paring the questionnaire down, but even that didn’t really give us enough helpful info. Simply pointing out what was wrong or rating a project on a scale of 1-10 didn’t really give us actionable insight. Also, because people were falling behind on debriefs or back-burnering them, they couldn’t always recall the project’s issues or answer questions with as much detail by the time they actually got around to them.
  3. The insights weren’t shared. Even when producers did fill out the surveys and we maybe had a conversation or two about how to improve next time, their feedback often languished in those surveys. We couldn’t easily translate it into useful insights or process-level changes. Similarly, we couldn’t cultivate communication between departments. If a producer noted that the design team struggled to hit deadlines, but in reality the design team was delayed because content came in late, that information was siloed. We didn’t have a way to get teams talking positively and proactively.

Some people subscribe to the “if it ain’t broke, don’t fix it” philosophy. We say if it isn’t helping, it’s hurting. So last year we axed the debrief as we knew it.

Switching From Debriefs to Project Retrospectives

Just because our debriefs weren’t serving their purpose didn’t mean we weren’t eager to figure out a more effective way to get that valuable info. Feedback is the only way we can improve all aspects of our business, whether it’s our relationships with partners, our process, or each other. So we thought about a better way to solicit feedback, dive into issues, and solve problems. Thus, the project retrospective was born.

Unlike our project debriefs, our project retrospectives aren’t a solitary experience. They aren’t typed out and sent into the ether. They’re a group conversation where everyone is encouraged to discuss how a project went, guided by a facilitator. The goal is simple:

  • Empower everyone on the team to communicate openly and honestly about the frustrations, successes, and discoveries in their work.
  • Identify ongoing issues, problems, and challenges so that leadership can help address them.
  • Discover things that worked (aka happy accidents) that can improve our processes/tools going forward.

Tl;dr, they’re an opportunity to figure out how to work better and more efficiently.

How We Run Our Project Retrospectives

Our project retrospectives (aka retros) are fairly simple. We don’t do them after every single project, only after particularly large, challenging, or unique projects. 

After a project wraps, we block off at least an hour for a retro, grab the team, and have a laid-back but productive conversation. Here’s how it works.

1) We invite the whole team (plus some).

We include everyone who worked on the project, including producer, designer, account director, etc. We also include a facilitator to guide the conversation and a neutral person who can listen to what’s being said and identify issues or pose solutions. (This is often our VP of People and Culture Tamara Hlava.) Including someone neutral is particularly helpful to identify the group’s blind spots and address issues objectively, without being emotionally invested.

2) The facilitator structures the conversation.

While the conversation is an open format, the facilitator is there to offer prompts, nudge people out of their shells, identify issues, and keep the conversation focused. To start, we ask simple questions that get the ball rolling. These are usually:

  • What lesson/learning experience (good or bad) did this creative team take from this project?
  • What changes would we make were we to start this project today?

As people answer, the facilitator takes notes to guide the conversation, identify through-lines, or flag things to circle back to.

3) We focus on what we can control vs. what we can’t.

As the group provides feedback, we encourage each other to address challenges or issues through the lense of control. (That way it doesn’t devolve into a complaining or finger-pointing session without useful resolutions.)

  • For problems we can control (e.g., late content deliveries), we talk about direct actions and solutions, from process changes to tools we might use.
  • For things we can’t control (e.g., a client sending incomplete data), which are more complex, we talk through potential solutions or ways that we can anticipate, accommodate, or reduce the problem going forward.

This helps us cut through the static and focus on only productive and actionable ideas and solutions.

Why Our Project Retrospectives Work

We’ve learned our team functions better and gets more out of an organic conversation than a formal survey, but really the biggest benefit of this format is that it lets us use our collective brainpower to find solutions. It also bonds us to each other, as that face-to-face time cultivates a different dynamic than endless emailing.

That said, we’re always looking for ways to enhance and refine our process. Our retros aren’t perfect, but they’re improving. Most importantly, they’re far more productive than those damn debriefs. In the end, we’ll always choose people time over paperwork, so we’ll take it as a win.

We hope this little glimpse into our project retrospectives gives you something to think about for your own team. If you’re interested in more things we’ve learned in our work…

BTW, we love opportunities to solve any and all creative challenges, so holler at us if you’ve hit a roadblock and need to get unstuck.

Leave a Reply

Your email address will not be published. Required fields are marked *