Gather Lessons Learned, Not Grievances: Continue-Stop-Start

I’ve been a project manager for 8 years and I still don’t have project debrief meetings mastered.

Ideally in a debrief, postmortem, retrospective, or lessons learned meeting, the project team and other key stakeholders will reflect on what they’ve learned from the project so that similar projects can go better next time—or just as well, if everything went well.

Early efforts to make debrief meetings part of the standard project process at my company were unsuccessful—it was hard to get people to make time to stop, reflect, and learn when the next project needed attention. Even if we got people to the meeting physically, their brains weren’t fully in it. So to this day, we typically only have these meetings when the project owner or another manager requests them.

Even with as rarely as we debrief a project, I’ve tended to dread such meetings because in my experience they typically go one of two ways:

1. Too negative. I commonly see debrief meetings descend into complain-fests. When the meeting starts off with one comment about something that went wrong, or was hard, or could be better, it seems to put something in the air that draws out everybody else’s complaints and pain points…big or small, relevant or irrelevant. This is even more likely when everyone knows we’re debriefing because the project had some major problem. While some helpful information can surface, it’s not in the context of a team with a positive attitude that wants to make things better. It’s just about emoting, which in this type of situation is better done in private.
2. Too positive. The other way I occasionally see debrief meetings go is that a ‘groupthink’ dynamic sets in, and people only make positive comments about the project. This is presumably because they only feel safe saying good things to the group at hand; they don’t think constructive criticism or honest feedback is really welcome.

My debrief meetings went one of these two ways for many years. I knew it wasn’t great to have an agenda-free meeting where I’d basically open it up and say, “Well, how do we think it went?” But I couldn’t figure out how to write an agenda when I didn’t know what anyone was going to say, so I was stuck.

That is, until I discovered a debrief framework that usually prevents both of these undesirable scenarios, elicits feedback that is both honest and useful, and keeps the tone positive. It’s also extremely easy to implement; your team won’t need any training time beyond a very brief explanation. I typically see the framework called Stop-Start-Continue, but I prefer to use a modified version called Continue-Stop-Start.

The Continue-Stop-Start Framework

The framework’s origin is unclear. I believe I personally discovered it while poking around Zoom’s Whiteboards feature and its whiteboard templates for retrospective meetings.

To use the framework, you structure your meeting around three basic questions:

The next time we do this (a similar project, an agile sprint, etc.)…

1. What should we continue doing? What worked well that we would want to repeat in a future similar project or make a standard practice of?
2. What should we stop doing? What didn’t work, that we’d do best not to repeat?
3. What could we start doing? What ideas do folks have for things we didn’t do this time, but that might create improvements if we tried them next time?

The framework’s Continue-Stop-Start terminology somewhat assumes you are repeating a project or process over and over continuously, like an agile sprint, but I’ve used it in debriefs of one-off projects and it works just as well. Sometimes I swap out the terminology to make it clearer in this setting, like using Repeat instead of Continue.

The reason I like to put Continue (or Repeat) at the beginning instead of the end is twofold. First, it seems to be the easiest question for people to answer at the beginning of the meeting while their brains are warming up; it doesn’t require anyone to have ideas for changes. Second, by starting the conversation on what went well, it helps set a positive tone for the meeting overall—heading off the negativity problems I mentioned earlier.

While you can use the framework by verbally asking the questions one at a time or listing them out in a written agenda, I find it helpful to put them on a central meeting visual like a physical or virtual whiteboard. You can section out your whiteboard like this, with space to record each type of answer:

The visual achieves a few things. First, it helps people stay focused on what you’re asking them to think about. Second, people don’t always have ideas in the three categories in the exact order you present them, so the visual gives people the freedom to bounce between the different categories as ideas come, and those ideas can simply be recorded. Third, people can stare at other people’s ideas on the whiteboard as they think, which may help inspire their own ideas that build on what’s been said.

You’ll still want to use your meeting facilitation skills, likely marking some transitions during the meeting where you ask people to focus on the next question/category/box. But you can circle back as well if one of the categories is sparse, as people may have fresh ideas after they’ve had more time to think.

You may get even better meeting results if you explain the framework to people ahead of the meeting and ask them to jot down their thoughts ahead of time. This can lead to higher quality or better-fleshed-out suggestions by the end of the discussion.

That’s it! I hope you find it as easy to understand as my project teams and I have, and just as low-friction to implement. It really is a path to debrief meetings that both have the tone and gather the information that make them useful.

I’ll be honest that a really important part of gathering such takeaways is finding a way to be reminded of them in the future when you need to use your learnings. Unless I remember to look back at them at the right time, they don’t help anyone. I don’t have a consistently effective system for such reminders, as debrief meetings tend to elicit a variety of types of information that applies in different situations, projects, phases of a project, etc.

But discussing lessons learned productively and writing them down is an enormous first step, and one the Continue-Stop-Start Framework can help you achieve without much effort! Happy debriefing!