Opinions???
Note the diagrams are off because of proportional font problems in rendering in the bbs software - but the essence is here...
-----snippo-----
Date: Tue, 8 Dec 1998 19:46:29 -0500
From: "Francis S. (Frank) Patrick"
Subject: Re: Problem solving techniques
**** Warning -- Long posting ahead ****
Problems are related to dilemmas, doubts, and decisions. From a "scientific" viewpoint, any problem can be stated in terms of a conflict or conflicts between what are perceived to be necessary conditions of the system that's involved. TRIZ, recently mentioned in this thread, recognizes this in the way with it deals with conflicts between physical or technical aspects between design requirements encountered in the "invention" process. There is also another body of knowledge with a set of tools that are used for problem solving.
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 intuition to a format that can be discussed rationally, questioned without offense, and modified to more fully reflect the understanding of the situation. They are used for the construction of common sense solutions to problems as well as to facilitate communication, collaboration, and consensus among those that must be involved in its resolution.
THE CONTEXT
To put any set of tools in context, they must generally support one of three generic objectives that groups are brought together to accomplish. These three objectives are to determine:
WHAT TO CHANGE
(Situation assessment, description of "current reality," and identification of the core problem or conflict and assumptions that sustain it -- diagnosis)
WHAT TO CHANGE TO
(Verbalization of vision/solution and description of strategy to attain the desired state -- prescription, decision making, and solution development)
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)
Any time a problem is encountered, its solution usually relates 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 TOOLS
Tool 1 -- The Evaporating Cloud
The Evaporating Cloud is a construct of necessity logic that takes the
form:
and is read:
In order to have objective A, we must have requirement B...
In order to have requirement B, we must have prerequisite D...
In order to have objective A, we must have requirement C...
In order to have requirement C, we must have prerequisite D'...
But prerequisites D and D' are in conflict...
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 a number of times in the past in this discussion list, 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 problem solving, 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', even when its as simple as doing something or doing nothing. 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.
Tool 2 -- The Current Reality Tree (CRT)
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 problem solving tools here, it should be mentioned that from a group participation point of view, the CRT is also 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 and clarification. 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 (the Evaporating Cloud) 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?
Tool 3 -- The Future Reality Tree (FRT)
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:
Note the diagrams are off because of proportional font problems in rendering in the bbs software - but the essence is here...
-----snippo-----
Date: Tue, 8 Dec 1998 19:46:29 -0500
From: "Francis S. (Frank) Patrick"
Subject: Re: Problem solving techniques
**** Warning -- Long posting ahead ****
Problems are related to dilemmas, doubts, and decisions. From a "scientific" viewpoint, any problem can be stated in terms of a conflict or conflicts between what are perceived to be necessary conditions of the system that's involved. TRIZ, recently mentioned in this thread, recognizes this in the way with it deals with conflicts between physical or technical aspects between design requirements encountered in the "invention" process. There is also another body of knowledge with a set of tools that are used for problem solving.
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 intuition to a format that can be discussed rationally, questioned without offense, and modified to more fully reflect the understanding of the situation. They are used for the construction of common sense solutions to problems as well as to facilitate communication, collaboration, and consensus among those that must be involved in its resolution.
THE CONTEXT
To put any set of tools in context, they must generally support one of three generic objectives that groups are brought together to accomplish. These three objectives are to determine:
WHAT TO CHANGE
(Situation assessment, description of "current reality," and identification of the core problem or conflict and assumptions that sustain it -- diagnosis)
WHAT TO CHANGE TO
(Verbalization of vision/solution and description of strategy to attain the desired state -- prescription, decision making, and solution development)
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)
Any time a problem is encountered, its solution usually relates 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 TOOLS
Tool 1 -- The Evaporating Cloud
The Evaporating Cloud is a construct of necessity logic that takes the
form:
Code:
B) Requirement <----- D) Prerequisite
/ ^
/ |
v |
A) Objective |/| -- conflict
^ |
\ |
\ v
C) Requirement <----- D') Prerequisite
In order to have objective A, we must have requirement B...
In order to have requirement B, we must have prerequisite D...
In order to have objective A, we must have requirement C...
In order to have requirement C, we must have prerequisite D'...
But prerequisites D and D' are in conflict...
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 a number of times in the past in this discussion list, 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 problem solving, 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', even when its as simple as doing something or doing nothing. 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.
Tool 2 -- The Current Reality Tree (CRT)
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 problem solving tools here, it should be mentioned that from a group participation point of view, the CRT is also 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 and clarification. 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 (the Evaporating Cloud) 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?
Tool 3 -- The Future Reality Tree (FRT)
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:
Code:
A CRT: AN FRT:
I have I don't have
a fire a fire
^ ^
/|\ /|\
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
I have I have I have I have I have I don't have
fuel ignition oxygen fuel ignition oxygen in contact
with the fuel