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.
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.
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]
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
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
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
posted by Candleman at 2:10 PM on November 22, 2019
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
- 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
This thread is closed to new comments.
posted by DrGail at 12:43 PM on November 22, 2019