Process-oriented Debriefing
November 22, 2019 12:23 PM   Subscribe

I just finished a fairly major project, and as I usually do I'm organizing a debrief/retrospective for everyone so we can improve the next time. Are there any theory- or process-based methods for doing this kind of exercise?

My usual method is just to keep a "lessons learned" document that I update while I plan and execute the project, and then I get team members and managers in the same room and summarize what I've been writing down. I'd like to try using some sort of predefined process this time around. Does something like this exist?

My criteria for this would be:
-Based on some sort of management theory, standards, etc.
-Industry agnostic (I'll take a look at stuff that's geared towards software programs but this was emphatically not a software project so if it leans heavily on code reviews or whatever it's not going to be useful).
-This debrief will cover the planning and execution aspects of the project. We don't have final analysis results yet.
-I want to give all of the team members an opportunity to contribute.
-This is not being used to evaluate individuals' performance, I don't want to point fingers, and I want it to be clear that this is only being used for process improvement. I don't have any managerial power over any person on the team outside of the direct execution of the project.
-The project actually went pretty well, so I'd like to be able to highlight the good things.
posted by backseatpilot to Work & Money (7 answers total) 13 users marked this as a favorite
The method I've seen used most often is very simple but also quite effective. There are two topics: what went well, what didn't go well. If you want to fancy it up a bit, expand it to three topics: what went well, what we should do next time that we didn't do this time (i.e., what would make it go better next time), and what we should not do next time that we did this time (i.e., what got in the way this time). To get everyone's involvement, you can either assign the topics as "prework" or go round robin in the post-mortem meeting.
posted by DrGail at 12:43 PM on November 22, 2019

we do something similar to drgail, but before the debrief meeting, the leader sends around a questionnaire of sorts that the compile before the meeting. that way no one is singled out and the "this went bad" comments are anonymous.
posted by misanthropicsarah at 12:47 PM on November 22, 2019 [1 favorite]

“What almost went wrong and how can we be farther from that error next time” is one of my favorites. But I thought it was endemic to flying, so you probably have it already.
posted by clew at 1:06 PM on November 22, 2019

If you want a phrase to google, try "plus delta debriefing". It is basically what DrGail said. Plus is the positive aspect; delta is the change/improve aspect. I know of this through the construction industry and maybe specifically lean construction if you're trying to find theory behind it. That's not my field--just work with people in that field--so I don't know much more.

The term After Action Review might also be helpful. I believe it involves specific steps or prompts and there are templates/guides out there for how to conduct a review and what it includes. I think this is something the Army uses and maybe they developed the steps. I don't know if you're really looking for the theory behind it or just a template, but there are multiple guides on google, so you can find one you like.
posted by kochenta at 1:11 PM on November 22, 2019

Agile is often used too manage software processes but there's nothing about the retrospective that can't be applied to any process.
posted by Candleman at 2:10 PM on November 22, 2019

In my org, we do both Lessons Learned (which focuses more on the project lifecycle /PMI) and Agile retrospective (to focus on development work in each sprint). Typing quickly, the gist is asking and documenting:
-What went right
-What went wrong
- Impact (if applicable)
- What needs to be improved (and the team(s) that should own that improvement)

We analyse where there are action items (e.g., training, process improvements) that come out of that, and carry out those activities. We store the Lessons Learned in a repository and reference it whenever needed.

The format has varied. In a recent one, each group that worked on the project met separately to collect and submit their inputs in writing, then it was compiled by group into a single document. A third-party moderated a session where the whole project team to stepped through the lessons learned and provided additional context/detail/assigned AIs. We have also done this by having each individual project team member provide their written inputs prior to the meeting (sometimes anonymously, sometimes not) and the PM then acts the meeting facilitator.
posted by sm1tten at 2:41 PM on November 22, 2019 [1 favorite]

I volunteer for a community emergency services organisation, and we have a predetermined structure for 'after-action review' (AAR) after incidents, emergencies, training, or just after responding to being called out to assist.

- What did we do? This can be as simple as a sentence, or be highly detailed or lengthy, but should cover the entirety of what happened, what was attempted or achieved. It's almost never the case that everyone involved in a team activity is aware of everything occurring, so giving everyone a chance to describe what they, individually, did, is essential.
- What did we do well? An opportunity to give credit and praise. It's also a chance to record new processes or new techniques that can be repeated. If any of you got something out of the project that you want to keep, this is the time to describe it.
- What could we do differently? The key to this is that it's not 'what did we do poorly', that's not a helpful review and tends to turn into criticism sessions—like you said, identify processes not point fingers. 'Things that can be done differently' might be as simple as a Plan B if Plan A hadn't worked, different tools or techniques that might have been used if they'd been available, or it could be as detailed as specific changes to processes, policies, and the like.

That's one method of collecting information, and it works for us. The Australian Institute for Disaster Resilience has a handbook in far greater detail (PDF) about the theory and process of how and why organisations learn; its chapter 3 sounds like it's what you're after.
posted by Fiasco da Gama at 11:53 PM on November 22, 2019

« Older How to deal with strangers who crowd you?   |   An ice-cold glass of blood?? Newer »

You are not logged in, either login or create an account to post comments