Debriefing Team Efforts Are Important
Debriefing the Analysis or Design Team after their key meetings is critical to the processes I created in my PACT Processes for T&D, Learning and Knowledge Management. Debriefings are important for the process and for you – the lead of the effort or as a Stakeholder in the effort. They offer reinforcing encouragement or corrective warning shots across your bow. And – debriefings bring closure, they are the final process check.
Debriefing the teams after key meetings in the PACT Processes for T&D is a critical skill for the practitioner that may or may not come easy. It all depends on your natural or learned facilitation techniques and style, but it can be learned by most. And – as the PACT Processes use a facilitated approach to data generation with a group of Master Performers (your people may call them exemplars) it is important to remember two things:
1- You won’t know personally how good a job the group assembled did just because they seemed to come to a consensus and let you write stuff down without them correcting it a lot – or outright rejecting it – until they assess how well they did. After all – if you yourself never did this job before – how could you possibly assess the completeness and accuracy of the outputs generated?
2- Just because they came to consensus on the data they provided to you – does not make them 100% right! But – who else could you ask to both generate this data – and then assess it in terms of completeness and accuracy? Only Master Performers understand the nuances of their job tasks and outputs that supervisors/managers most often won’t – or downstream customers cannot appreciate (other than what is delivered to their doorsteps – when the outputs becomes the input).
This post covers my thoughts and typical process steps for debriefing the hand-picked teams assembled to define Performance Competence – and against that define the gaps of all other non–Master Performers. And – I fully appreciate that there are many excellent ways to accomplish this than presented here. These just have worked very well for me over the last 29 years of my real-world applications – beginning in 1982. The “Group Process” was first written about/published in 1984 in Training Magazine. It is similar to bringing “experts” together to do Process Mapping and Process Re-Engineering – but with an Instructional Design purpose in mind.
I use this method – the Group Process method – as opposed to individual interviews and observations – for reasons I have articulated numerous times in numerous places: but suffice it to say it is quick (accelerated) and generates a better output – analysis data and design data that is more accurate, complete, appropriate – and authentic.
There are five debriefing points that I cover with every Analysis Team and Design Team – and I show them these as an “advanced organizer” before we actually start on the analysis or design steps – as part of every team effort’s “kick-off” – so they know how they can “nail” me and/or the process that I am about to drag them through.
The five debriefing points – usually articulated in a little more depth are:
- How complete and accurate of a job did we do regarding everything?
- How complete and accurate of a job did we do regarding critical items?
- How good are our outputs?
- How did you like the process?
- What are the issues going forward?
Exactly how you do this as a facilitator is somewhat open. PACT debriefings can tolerate some variation. But, as always, it depends. Situational assessment and specific reactions are tough to spell out in detail and are beyond the intent or scope of this post. See the more detailed versions of these debriefing questions later in this post and the follow-on post (Part 2).
PACT Process Meetings Debriefings
As I forewarned the team in the meeting kick-off, I always conclude my analysis and design efforts with a group debrief. It’s always there in the meeting agenda near the end. Very near the end – ¾ just before I say, “Thanks and have a safe trip home y’all.”
Debriefings bring closure. They are the final process check. I value them because they are my final clue and cue whether or not we collectively did a good job. Otherwise I have no clue. Yes, I read the clues and cues as I facilitated the team through the process appropriate to the meeting charter. So I have incremental feedback about the various piece-parts produced as we did them.
But now, at the end, I’d like the team members to sit back and take a collective breath (it’s a big sigh of relief for those who comprehend that we are really wrapping up with this step) and then take stock of what we’ve done and reflect on that verbally.
And if any of the team members just happen to start this debriefing prematurely before we are really finished with the meeting, I attempt to divert them back to the task at hand. I will then remind the group at that point that we will do a formal debriefing once we are finished and have accomplished our charter mission.
That mission is to produce either
- A Performance Model and Knowledge/Skill Matrix for a job, or job family, or a department/function, or for all of the jobs working one or more particular processes
- A Curriculum Architecture Design, or a Modular Curriculum Design, or the designs and development of a set of Instructional Activities instructions and materials
The debriefing is focused around five questions.
- What percent of everything under the “sun and moon” did we capture in terms of our coverage of the outputs, tasks, and enabling knowledge and skills within our project’s scope?
- What percent of everything critical, and not just necessary, did we capture in terms of our coverage of the outputs, tasks, and enabling knowledge and skills within our project’s scope?
- What did you personally think of the product we produced? The content of both the Performance Model charts and the Knowledge/Skill Matrix charts?
- What did you think of the process we employed to produce the Performance Model charts and the Knowledge/Skill Matrix charts?
- What do you see as the key issues going forward for our Project Steering Team to address?
All good facilitators have their own personal version of the above, and there are many versions and variations on those themes that may be apropos in a particular situation. You as a facilitator have to always be able to figure that out for yourself, on the fly, live. And you need to know how to recover in case you bark up the wrong tree by using the wrong phrasing for your question and sent a member of the team into a state of agitation. “It’s not just semantics,” an old colleague used to say, “It’s always semantics.”
We’ve all heard that it’s good to start work with a group by
- Telling them what you’re going to tell them
- Telling them
- Telling them what you’ve told them
The PACT Processes’ spin on that is to
- Tell them what I’m going to facilitate them to do
- Then do that
- Then have them tell us how well we did
To paraphrase or even perhaps quote Thiagi, “All the learning happens in the debriefing.”
Debriefing brings closure for everyone, regardless of his or her role. If done well, it allows everyone to have his or her final say.
If you had a good team of master performers and real subject matter experts, you most likely had a team of strong egos. They usually have something to say. This is their outlet. And if done correctly, they can still discover more and more about what it is that we did and can discuss the value (or lack of value) that it promises for our intended use in downstream efforts.
Let them know at the beginning that the debriefing is coming at the end of the meeting, and then remind them throughout the meeting that this is one of the final steps in the meeting agenda.
Beware: if it seems important and timely to the team to have a side discussion on the process or the content, early or not, they will try. And then you’ll have to decide whether to attempt to intervene or not, and then perhaps how to intervene.
Timing is everything, as it is said. Great facilitators have a great sense of timing. If portions of the debriefing process have to be done early by the group because the team just really needs to talk something outlet them or help them. But get on with it. Don’t get so bogged down by your process script that you can’t deviate from it upon occasion especially when the occasion seems to call for it.
The trouble is, it’s a judgment call, and those are usually problematic because they are so situational.
We’re not saying this is always easy. It is not.
# # #