Main Sections
• Main
• TOC
• Lean Mfg.
• Quotes
Evaporating Cloud and Other Thinking ProcessesFrom: "Francis S. (Frank) Patrick" fpatrick@focusedperformance.com (used by permission)
Go to Focused Performance for an update by Frank Patrick of the information presented below.
My list of "tools" doesn't quite add up to 10, although one of them could be considered a Swiss Army Knife multi-purpose tool. Also, with the exception of that one, the idea of ranking them in "order of importance" is questionable because depending what you are facilitating -- what the group is trying to accomplish -- the tools are important to different degrees at different times in a change process. The tools that I'm about to discuss are "thinking tools" (known as a group as the Theory of Constraints (TOC) Thinking Processes). They can be used in standalone situations, or together they form a coherent problem-solving and change management system. Their generic purpose is to translate the intuition of the members of a group to a form that can be discussed rationally, questioned without offense, and modified to more fully reflect the group's understanding of the situation. They are used for the construction of common sense in order to facilitate communication, collaboration, and consensus among a group. THE CONTEXT
Any time a group is brought together to really accomplish something, the purpose of the gathering can probably be translated to one or more of the three purpose above. Before I get into the specific tools and how they relate to these three purposes, I should really describe the two overarching "meta-tools" that are at the core of the tools -- SUFFICIENCY LOGIC and NECESSITY LOGIC. Sufficiency logic consists of "If...,then...,because..." descriptions of why situations exist or why we believe actions will result in particular outcomes. Linkages of sufficiency logic are also frequently expressed as "If..., and if..., and if..., then..." as in the case when it take three preexisting conditions (the "ifs") to result in the outcome (the "then"). Necessity logic often takes the form of "In order to..., we must...," describing requirements or prerequisites associated with desired outcomes. These requirements may not be sufficient in and of themselves to result in the outcome, but their existence is seen as necessary for it. Linkages based on necessity logic can often be augmented with a "because..." factor as well, which is a very powerful mechanism for surfacing beliefs or assumptions that underlie why we feel we must have A in order to have B. The Thinking Processes, based on these two logical constructs, get their power from the fact that the human mind seems to be practically "hard-wired" with an innate understanding of when the "if-thens" or the "in-order-to, we-musts" make sense or not, lending themselves to an ease of communication, scrutiny, and revision. They also benefit from graphical formats and presentation, so the mind can readily take in not only the words of the various entities, but also the spatial relationships implied by connecting arrows. The tools serve to communicate or verbalize the intuition of the participants in a way that lends itself to collaboration and dialogue and results in a description of the "common sense" of the participants.
The Evaporating Cloud is a construct of necessity logic that takes the form:
B) Requirement <----- D) Prerequisite
and is read: In order to have objective A, we must have requirement B...
One of the tenets of the Theory of Constraints, reflecting its roots in the application of the techniques associated with scientific method to those "soft sciences" like management and behavior, is that in any system that is brought together for a purpose, there is no such thing as real conflict, but only unexamined assumptions. The cloud allows a clear statement of the perceived dilemma and provides a route for the surfacing and scrutiny of those assumptions. I've written about the Evaporating Cloud many times on this discussion list (most recently in the discussion of the Abilene Paradox), but I'll repeat again that under every arrow (including the conflict arrow between D and D') lie assumptions. Brainstorming those assumptions is a matter of reading the "in order to, we must" statements, and then adding the word "because..." to it, soliciting reasons why A requires B or C requires D', or why D and D' are mutually exclusive. Once the assumptions are sufficiently spelled out, it's a matter of finding one that seems suceptible to questioning -- a chink in the armor of the conflict. Also known as a conflict cloud, a dilemma cloud, or a conflict resolution diagram, the Evaporating Cloud provides a solvable verbalization of a conflicted situation where solvable is defined as "win-win." Probably the most multi-purpose of the Thinking Processes, the cloud is appropriate for dealing with tough personal decisions, interpersonal conflict or negotiation (think of requirements as needs and prerequisites as wants), and resolution of what I like to call "systemic conflicts" and by extension, a sort of "root conflict analysis." Speaking of "systemic conflicts," new research/experience in the use of this tool is showing that if a group can verbalize the various dilemmas that they face in dealing with both their day-to-day and long-term efforts via clouds, the results can go a long way to delivering widespread favorable impact on their overall effectiveness. These individual conflicts usually turn out to be systemic conflicts, forcing people between "rocks and hard places" when they try to do the right thing for themselves, their individual departments, or the company as a whole. Often what seems to be the right thing for one of these entities results in a dilemma, the other side of which is doing the right thing for another aspect of the endeavor but that is in conflict with the first action. A group's behavior (its culture as well as its practices) is defined by the accumulation of these dilemmas and how they tend to resolve them. It may sound strange, but when you look at these dilemmas together, they seem to exhibit a "fractal" nature in their self-similarity. There is very often (actually almost always) some generic conflict/dilemma that they can be translated to. When this generic conflict is identified and addressed appropriately, it can lead quickly to a coherent and consistent set of actions (including appropriate training, measures, and policies) that will result in the mitigation, if not elimination, of the various individual issues being faced throughout the organization. These various applications of the cloud involve both construction and communication. The different uses imply different starting points for building the cloud. Those approaches are best left for another time (or another venue, like a workshop) so I can write about the other tools in my favorite toolkit. If stuck on the proverbial desert island of facilitation, I think it's obvious that the cloud is the tool I would want to have in my pocket, because at the core of almost any problem or decision (either minute and personal or broad and strategic) that one faces (or that a group faces) is the dilemma of doing one thing or another, pursuing one direction or another, going for D or for D'. The cloud tells you that there really isn't a choice involved at all, it's only a matter of examining the assumptions that make you think there is a choice.
The CRT is a sufficiency-based logic (if..., then...) tool that is used to fully describe an existing situation. Its purpose is to understand (only to the level of detail necessary for the group to achieve consensus) how the various issues and problems they face are related to each other, to their policies, measurements, and practices and to the generic/root/core conflict identified through the process I described in the discussion of the Evaporating Cloud tool. This understanding provides the guidance for developing a solution, as understanding why X leads to an undesirable Y provides guidance for inserting new actions to either replace X or to cause it to result in a favorable Z instead. The structure of a CRT is hard to draw in the text based format of email, but consists of connected clusters of statements associated with the situation. The connections are "if..., then..." or "if...and if...and if..., then..." cause and effect relationships. (Graphically, they are statements connected by arrows. Note that I have included similar diagrams in the descriptions of other tools -- FRT and NBR -- below.) These clusters are strung together as effects become causes of other effects. The CRT usually has at it's base a variant of a generic cloud, and higher up in the tree, most if not all of the subject matter's stake holders' symptoms/problems/issues linked in as effects stemming from stuff the root. As we are discussing facilitation tools here, it should be mentioned that from a group participation point of view, the CRT is better thought of as a communication and clarification tool. Its construction is not really suited for a group activity. It is usually best if it is built by one person, or a very, very small group, familiar with the subject matter on their own, and then presented to the group for scrutiny, clarification, and expansion. An alternative approach to using it is to have the individual members of the group build pieces of a CRT related to their area of expertise, and then use the group presentation and scrutiny to merge the pieces into a whole. Construction of a CRT is best as an individual process, scrutiny and clarification is most effective with group effort and input. A well-built CRT will confirm that your suspect generic conflict (or a modification of it) is indeed at the root of the originally identified problems and it will serve as guidance for developing a new view of future reality (vision) to replace the current. The combination of the core/root/generic conflict and the confirmation of the CRT linking it to the particular range of issues facing the group answers the first question that groups come together to address...WHAT TO CHANGE?
The FRT is similar to the CRT in structure, but with new proposed actions, policies, and behaviors injected into it in order to create a new vision of the future reality of the system. The power of the logical "if-then" construction is that if any one of the lower-level causes are removed or mitigated, everything that is above it is subject to change. If you can develop various "injections" as new causes, then you can, through restatements of the subsequent logic, predict and direct changes to the resultant effects. The classic example of how this sufficiency logic works is: A CRT:
AN FRT:
If any one of the three "ifs" are removed or modified, the "then" may be removed from consideration as a problem. We might choose to develop a system in which fuel and sources of ignition are isolated from one another to prevent fires. Or if the problem is that a fire exists, we may choose to remove the oxygen by covering the fire with water, CO2, or a blanket. These are all possible injections. (If only all the "fire-fighting" we do were so clear cut! But maybe it can be almost so.) Even in more complex real-life issues, a careful analysis of assumptions, which in this kind of construction become more "ifs" arrowed into the "then," which become more possible sources for things to remove by the "injection" of new actions, policies, or behaviors. If the CRT is based in a generic conflict, then the initial injection comes from the "out-of-the-5-sided-box" solution of that conflict -- the idea that stems from addressing questionable assumptions. (If the CRT was developed simply from linking the various undesirable effects (as it used to be done in the process before the discovery of the generic conflict's existence), then the core problem at the base of the CRT might be a single statement in the tree. The best way to deal with that result is to do a cloud on that statement.) The objective of the FRT is to communicate a vision of how to change the undesirable effects found in the CRT to desirable effects. Again, like a CRT, construction is best done by individuals or very small groups, while the most effective use of group interaction (and that gains from experienced facilitation) is in scrutiny, clarification, and completion of the solution. The FRT is the first step to address the second reason for groups to come together, figuring out WHAT TO CHANGE TO.
When a proposal to solve a problem is offered by a member of a group, whether in the form of a seemingly complete FRT or in the form of a standalone idea thrown out on the table, there are frequently concerns or reservations raised on the part of other members of the group. In the lingo of the Thinking Processes, a RESERVATION exists that if we act on an injection in the Future Reality TREE, there will result a BRANCH that leads to an undesirable, NEGATIVE result. Hence, the "Negative Branch Reservation" or NBR. The key to "trimming the negative branch" again lies in the conversion of internalized intuition into logical if-then steps that can be rationally discussed while avoiding the feeling of "constructive criticism" or more blatant "pot-shots" aimed at the proposal. The "if-thens" must link the proposed action with the suspected negative outcome. Then we can again apply assumption searches to the arrows, especially those that are merging arrows, not directly related to the initial proposal, in order to find a new injection - a new arrow that will change the outcome of concern. In the following example, it is determined that by instituting a new policy, we will be able to achieve something good for the organization. We don't really
We may get stuff
In this simple negative branch, it's easy to see that to complete the solution, i.e., to get not only the desired good stuff, but to avoid the possible negative consequences of our action we might want to replace the lack of understanding of the policy with another action involving education and explanation of the purpose of the policy. By doing so, we avoid the possible misinterpretation and subsequent bad stuff. As a standalone tool, the NBR ranks right up there with the Evaporating Cloud in everyday usefulness in basic facilitation. The cloud deals with conflicts and dilemmas and the NBR deals with doubts and concerns. They both aid communication so that the conflict or concern can be effectively and efficiently dealt with. In terms of group accomplishment, the NBRs brought up by group members serve to complete the solution developed in an FRT. It also provides a route to buy-in for participants as their contribution to the solution (in the form of actions required to trim their NBRs) gives them a sense of ownership of (at least part of) the overall solution. Actually, even if starting with a single proposal, the identification and solution of NBRs could result in an FRT built on that proposal as open and unguarded discussion of concerns builds upon it. (Some "system-thinking" aficionados may see similarities to FRTs and NBRs in causal loops. Indeed, complete CRTs and FRTs for complex systems do frequently contain loops of causality. In CRTs, these loops most often serve to perpetuate undesirable stuff. In well-designed FRTs, loops will be consciously looked for and strengthened so that they will contribute to getting more and more of the desired outcomes.) The combination of the FRT and NBRs completes the answer to the group objective of determining TO WHAT TO CHANGE TO.
OK. We have a solution defined in terms of a vision and strategy that should achieve it (the complete FRT, augmented by the results of adding injections to trim NBRs), but we also have a whole pile of stuff blocking us from doing this part or that part of the strategy. Indeed, for some of the things we've identified as injections in the FRT, we may have no idea whatsoever how to make happen. People are great at finding excuses why something can't be done. In more politically correct language, we refer to that skill as identifying obstacles. The Prerequisite Tree (PRT) takes advantage of people's natural propensity and ability to point out why something can't get done. The first step in building a PRT (after identifying the team's ambitious objective) is to collect all the obstacles that the group can come up with. Then each individual identifies an "intermediate objective" (IO) that would overcome or make moot the obstacle they raised. (After all, the person who comes up with an obstacle has the most intuition about what it would take to address it.) Once all the IOs are identified, the obstacles are used to sequence the IOs into a network that becomes the plan to achieve the objective. Team effort is focused appropriately, since the network points the group to start on those IOs that don't depend on others, and only when they are done, they know they can move on to the next because they've overcome an obstacle that was blocking them. A PRT defines what needs to be done (necessity logic) in what order to accomplish the ultimate ambitious objective. This is a painless way of identifying which "bites of the elephant" we'll gnaw on first in our attempt to consume the whole thing. As a group effort, this process benefits (as does the solicitation of NBRs as reasons we shouldn't take a particular path of action) from the diverse and divergent views of the group's members. The more obstacles that are raised, the more complete the implementation plan of HOW TO MAKE THE CHANGE HAPPEN will be, resulting in fewer surprises along the way.
This last tool further supports the need to describe HOW TO MAKE THE CHANGE HAPPEN. Sometimes a plan is developed by a group for other people to use. Sometimes getting from one IO in a PRT to another requires a finer level of detail in terms of action and results. Including the TrT here for completeness of the list of TOC Thinking Processes, it may be a stretch to think of it as a facilitation tool, as it's really a communication and empowerment tool, allowing the recipient of it to follow a path of action with clear understanding of what to expect along the way and why to expect it. It is a simple repetitive sufficiency logic construct that puts the
actions/tasks in context with the objectives. Based on simple, "if-then"
links, the Transition Tree includes the need for action, the action, the
rationale for the action (why we expect the action to provide the desired result), that desired, expected result (or intermediate objective -
IO), and then reason for the next need in a graphical format:
Result
The transition tree includes all the info you need to build a detailed action plan, assess its ability to deliver results, and includes those results to allow development of alternative actions...a real "results-oriented" task list that encourages "empowerment" to offer new solutions. It sure beats a simple "Do this, then do that, then..." list of tasks that we usually get for instructions. Again -- I might not consider it to be a real "facilitation" tool like the others, but I include it to round out the TOC Thinking Processes.
WHAT TO CHANGE (Situation assessment, description of "current reality," and identification of the core problem or conflict and assumptions that sustain it -- diagnosis) Tools: Evaporating Cloud, Generic Cloud Process, and Current Reality Tree to link undesirable effects to root causes or conflicts that are the most efficient/effective things to attack. WHAT TO CHANGE TO (Verbalization of vision/solution and description of strategy to attain the desired state -- prescription, decision making, and solution development) Tools: Evaporating Cloud to identify an out-of-the-box starting point, Future Reality Tree to flesh out the strategy to turn undesirable effects into desirable outcomes, and the Negative Branch Reservation to complete that strategy/vision by adding things needed to avoid unintended negative consequences. HOW TO MAKE THE CHANGE HAPPEN (Development of detailed plans and tactics that will clarify what needs to happen and synchronize the efforts of the group in the implementation of the strategy -- planning, team-building) Tools: Prerequisite Tree to turn obstacles into an implementation plan so that ambitious outcomes can be achieved. The building of a plan as a group, based on individual input of foreseen obstacles, allows the team to become synchronized in its understanding of the task ahead of them and how their parts fit in to the whole. Transition Tree to (when necessary) get into deeper levels of detail for paths of action, relating them to expected outcomes along the way. In addition to this comprehensive and consistent approach to making the right change happen, the use of clouds and NBRs as the starting point for assumption checking, and even the quick-and-dirty building of PRTs for planning become second nature to those that become familiar with the tools. There are a few pages on my web site (http://www.focusedperformance.com) that deal with these tools, but I have a feeling that I'll be replacing some of those web pages with what I've written here, especially for the new information on strategy development through the generic cloud process. Thanks to Heather for inspiring me to put this all together and thanks to any readers who got this far for their patience in what is a very long posting. -- Frank Patrick _________________________________________________________________________
Focused Performance - Management Consulting & Training
"Where self-reliance leads, resilience follows, and where generosity
|