Bill Dettmer is a hero of mine. I learned much of my early TOC thinking from Bill's early books and I love him for sharing details of how to use the TOC thinking with mere mortals, too cheap to invest in the training like Bill did.
He is currently immersed deep down in the final stages of editing his latest book on the TOC Thinking Processes. Bill described the new book as a "quantum leap forward in the thinking process". I truly can't wait.
In order to help us kick start this blog, Bill has kindly shared one of the appendices from his book. It is the controversial one where he states why he believes the 3-cloud method of constructing Current Reality trees is fundamentally flawed. Funny thing is – a lot of very clever people agree with him; a lot of very clever people don't. It reminds me of the dire straights song which goes "Two men say they're jesus, well one of them must be wrong".
APPENDIX E. THE 3-UDE CLOUD
At some point in your experience with the thinking process, some of you will undoubtedly encounter a way of attacking the problem-solving phase known as the 3-UDE Cloud, or sometimes as the Core Problem Cloud. Some of you reading this book may have elsewhere learned this as the preferred way of doing problem analysis. In both cases, it's worth exploring the differences between the 3-UDE Cloud method and the way described in this book—what I call the modified traditional approach. As the name implies, the traditional approach preceded the 3-UDE Cloud method by about six years.
The Basic Differences
The differences between the two approaches (traditional and 3-UDE Cloud) can be summarized this way:
Traditional
The traditional approach follows the scientific method: identify the problem, develop possible solutions, test the candidates, and select the best one. So, in applying the thinking process to the challenge of problem solving in complex systems, we start with the IO Map to determine the standards of required system performance, then prepare a Current Reality Tree to define the root causes of deviations in real-world performance, resolve any possible change dilemmas with an Evaporating Cloud, and finally move on to the Future Reality Tree to design and logically test the solution.
3-UDE Cloud
The 3-UDE Cloud approach assumes that all system problems are the result of an underlying core conflict. This method seeks to ferret out that conflict first (that is, without actually establishing the causal connections), then uses that conflict to construct a "core" or "communication" Current Reality Tree to show how this conflict leads to the observed systemic undesirable effects.
Why Are There Two Methods?
The astute observer might well ask, "Why are there two methods? Why isn't the traditional approach enough?" It would seem logical to assume that if something is working the way it was intended, it shouldn't need to be changed unless it's found to be deficient. In fact, W. Edwards Deming saved some of his most critical comments for those who tampered with a stable process without proper understanding of what they were doing and why. [2] So it would seem reasonable to ask what was wrong with the traditional approach that caused some people to move away from it.
Since we'd prefer not to speculate or resort to hearsay, its reasonable to look for some kind of documented history. Unfortunately, not much is available in the public domain. It's limited to three sources, a paper in conference proceedings by Button [1], a book published later the same year by Lepore and Cohen [4], and a book by Scheinkopf [5]. We'll examine all three.
Why Replace the Traditional Approach?
Lepore and Cohen don't provide a rationale for jettisoning the traditional method, but Button does.
Experience with CRTs has uncovered two undesirable elements. One is that
the core problem often reflects poorly on management practices. When a CRT
is presented to those responsible for the core problem, this tends to immediately
activate their defense mechanism. Further productive dialogue may be very difficult.
The other is that in my experience, a CRT that is well constructed can take from
5 to 10 hours to develop. Few individuals have the stamina to undertake this effort
on a regular basis. [1:31]
If I interpret this line of reasoning correctly, Button finds two faults with traditional CRTs. The first is that management is frequently too insecure to "swallow the medicine" (that is, bad news that may be their responsibility). The second is that traditional CRTs are "too tough to do" in most people's attention span. In other words, it might actually take up to 10 hours to identify a particularly challenging problem, and complex problems with profound system-level impact should be definable in much less time.
Core Problems and Core Conflicts
Both Button and Lepore and Cohen explain the 3-UDE approach in some detail, though there are some minor procedural differences between the two. (Scheinkopf addresses "communication" Current Reality Trees, but doesn't mention the 3-UDE Cloud idea.) Button's explanation is also more pedagogical while Lepore's and Cohen's is more conceptual. Lepore and Cohen begin with the introduction of something called the core problem cloud. The presumption in their discussion of the CRT [4:124] is that a core problem cloud can be used to explain the existence of the UDEs in a CRT:
One of the popular ways to construct a CRT is to base it on the Core CRT that
is using the core problem cloud. [4:124]
Now we have two apparently different terms: CRT and core CRT. Unfortunately, Lepore and Cohen don't make clear the distinction between the two. They do, however, address the concept of a core problem cloud in some detail. [4:122-124]. According to Lepore and Cohen:
The core problem cloud describes the conflict that prevents us from finding a solution
to the core problem. There are three major types of core problem clouds:
1. Conflict with the "rules" of the system
2. Personal dilemma of the leader
3. Conflict between functions, management levels, or individuals (chronic conflict)
There are a couple of unstated assumptions that require examination, and an interesting implication of Lepore's and Cohen's perspective on systems that follows from it. The first assumption, which I have personally heard Goldratt express, is that conflict underlies all core problems. And the second is that a large majority of a system's undesirable effects (Goldratt has said 70 percent or more) are accounted for by this core problem. The implication for Lepore's and Cohen's system perspective is that all possible conflicts perpetuating core problems are reducible to one of these three categories: rules, personal leadership dilemmas, or functional/management/personal conflict. In other words, no allowance is made for core problems resulting from incomplete knowledge (ignorance of causal connections), insufficient resources, or factors external to the system itself.
The second is even more interesting: that a large majority of a system's undesirable effects result from a core problem. This idea is somewhat easier to accept when we consider that since its inception (and until this second edition), an undesirable effect has been imprecisely defined as just about anything that's happening in your system that you or others don't like. Because that opens the door to virtually everything, it's easy to see how a single core problem might cause a large percentage of UDEs, maybe even a large majority. Lepore and Cohen confirm this:
These UDEs cover a fairly large span; they originate from different sources
and have different "weights." [4:124]
This represents an important and fundamental difference between the modified traditional approach to the thinking process described in this book and the core problem cloud method. The latter suggests that not all UDEs are created equal, and that there are a lot of them in any system. The modified traditional method described in this book suggests that there are relatively few real UDEs in a system, and they are clearly identifiable with respect to the system's goal and critical success factors—of which there are probably no more than three to five. And because each of these critical success factors is, by definition, a necessary condition to attaining the system goal, the absence of any one compromises goal attainment. This makes the few real UDEs any system might experience relatively equal in weight, and not a matter of one person's opinion versus another's.
So, to summarize briefly, the 3-UDE Cloud method, or core problem cloud (as Lepore and Cohen refer to it), is based on the following assumptions:
- UDEs are subjectively determined
- Most system UDEs result from a single core problem
- Conflict underlies all core problems
- Core-problem conflicts fall into only three archetypes (Boy, that sure makes complex problem identification easy!)
On the other hand, the modified traditional approach to the thinking process is based on the following assumptions:
- All UDEs are objectively defined with respect to non-negotiable system-critical success factors (refer to Chapter 3)
- There are relatively few real UDEs in any system
- All UDEs result from a few critical root causes (true core problems are relatively rare)
- Critical root causes are not limited to a few common archetypes ("generic")
Basics of the 3-UDE/Core Problem Cloud
The 3-UDE, or Core Problem, Cloud works essentially like this. First, you identify an UDE pertaining to the system. (Remember, almost anything you don't like can qualify as an UDE.) Then you determine its opposite condition—a corresponding desired effect. Repeat this process two more times, so that you have three UDEs and matching opposite desired effects. These pairs become the conflicting prerequisites in three different Evaporating Clouds. [1, 4]
To construct the rest of the cloud, the usual right-to-left procedure is employed (refer to Chapter 5). In each case, however, the requirements and objective are established by determining the direct and immediate reason for existence—what outcome each conflicting prerequisite (the UDE and the desired effect) is aimed at achieving. The overall objective is then determined as some overarching condition that both requirements are intended to satisfy.
Clearly, the product of this part of the process is three discrete Evaporating Clouds, the only common thread of which may be that they are inherently part of the same larger system. These three clouds are then consolidated into a single "generic" cloud.* [7]
The process of consolidation, as described both by Button and by Lepore and Cohen, is purely inductive in that it attempts to reach a "general rule" conclusion from three component elements. And therein lies one of the logical fallacies with the 3-UDE/Core Problem Cloud method.
Inductive Reasoning
Why is a conclusion arrived at inductively not logically sound? The answer lies in the nature of inductive reasoning itself.
Induction or inductive reasoning, sometimes called inductive logic, is the process of reasoning in which the premises of an argument are believed to support the conclusion but do not ensure it. It's used to ascribe properties or relations to broader types based on tokens (that is, on one or a small number of observations or experiences), or to formulate laws based on limited observations of recurring phenomenal patterns. [3] Basically, it induces the universal from the particular. However, the conclusion is far from certain.
What, then, is the process of "genericizing" three discrete clouds into a single consolidated one, inducing a universal conclusion from particular details? It's inductive reasoning. And why is this a problem? The answer is that conclusions drawn in this manner are usually over-generalizations. Consider, for example:
I always hang pictures on nails; therefore, all pictures hang from nails.
or:
Teenagers are given many speeding tickets; therefore, all teenagers speed. [3]
As mentioned earlier, Lepore and Cohen don't offer any specific examples, only conceptual directions. But Button does. Here's an example of generic cloud elements (in this case, the conflicting prerequisites) induced from particular, specific ones [1]:
Specific cloud #1 = Don't work overtime vs. Work overtime
Specific cloud #2 = Buy a component vs. Make a component
Specific cloud #3 = Build only on demand vs. Build to stock
Generic cloud = Take action for good department performance vs. Take action for good system performance
It's not obvious how any of these components produces its respective conclusion, and in some cases an argument could be made that the conclusion could actually require an opposite component. (for example, taking action for the good of a department might actually require working overtime.) Without beating this particular example to death, the other "UDE Cloud" elements constitute equally weak inductions. [3]
The Fundamental Problem with Inductive Reasoning
Formal logic, as most people learn it, is deductive rather than inductive. Some philosophers claim to have created systems of inductive logic, but it's a matter of some controversy whether a logic of induction is even possible. Karl Popper adamantly maintains that it is not. [6]
In contrast to deductive reasoning, conclusions arrived at by inductive reasoning do not necessarily have the same degree of certainty as the initial premises. For example, a conclusion that all swans are white is false, but may have been thought true in Europe until the settlement of Australia. Inductive arguments are never binding, but they may be cogent (let's not even go into cogency!).
Inductive reasoning is deductively invalid. (An argument in formal logic is valid if, and only if, it's not possible for the premises of the argument to be true while the conclusion is false.) In induction, there are always many conclusions that can reasonably be related to certain premises. Inductions are open; deductions are closed. Here's an example (somewhat ludicrous, perhaps, but the extreme case clearly demonstrates the potential invalidity of inductive reasoning):
A group of men regularly took birth control pills for three years.
None of the men got pregnant.
Therefore, birth control pills are effective at keeping men from getting pregnant. [6:38]
What's the problem with this, logically speaking? It's the proposed conclusion (the "therefore" part)—it's not valid. Because this is not a deductive statement, the conclusion a) doesn't have the same degree of certainty as the two initial premises, and b) it is only one of several possible conclusions that may be drawn. By accident or by design, the risk is higher of drawing an erroneous conclusion with inductive reasoning.
It is possible, however, to derive a true statement using inductive reasoning if you already know the conclusion. (This has implications for what is typically done with the generic cloud later.)
The only way to have an efficient argument by induction is if the known conclusion is true only when an unstated external conclusion (in thinking-process parlance, an additional predicted effect) is also true. That external conclusion has certain criteria to be met in order to be true (separate from the primary conclusion). By substitution of one conclusion for the other, you can inductively find out what evidence you need in order for your induction to be true.
For example, let's say you have a window that opens only one way, but not the other. Assuming that you know that the only way for that to happen is that the hinges are faulty, inductively you can postulate that the only way for that condition to change would be to fix the window (that is, apply oil, or whatever will fix the unstated conclusion). From there on you can successfully build your case. However, if your unstated conclusion is false (which can only be proven by deductive reasoning!), then your whole argument by induction collapses. Thus, ultimately, pure inductive reasoning does not exist. [3]
Transitioning to the CRT
Setting aside for a moment the argument about whether the inductive (generic) cloud is a valid one or not, let's move ahead to what practitioners of the 3-UDE/Core Problem Cloud do with it.
Since one of the underlying assumptions behind the 3-UDE/Core Problem Cloud is that a core conflict underlies all UDEs—in other words, the idea that an ultimate root cause of an UDE might not have a conflict associated with it is excluded—a conflict of some kind, no matter how logically supportable, must be incorporated somewhere in the bottom of the CRT.
The procedure described by both Lepore/Cohen and Button calls for the generic evaporating cloud elements to be rotate 90 degrees counterclockwise, placing the objective of the cloud at the bottom and the conflicting prerequisites at the top. The arrows are then reversed, the wording is modified to support an "if-then" (sufficiency) verbalization, and additional entities (assumptions) are incorporated with ellipses to translate the former generic cloud into the bottom portion of a CRT.*
Additional layers of cause-and-effect are then extrapolated upward from there until broader system-level UDEs are reached. (Remember, though, that consistent with one of the assumptions underlying the3-UDE Cloud method, UDE determination is highly subjective.) [1, 4]
Bottom-Up Versus Top-Down
There's another difference between the traditional CRT approach and the 3-UDE/Core Problem Cloud methods. In the traditional method, the CRT is constructed from the top down, like peeling the layers of an onion. Each lower layer of causality is hypothesized and then checked for validity using the Categories of Legitimate Reservation. This is inherently a deductive process, which is able to establish validity.
The 3-UDE/Core Problem Cloud method, on the other hand, builds upward from the presumed core conflict to the undesirable effects. In other words, it starts from a presumed (not validated by deductive logic) cause to a preconceived conclusion. Now, think back to the preceding discussion on inductive reasoning [3]: Inductions are open; deductions are closed. It is, however, possible to derive a true statement using inductive reasoning if you already know the conclusion...The only way to have an efficient argument by induction is if the known conclusion is true only when an unstated external conclusion is also true...By substitution of one conclusion for the other, you can inductively find out what evidence you need in order for your induction to be true.
There's another way to express this: When you start from a point you arbitrarily determine, build toward a predetermined destination, and know what supporting evidence you need to get there, it's almost amazing how often the cause-and-effect will turn out to be exactly what's needed to reach that destination.
What's more, building upward deliberately excludes the search for additional causes (the fourth of the Categories of Legitimate Reservation)—a pitfall of inductive logic that's avoided with deductive logic.
Why the Change? (Redux)
A substantial percentage of thinking-process users have switched away from a method that is deductive and sound and that separates the resolution of conflict from the logically supportable determination of cause and effect. They've gone instead to a method that muddles the line between problem definition and conflict resolution, that doesn't offer the same degree of logical certainty, and that can't be evaluated for soundness. Why would anyone deliberately choose to do this?
I believe the answer lies in the rationale offered by Button—concern for defensiveness on the part of those in authority and ease of CRT construction.
At about the time the 3-UDE Cloud made its appearance, Goldratt was much involved with the idea of resistance to change. Some thinking-process practitioners observed seemingly irrational behavior by decision makers: in the face of persuasive CRT logic, they denied or ignored the analysis of the identified core problem. Recognizing that presenting the logic in palatable way wasn't the same as constructing it, Goldratt conceived of the idea of a "communication" Current Reality Tree.* In her book, Thinking for a Change, Scheinkopf devotes a whole chapter to the idea.
What if the party to whom you need to communicate the content of the current reality
tree is someone who is, or thinks he is, directly responsible for the environment described
in the current reality tree? How do you go about communicating the issues to him with-
out putting him on the defensive?...The communication current reality tree (CCRT) com-
bines the evaporating cloud with the current reality tree in a way that avoids the defensive
response. [5:235]
In other words, the CCRT is a way of avoiding a negative reaction to "bad news" by a decision maker. But a little farther on, Scheinkopf provides an equally important but conveniently overlooked prescription:
When you begin to create the communication current reality tree, you have already
completed a current reality tree and evaporating cloud. (Emphasis added) [5:235]
This distinction is important, and it's relevant to what apparently happened later. It implies that the use of a CCRT for persuasion does not relieve one of the responsibility to conclude a thorough, deductively logical analysis first by the traditional approach: a CRT followed by an Evaporating Cloud. The use of the CCRT comes afterward, only when the traditional analysis is complete, and only for the purpose of making that analysis persuasive and non-threatening. In a video tape in 1995 (no longer widely available), Goldratt himself confirms this line of thinking.
So the second half of the 3-UDE/Core Problem Cloud method has a firm basis in rationality. As originally conceived, it applied the only aspect of inductive logic that is admitted to be valid: It is, however, possible to derive a true statement using inductive reasoning if you already know the conclusion...[3] The CCRT, as originally conceived, does this, that is, operates from an already known conclusion. The traditional CRT and Evaporating Cloud on which it should be based were developed using sound deductive logic; thus, the conclusion is known in advance. And this is not only okay, it's required for efficient inductive reasoning!
The disconnect came later, when someone decided that the traditional CRT and Evaporating Cloud could be dispensed with. Instead the process could be "short-cut" by inducing a generic cloud from three discrete ones. Then using that generic cloud as the basis for a CCRT would be a good idea. In other words, they eliminated the only thing that made the bottom-to-top logical construction of the CCRT a logically robust process!
From our earlier examination, we know that the 3-UDE Cloud part of this process is fatally flawed because it depends on inductive reasoning for the analysis in the first place, rather than having the induction follow from a verified, validated deductive analysis. Button's second observation above (takes too long and too much effort) provides a clue to why this "shortcut" was adopted. Why would someone seek a shortcut in the first place? Two possible reasons:
- They aren't adept enough at constructing the deductive logic of the CRT to do it any faster. This could be a deficiency in either teaching or just intellectual laziness.
- The traditional method wasn't complete or logically "tight" enough to be easily translatable to the real world by most people—in other words, a deficient method.
The latter difficulty is an acknowledged problem with the original method of constructing a CRT initially taught by the A.Y. Goldratt Institute. I encountered the problem with clients of my own repeatedly over the first six years of applying the thinking process. The CRT was difficult to construct well and expeditiously. But that isn't the case anymore. Readers of this book know that Chapters 3 and 4 explain in detail how to construct a sound, logical CRT by starting with an Intermediate Objective Map first. CRTs may have taken up to 10 hours when Button and others first learned them. There's no reason that most of them should take longer than about four hours now.
Unfortunately, rather than refining and perfecting the traditional method of CRT construction, people looked for an easy way out. And a general deterioration in the quality of CRTs and problem analyses has resulted. Yes, there are those who would say that they have been successful using the 3-UDE/Core Problem Cloud approach. I don't deny this. Rather I would observe that even a blind pig finds an acorn once in a while. Even with a faulty method, some level of success can be expected, though it may not be consistent or always optimal.
Predetermined Causes to Preconceived Problems
How many times have you heard the expression, "When your only tool is a hammer, all problems tend to look like nails"? This is an indication of an insidious trap that many people fall into. Whether your "hammer" is the Theory of Constraints, Six Sigma, Lean, or any number of other worthy methodologies, if you have an emotional or intellectual commitment to it, there is a real risk of partitioning and arranging reality to fit the tool. This is especially true when one assumes that most underlying problems fall into a limited number (say, three) archetypes. [4:122] How easy it becomes to say, "The reason must be this, because it fits our model so nicely!"
Because there is so much "semantic maneuvering room" in the inductive process of 3-UDE/Core Problem Cloud, it's so easy to make the presumed problem fit the details of the situation. And with no provision (or even thought) to validate the induction with deductive verification, the induced conclusion becomes the problem, in spite of the known deficiencies inherent in inductive reasoning. Why bother with a deductive thinking process when you already know what the problem is?
The insidious part of the thinking process is that it can be used to justify the existence of a preconceived cause—if (and only if) the Categories of Legitimate Reservation are not conscientiously applied. All of them, including additional cause. The reason the CLR safeguard against subversion of the thinking process is that they are part of a deductive reasoning routine, not inductive.
Yet in spite of the fallacies of inductive reasoning, the kind of "communication" current reality tree described by Scheinkopf [5:235] makes perfect sense—for presentation and persuasion, but not for logical analysis. Thus, as Scheinkopf recommends, the traditional (deductive) CRT should be the basis for—and the only logical justification for—the inductive "communication" CRT. And the 3-UDE/Core Problem Cloud does no more than exacerbate the inductions in a "communication" CRT.
Summary and Conclusion
As Lepore and Cohen said, the 3-UDE/Core Problem Cloud is one of the popular ways of constructing a CRT. The other one is the traditional method, as originally conceived by Goldratt and modified in this book.
The traditional method:
- Starts with a few objectively determined system-level UDEs
- Is deductive, and therefore its validity is logically verified
- Terminates in a few actionable critical root causes not confined to a few arbitrary archetypes
- Accommodates whatever valid additional causes might occur
The 3-UDE/Core Problem Cloud method:
- Starts with three subjectively chosen random data points (perceived localized UDEs)
- Uses inductive reasoning (less certain, not binding) to generalize (really, speculate—unlike in a traditional CRT, no attempt is made at verification using the CLR) five elements of an Evaporating Cloud
- Uses the inductively developed cloud as a starting point for a cause-effect journey to a predetermined conclusion (subjective system-level UDEs)
- Ignores potential valid additional causes
Of course, you're free to use whichever method you choose. Which one would you choose?
ENDNOTES:
1. Button, Scott. "Genesis of a Communication Current Reality Tree: The Three-Cloud Process," 1999 Constraints Management Symposium Proceedings, APICS, March 22-23, 1999.
2. http://www.qualityamerica.com/knowledgecente/articles/CQEIVH3f.html
3. http://en.wikipedia.org/wiki/Inductive_reasoning
4. Lepore, Domenico, and Oded Cohen. Deming and Goldratt: The Theory of Constraints and the System of Profound Knowledge. Great Barrington, MA: The North River Press, 1999.
5. Scheinkopf, Lisa. Thinking for a Change: Putting the TOC Thinking Processes to Work. Boca Raton, FL: St. Lucie Press, 1999.
6. Stokes, Geoff. Popper: Philosophy, Politics and Scientific Method. Malden, MA: Blackwell Publishers, 1998.
7. Thesaurus.com.: "generic." Roget's New Millennium? Thesaurus, First Edition (v 1.3.1), Lexico Publishing Group, LLC. (http://thesaurus.reference.com/browse/generic) Accessed: November 05, 2006).
