Once you have established a working group and discussed the current state enough for the members to become comfortable with each other, you can start to make real progress.
During discussions on Organisational Change (and most other discussions) the group will encounter many problems to be solved. The approach to solving each of these problems follows the same basic framework:
- Create a shared understanding of the problem
- Generate ideas
- Create a shared understanding of each idea
- Evaluate each idea, identifying and understanding the implications
- Deciding between ideas
It is likely that the group will go through this cycle dozens or hundreds of times before reaching a mature end state. Decisions at a high level will reveal many subsequent more detailed problems to be solved. Some groups will want to discuss how they should approach discussing the problems. Often groups will make a decision at a high level and get part of the way through solving the subsequent problems when they hit a problem that causes them to re-evaluate the high-level decision and perhaps decide to explore a different path. These are all normal patterns for groups, but as facilitator it is your responsibility to ensure the group doesn’t get lost, try to talk about too many problems at once, go in circles, or miss things.
Let’s talk about some common pitfalls and what can be done to prevent or cure them:
The group discusses the approach to discussing the problem and this takes up too much time.
This was covered in the last post so I don’t want to recap too much, but basically unless someone can quickly explain a better method that the group likes, ask the group collectively if they will try your approach and see how it goes. This is normally enough to get the group back on track, but if it’s not then likely there is an underlying issue in the group dynamic that needs to be dealt with.
Many of the pitfalls are varations of where the group deviates too far from the optimal path. What I mean by the optimal path is where a group starts with one problem, solves it and then discusses the subsequent problems, solving them along the way, reaching a completed solution with no back-tracking. This is rarely the case as groups rarely understand all implications of each decision and will want to re-evaluate previously-made decisions once they learn more through exploring the sub-problems. Problems are often not simply a case of “A means B which means C which means D”, solutions to one problem will have implications on the solutions to other problems, so many problems must be discussed simultaneously, often revealing a number of scenarios to address the problems.
Problems can start occuring when the group deviates too far from the optimal path. There is no way of telling in advance how far is too far, but normally you can tell that the group is reaching that limit when you start to get confused, when others start becoming confused, when people disengage from the conversation, or when the conversation becomes fragmented or jumps around between individual problems rapidly.
As strange as it might sound, the solution to a group getting lost is to draw a map. This is what everyone is doing mentally anyway, so creating a shared map that everyone can follow shouldn’t disrupt the discussion too much – even for those who weren’t confused.
Maps can take any format that makes sense to the group for that topic. Some maps I have seen used:
- A decision tree, where options are listed and sub-options listed for each option.
This option is purely a navigational aid and would normally be suplemented with some kind of final documentation outlining the details of the solution selected.
- A grid showing all combinations of several variables.
This is normally used to show all combinations of several variables allowing the group to confidently explore these, ruling out combinations that don’t make sense and then discussing and selecting between the rest.
This option is mostly a navigational aid however it may be included in the final documentation which outlines the details of the solutions selected.
- Listing each option, the implications and the associated pros & cons.
This can evolve into a decision tree if next to each option the sub-problems are listed and then for each sub-problem the options are listed following the same format. This can quickly map which options lead to implications the group would like to avoid and prevent discussion from dwelling on options that have been ruled out.
This option produces a skeleton format for what could be the final documentation outlining the details of both the solution selected and the options explored but rejected.
- Documenting the final solution and details as you go.
This works well when the discussion takes place over many sessions as it clearly shows the outputs of the discussion to date. Should the group stop liking the decisions already made and want to explore a different high-level option then the current version of the document can be set aside and a new version produced. Should the group want to re-assess any previously explored options then the documentation can simply be reviewed.
This option provides the least assistance as a map, but if the group remains focussed and doesn’t skip between options it produces the final documentation outlining the details quickly and with the most group understanding of the selected option. The risk here is that the group may choose the wrong option through not identifying or understanding the other options sufficiently.
Map selection is normally a trade-off between mapping the structure of options versus exploring each option in detail. A working group may choose to develop more than one map, perhaps starting with a structural map and finishing with a document outlining the selected option in detail.
Good use of maps will help the group to: see what options they have; discuss each option to the point where it can be ruled out, or for the selected option discuss it until sufficient detail to proceed with implementation is known; and for everyone involved to understand why the group made the decisions it did (even if they don’t agree with them).
Not all use of the above maps will accomplish all of these things in all situations and if the group doesn’t systematically explore and discuss the options it might neglect options, miss things or make errors in logic. For these ommissions or errors it is up to the facilitator to detect these and raise them for group discussion. Depending on the complexity involved or the knowledge of the facilitator it might not be until after the session that these are discovered. Often the person who documents the progress of the group is the one who will find these as writing documentation can trigger insights which may not have been discovered or discussed by the group.
Another dynamic is that some groups will want to discuss things forever without making a decision. It is the job of the facilitator to get the group to follow the steps through to making a decision and moving on. There is a balancing act between rushing the conversation and missing things, and between never reaching a decision and never reaching the end.
There is a lot more to cover in this area and I will focus on these elements in greater detail in future posts.