TOC Thinkers

Hello TOC World

Can you think?  Can you write?  Do you want to share?

I'm currently setting up a TOC related weblog which anyone in the TOC community can publish to and anyone in the world with internet access can read.  If you are not familiar with blogging then ... ummm ... take a look at my blog www.clarkeching.com and you'll quickly get the idea. 

All you need is (a) the ability to think and write (b) something to say and (c) a desire to share.  The blogging part is easy - send me an email and I will send you a free invite to become an author on the new blog "TOC Thinkers" blog.  It is very easy to use.

Perhaps you've written something in the past that you'd like to share?  Drag it out and I'll publish it for you. Steve - you've written some fantastic stuff, some of which I've already published on my blog; Jean - how about sharing your dissertation with the rest of the world?  Tony - could we republish your classics?  (Some of them got me started in TOC you know); Rob, Larry, Jim, the other Jim, Eli S, Eli G, Dr Stephen P, ... I know you've all got great content that the rest of the world needs to share.

Send me an email if you would like to become an author or if you've got content you'd like to share - clarke.ching@gmail.com.  I'll publish the URL during the next few days.

Please, please, please don't be shy. 
--
Clarke Ching
www.clarkeching.com
+44(0)7920114893

Bill Dettmer on the “3 Cloud Method”

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).

An example of the three cloud method

I'm one of the people that disagrees with Bill Dettmer's (and many others) assessment that the three cloud method for constructing current reality trees and finding the core problem is invalid. I do, of course, respect Bill's opinion and his ever growing body of work immensely – I just don't agree in this particular case.

Before I explain why (in the next blog post I write) here's an example of the 3-cloud method in action which comes from my book. What you are about to read is the fictionalized and sanitized version of the first time I used the approach under the guidance of my TOC mentor Jim Bowles.

You can see more detail of my interactions with Jim on my tocsoftware blog. You'll see what happened before and what happened after. You'll even see the final Currently Reality Tree with the core problem cloud (which my character Steve discovers in the following excerpt) at the bottom of the tree.

Here you go:

Chapter 21 The core conflict?

 

Once Eleanor had left and I had calmed down a little, Craig pulled a large notepad from his briefcase which he put on the table, then he removed a single sheet of paper and passed it to me.

'This table shows the three conflict clouds we constructed together when we first met. I've taken them out of the cloud format and put them in a table format. I want to conduct a little experiment.'

A Objective		B Need			D Want	C Need	D' Want
Deliver a high quality product on time and budget		Prevent Expensive rework late in the project			Developers check in code once it is completely unit tested	Meet their Management Commitments (and avoid punishment)	Developers check in code before it is completely unit tested
An efficient development process		Get feedback as soon as possible (so we can fix defects cheaply and have good visibility)			Start integration testing as soon as possible	Simplify scheduling of the integration of many components	Don't start integration testing until all code is built.
Have a successful project		Deliver a product the customer desires			Allow change	Deliver on time and on budget	Don't allow change.

 

'Steve, can you draw me THE core conflict of software development projects?', he asked, passing me the notepad.

I opened the notepad and turned to a blank page, then I picked up the pen and half-heartedly drew a blank conflict cloud. I placed the nib of the pen in the D box, wrote the letter "D", then took a deep breath and put the pen down. 'Honestly, Craig, I don't know where to start.'

'Good', he said. 'Don't forget this little experiment for at least 15 minutes.'

He cleared his throat. 'Over the years of using clouds we've discovered that they tend to be fractal in nature. The three you constructed are hidden just below the surface of your everyday life. But they are manifestations of another deeper, almost hidden cloud, a root cause conflict, if you like. It's that conflict cloud I want to find now. It's a quick and simple process which is easier to do than to explain.'

He passed me the paper and instructed me to draw a blank conflict cloud in the space underneath. 'Start with A. Now look at all 3 of the objectives in the A column and you'll see they are all somewhat similar. What I want you to do Steve, is to figure out a sentence which generically describes all three.'

I must admit I was skeptical, but I had been all along with Craig's lessons and things had turned out pretty damned good so far, so I gave it a go.

I read the three A entities and decided that "A - Deliver a successful project" seemed to generically describe all three of them. I added that to the A box.

Steve then asked me to do the same with the B box. This was a little trickier. The first two were clearly about delivering high quality software code base, but the 3'rd "Deliver a product the customer desires" was somewhat different. But really, when I stopped thinking too hard about it, all three were about delivering a high quality product – it's just that they're two different types of quality we're talking about. I write "B - Deliver the best product".

Steve then directs me to the C box. It's easier than the last one. I quickly add "C - Deliver on time and on budget" to the diagram. The D box is trickier, but not because I can't see a pattern, rather because it seems to be exactly the same pattern as the B box. After a few moments thought, I realize that the B box is talking about the quality of the product as a whole and the D box is talking about the activities we do to achieve that quality. I write in "D - Do things to ensure we deliver the best product". The D prime box is a no-brainer. I write in "D' – Do things to ensure we deliver on time and on budget".

Steve looked at my cloud and suggested that I change the word of the two D boxes from "Do things to ensure …" to "Focus on …". He said it would make the conflict clearer when reading it out loud. While he was telling me this, I read the cloud out loud then rewrote it on a blank page.

I read through the cloud again. I was totally under-whelmed.

I mean, wasn't it just obvious? Really, everyone knew that this was the big problem we faced in Project management. We had a name for it – the "iron triangle". Everyone knew it. The BD arrow represented the needs of "the business". The CD' arrow represented the needs of the project manager. The tug of war between building the best product and meeting schedule is pervasive. Marketing wants to get as much out of us as they can. We want to give them as little as we can get away with. It's a constant, never ending negotiation.

My contempt must have showed on my face because Craig had a cautious tone to his voice when he asked me, 'What do you think of it?'

'To be frank with you Craig, I could have told you this without going through the fancy process. It is PM101.'

'Oh really? When I'd asked you 15 minutes ago to draw the core conflict of software development projects, you drew a blank.' He made a sweeping gesture towards the cloud.

He had me there. 'Okay. It's just that it is so obvious.'

'That's great Steve. I call, what you are experiencing "The paradox of simplicity". Your brain sees the simplicity of the process and of the end-result and assumes that because it is simple that the result is simplistic, and you therefore undervalue it. You must see this all the time in your industry - where an elegant design is mistaken for a simple one.'

He had a point. I told him about a very clever chap I once worked with who would often present two designs for a solution. The first was the complex design he had when he was half-way through the design process. It always impressed people that he was able to come up with such a complex and complicated solution. Then he'd present the second design, which was based on and functionally equivalent to the first, but much simpler and more elegant. His audience were even more impressed because it was obvious how much skill and effort was required to go from the first design to the second. Yet if he'd only shown them the second, final design then they would have been under-whelmed. Very clever chap.

-oOo-

'To help you overcome the "simplicity paradox" Steve, can you think of another common cloud and just quickly confirm whether or not it matches this pattern.

I quickly recalled a conflict I'd recently noticed in another project. In fact, it happened in most projects when the developers wanted to start coding before the customers and analysts had finished the specifications. I quickly constructed the cloud in my head. Why did the developers want to start coding quickly? Because they were focusing on meeting the schedule. Why did the customers and analysts want to wait? Because they were focusing on getting the product definition as good as possible. It was indeed a more specific instance of the root cause cloud.'

-oOo-

As a final "proof", Craig opened his brief case and with a theatrical flourish pulled a sealed envelope from it. He told me that he had done the same "3 cloud" technique many months ago when he was doing his initial research based on different clouds then put it in a sealed envelope. I opened the envelope and compared his cloud with mine – they had the exact same meaning, if not the exact same words. Bravo!

At that stage, I was intellectually convinced that the root cause conflict was valid, but it took me much longer to become emotionally convinced. It has been several years since this conversation, but I've kept testing and testing the core conflict cloud against reality and it always rings true.

'Okay maestro, what do we do with this cloud then?'

-oOo-

'The first thing we need to do is derive a "core problem" statement from the cloud. The core problem is a statement – a sentence or a few sentences - that summarizes the core conflict cloud.

…

TOC in Color

TOC in Color

by Adail Muniz Retamal © July/2007

Versão em Português

“Just as the transition from black-and-white photography to color is so profound,
the transition from black-and-white modeling to color is an awesome one.”

Coad, Lefebvre, De Luca

The year was 2003. I’ve been researching and practicing Agile software development methodologies since 1999, but since 1992 I’ve been using Object-Oriented Programming in my software development practice. Of course, my natural next step at that early time was to start studying Object-Oriented Analysis and Design techniques to apply a common mindset to the whole development lifecycle. I’ve tried several methodologies, with varying degrees of success and satisfaction.

In 2003 I discovered FDD – Feature Driven Development, a complete Agile methodology for Agile Project Management and software development. FDD is a very clever blend of a solid Object-Oriented Software Engineering method, known as “The Coad Method”, named after Peter Coad, and a successful Project Management practice developed by Jeff De Luca, an Australian Project Manager.

But what FDD has to do with TOC? To me, a lot! First, it was at that very same time that I was presented to TOC by John Mac Felsing, co-author of “A Practical Guide to Feature Driven Development”, the FDD bible. But the point I want to make in this article is related to a technique that, although not mandatory or exclusive in FDD, makes a lot of sense and is extremely helpful: the UML in Color.

Peter Coad was (well, in my opinion still is) a very talented systems modeler, architect and strategist. He developed a couple of object-oriented software development methodologies, including processes, guides and graphical notations, back in the 80’s and 90’s. He also developed CASE (Computer Aided Software Engineering) tools to streamline and automate the modeling activities of a project team. His last and most famous modeling tool is called Together, now a product from Borland, since the acquisition of TogetherSoft (Peter’s company) in 2002.

After decades of modeling experience, in vast different business domains, he was hired in 1997 as the Chief-Architect for a challenging project in Singapore, where he proposed and tested the UML in Color technique. But more than coloring the UML, Coad also proposed the use of archetypes and described their common properties, behaviors and relationships.

After having more experience both with software models and TOC trees, I got the idea to apply the coloring technique to TOC Thinking Processes and, hence, the title “TOC in Color”.

Why use color?

I’ll let Peter and his colleagues answer this question for us. The quotations are from the “Color Book” and the emphasis are mine:

“Black-and-white conveys basic information. Color reaches out and grabs you.”

“In September of 1997, we started building models with four colors of Post-It notes: pink, yellow, green, and blue – one for each archetype. Developers and domain experts new to model building on the team commented a number of times along the way, 'But how could you possibly build effective models without color?' That caught our attention! So we developed this technique in practice, published initial findings, and presented this approach in an OOPSLA ’97 tutorial. As is often the case, practice preceded theory. Seeing these ideas work so well in practice, we began investigating color and why it appears to have such a profound effect on building better models.”

“Color gives us a way to encode additional layers of information. The wise use of color increases the amount of content we can express.”

“More importantly, one can use color to add layers of new content to models. Those layers are visible from a distance, so that ‘big picture’ model content comes across even before one starts reading the details. We call this effect ‘spatial layering;’ it means that a model is capable of delivering an overview and a detailed view all within itself, without needing to break visual context by jumping to some other representation. Color makes spatial layering possible.”

From what I’ve seen in my consultancy practice, when we stick the colorful trees to the wall we can easily see the broad picture, and the team can talk about it with much more confidence.

“The fundamental uses of color in information design are: to label (color as a noun), to measure (color as a quantity), to represent or imitate reality (color as a representation), and to enliven or decorate (color as beauty).”

I’ve been using colors when building TOC trees for all of those reasons:

• To label: each color is a hint to the modeler and to the reader, like an archetype or stereotype (what is the kind of each entity in the diagram). This is a valuable extra information;

• To measure: the colors can convey an idea of importance or priority, as in the case of the root causes and main UDE’s in the CRT (see below); another way that colors help measuring is the visual counting they enable on the spot (e.g., we have 3 pink root causes);

• To imitate reality: enhancing the “tree” analogy, we’ll see that colors try to emulate the leaves, roots and trunks of the trees; we also have the “stop sign”, the injection (medicine in a syringe), etc.;

• To decorate: of course, this comes as a bonus.

How many colors?

“Two or three colors are usually enough; five is too many. Four-color combinations must be selected with great care: nothing looks worse than too many colors, particularly when they lack common elements.” [Hideaki Chijiwa]

Given that 3M’s Post-It notes usually come in 4-color packages (of course, there are the mono-color packages as well), this is usually the maximum amount of colors used in building the models (the trees, in TOC).

Which colors?

“The perceptual-primary system, first proposed by Leonardo da Vinci, defines primary colors as red, yellow, blue, and green. These are the perceptual primaries, those colors that do not appear to have any other color in them.”

“We can mute these colors by adding a little white to them. That makes text placed on those colors much easier to read. So, for the four archetypes, we can use pink, pastel yellow, pastel blue and pastel green.”

This is very important: only use the pastel (light) tones of the colors, not the pure (strong) tones, otherwise your trees will look too much colorful and can irritate the readers!

---

CRT in Color

When constructing a CRT (Current Reality Tree), I use the colors to represent:

• Green: the most visible UDE’s (the leaves of the tree);

• Pink: the root causes (the roots of the tree);

• Yellow: the intermediate UDE’s (the trunk and branches of the tree);

• Blue: rarely used, but if some other information is needed, I use a blue box to show it (some assumption, for example).

The following picture shows a colorful CRT, typical for a software development and maintenance environment.

Notes:

• The trees in this article may not be complete or accurate, for they may lack some thorough analysis with the Categories of Legitimate Reservation (CLR). They are meant for illustration purposes only.

• I used Bill Dettmer’s version of the Thinking Processes, as stated in his book “Breaking the Constraints for World Class Performance”.

Figure 1: A CRT in color (click to see the large version)

We can quickly grasp what are the main UDE’s (the leaves) and root causes (the roots) of this tree. This scheme works very well when building CRT’s with a group of people, using Post-It notes stuck to a flipchart paper. The arrows are drawn on the paper using a permanent marker, after the group reaches a consensus on the cause-effect order.

But how do we know when a particular UDE will be a green, yellow or red one? Granted, we don’t know it beforehand. For that, I use the following process:

1. Initially, write all UDE’s with yellow notes and stick them to the paper.

2. After the logical analysis and group consensus, reorder the notes following the “causes at the bottom, effects at the top” rule, then draw the arrows.

3. For each UDE that doesn’t have any (or significant) arrows pointing to it, copy it in a pink paper and stick it replacing his yellow version. This is a root.

4. For each UDE that doesn’t point to any other UDE, or is pointed to by many other UDE’s, or is a well known situation in the context being analyzed, copy it in a green paper and stick it replacing his yellow version. This is a leaf.

5. If there is any other type of information you want to present together with the CRT (assumptions, comments, etc.), you can use a note of another color, like blue.

---

Clouds in Color

I often draw Evaporating Clouds diagrams directly on the flipchart or whiteboard, without using Post-It notes. However, if someone asks me to use the colorful notes, I would use green for the goal (A), yellow for the necessary conditions (B and C), and pink for the conflicting actions/desires (D and D’). The injections would be written in blue notes. The premises can be written right above or below the arrows, without boxes.

Figure 2: An EC in color (click to see the large version)

---

FRT in Color

For the FRT (Future Reality Tree), the basic color scheme from the CRT is used: pink for root causes, green for leaves, and yellow for the other UDE’s. The main difference here regards the blue color: it’s used to represent the proposed injections and predicted DE’s (Desirable Effects).

The image below shows a proposed FRT for the previous CRT.

Figure 3: An FRT in color (click to see the large version)

When modeling with a software tool (PowerPoint was used to build these diagrams), I distinguish the injections from the predicted DE’s with a different shape of the box (the injections are squared rectangles). With Post-It notes, I write “INJ” at the corner of the blue note to denote an injection.

---

NBR in Color

The NBR (Negative Branch Reservation) tree is actually a complement to an FRT, usually built after someone expresses a potential risk in the proposed solution. Thus, this risk is a “red sign” of warning, and is written in a pink note. The injections, as usual, are blue. I use green to denote a desirable state or effect, and yellow for the other real life facts and states.

Figure 4: An NBR in color (click to see the large version)

---

PRT in Color

The PRT (Pre-Requisite Tree) is treated differently from the previous ones, because it is somewhat different. We basically have obstacles, actions and the objective.

Let’s start with the objective: it’s a lonely blue box at the top (because, usually, it’s an injection from the FRT). An obstacle is drawn as a “Stop sign” (which is a red octagon), thus, it’s pink. The actions (like the “Go” sign), are green.

When constructing a PRT with Post-Its in a group, start by sticking the blue objective/injection at the top of the flipchart paper. Then ask the group for the pink obstacles. Finally, ask for the green actions that will overcome the obstacles. Put the actions in logical and chronological order, draw the connecting arrows and, voilà, you have a portion of a project network to be executed, using Critical Chain Project Management, of course.

The following image shows a PRT for one of the injections at the previous FRT.

Figure 5: A PRT in color (click to see the large version)

---

TT in Color

The TT (Transition Tree) is another way to communicate the proposed plan as in the PRT. The focus of TT is to explain the why, along with what to do. Here I present the same PRT content, now translated into a TT.

As in CRT and FRT, the most visible leaf/objective (desidered state) is written in a green note and put at the top of the paper. The initial conditions, usually UDE’s, are written in pink notes. Then we have a series of trios composed of a state, a need and an action. The intermediate desired states are also written in green notes, the actions (here they are injections) are blue, and the needs are yellow.

Figure 6: A TT in color (click to see the large version)

---

Summary

I hope this brief explanation of how I’ve been using color when constructing TOC trees will help you in your future adventures.

The following table summarizes how the colors are used with each tree.

	Pink	Green	Yellow	Blue
CRT	Root Cause	Main UDE	UDE	Assumption, etc.
EC	D, D’	A	B, C	Injection
FRT	Root Cause	Main DE	DE	Injection
NBR	Risk	DE	Fact, UDE	Action, Injection
PRT	Obstacle	Action	-	Objective/Injection
TT	Initial State	Objective, DE	Need	Action

From my experience, using color in my models, both in software systems and TOC trees, helped me enhancing the thinking process and better communicating with other people. As a consequence, the time and effort required to build the diagrams are shorter, and amazingly, the quality is much higher.

I used PowerPoint to draw the trees in this article, but I know that it is not the best tool for the job. Basically you can use almost any drawing tool available. I’ve also tried Visio, Transformation Logic Tree (TLT) and Flying Logic.

Unfortunately, the last version of TLT I used (Beta 0.8.8) does not yet support colors in the boxes. Thus, I use TLT to draw a tree and then I copy and paste it into PowerPoint, to apply the appropriate colors. It’s not a very efficient job, but I can leave with it while waiting for the color support in TLT.

The Flying Logic tool is very interesting as well. It automatically spreads the entities around the screen and has a very beautiful design. It also offers the possibility to test the logic of the trees.

I thank Peter Coad and his colleagues for creating the UML in Color technique, and I hope many of you in our TOC community will take this seminal work much further than what was presented here.

Now, grab your Post-It notes and start coloring your trees!

---

About the Author

Adail Muniz Retamal is CEO at Heptagon TI Ltda (www.heptagon.com.br), a Brazilian company dedicated to consulting, training, coaching and mentoring in TOC and Agile software development methodologies. He graduated as an Electronics Engineer in 1993, but since 1983 he has been a software developer, analyst, architect, project manager and instructor. He is the founder and moderator of TOC-Brasil, the Brazilian Yahoo group for TOC, and GUFDD, the Brazilian Yahoo group for FDD. Adail can be contacted at "adail at heptagon.com.br".

This article can be copied, translated and published only in its entirety, including this note. The author will appreciate a notification to keep tracking of where it is published.

This article was featured on Goldratt Marketing Group's TOC Update Newsletter of October/2008

Q & A with John Ricketts - author of Reaching The Goal.

I'm looking forward to reading the new TOC book by John Ricketts.  It's called "Reaching The Goal: How Managers Improve a Services Business Using Goldratt's Theory of Constraints".  I would have written that last sentence more elegantly if I'd known how to do a possessive apostrophe when someone's name ends in "s", btw. 

The book won't be released for a few more weeks but you can search inside at Amazon.

In the meantime, John has kindly agreed to answer a few questions about himself and the book. 

Here're the first two questions with more to follow:

Q1: What is your TOC background?

A1: I'm a "Jonah." For the benefit of people new to Theory of Constraints, Jonah is a former professor and consultant in the original TOC novel, The Goal, who teaches the central character, a factory manager, how to solve what appear to be unsolvable problems. As a practical matter, being a Jonah means I've completed TOC training and actively practice it. My involvement with TOC has taken me beyond its usual boundaries, however. I started my career in manufacturing, moved into information technology, and have been in the services field for a long time. So my career has taken me progressively away from the roots of TOC. As anyone who’s tried to apply TOC to services quickly discovers, however, the less a services business is like an industrial firm, the harder the traditional TOC applications are to apply. I was program manager for the introduction of TOC into IBM Global Services, and I remember vividly that it was impossible to make traditional TOC applications work on certain services problems. For instance, TOC does a terrific job of managing inventory in manufacturing and distribution businesses, but in a pure services business, there is no inventory. You can’t buy a haircut off the shelf. Thus, making TOC work in services requires more than a little innovation.

Q2: Can you tell us a little about your new book? Why were you inspired to write it? What's new about it compared to the existing literature? Who'll benefit from reading it?

A2: Reaching the Goal explains how we adapted TOC applications to work in Professional, Scientific, and Technical Services, which is the services sector least like manufacturing and distribution. Of course, it also happens to be the sector where IBM Global Services would be located if it were an independent entity. Fortunately, a lot of what we discovered can be applied in other services sectors. And many product-based businesses are offering services around their products, so interest in services innovations extends beyond just services sectors. Compared to the existing TOC literature, which generally stays pretty close to its roots, this book is almost entirely devoted to TOC for services. I say “almost” because the first section reviews the fundamentals of traditional TOC as well as services. Thus, readers should be able to pick up this book even if they’ve never read anything about TOC or services before. On the other hand, even readers already familiar with TOC or services will find brand new material in the middle section, which covers management of resources, projects, processes, finances, marketing, and sales. The last section covers strategy, change, implementation, and technology for services from a TOC perspective. And there are endnotes throughout so readers can find their way into the existing TOC literature. In other words, anyone wrestling with management challenges will probably find something in this book that makes them go, “Hmmm.”

The Road Less Traveled - by Rukesh

The Road Less Traveled

If the Man(ager) had learnt but one thing from Murphy
That there’s many a slip betwixt the plan and the delivery
Wisely would he have heeded Deming’s advice
And shunned as hell the road leading to noise

Alas! re-planning remained the order of the day
With expediting ‘n’ fire-fighting making heroes fray
But before long arrived Eli on the scene
Called for discerning execution from planning

Many a sacred cow had to be slaughtered
Myths aplenty had to be altered
From local to global was a whole different game
Behold, reality became much easier to tame

Both planning ‘n’ execution got their own prudent rules
The Man(ager) was equipped to play it cool
But if he ever so much as loathed using his brain
Straight into another hell would he plunge again

Such are the ways of this ‘complex’ world
Where ‘simplicity’ calls for relentless thought
Silver-bullet solutions, my friend, will come and go
Only courage to face dilemmas will make you a maestro

- by Rukesh

John Ricketts - on TOC in Marketing and Sales

Q3: Chapter 8 is devoted to using TOC in Marketing and Sales. This is something that fascinates me.  Could you tell me a little more?  Do you use the approaches that Eli Goldratt describes or something different?  Could you give an example?

A3: Keep in mind that my book is about TOC for Services, so the chapter you mention covers marketing and sales in a services context. The TOC principles are the same as what you see in manufacturing and distribution, but because the context is different, there are differences in how those principles are applied. For example, traditional TOC doesn’t use standard product prices because they distort the real contribution each product makes to profit. TOC for Services doesn’t use standard service prices for the precisely the same reason. However, unlike consumers of products, who are often satisfied with a product off the shelf; consumers of services far more often expect their service to be customized. There’s a good reason the barber asks how you want your haircut. Indeed, many contracts in Professional, Scientific, and Technical Services are unique to some degree because no two clients have exactly the same requirements. Of course, those differences affect pricing, segmentation, and business value, which are all integral to effective marketing and sales. Indeed, some services deals that look profitable when based on standard prices, actually turn out to be unprofitable when examined with TOC. Fortunately, TOC can also find highly profitable services deals that look unprofitable when viewed conventionally. Thus, anyone familiar with the traditional TOC approach to marketing and sales will recognize the principles covered in this chapter, but some of the implications will come as a surprise, especially to service providers who currently rely on standard prices.

John Ricketts - on the Thinking Processes in Services

Q4: I notice as I've browsed through your book that you mention conflicts in many places, but I didn't see any clouds. Do you use the Thinking Process? If so did you consciously decide to not show the tools in the book? (Two things about this question: 1) I'm searching inside on Amazon so I may have just not seen any TP tools, and 2) I'm not being critical of you not using the TP tools.)

A4: I’ve often wondered how much readers can glean from Search Inside, and your question indicates that the answer is “quite a bit.” Both of your impressions are correct: Conflict resolution is one of the recurring themes throughout the book, but there are no clouds. For the benefit of readers new to TOC, “evaporating clouds” (also known as Conflict Resolution Diagrams) are a specific way to illustrate conflicts and their resolution. Thinking Process (TP) tools include clouds as well as several other diagrams. Though we did use TP tools, I decided not to show them in the book for several reasons. First, it would have made the book much longer because the target audience includes readers new to TOC, and they wouldn’t comprehend the tools without an explanation. Second, large services businesses are incredibly complicated, so the actual diagrams were too unwieldy to make good illustrations. Finally, unlike TOC applications, which had to be adapted for services, the TP tools work fine as they are. On the other hand, we had to push the TP tools farther than is typical in order to make the applications work in services.  For example, Multi-Project Critical Chain (MPCC) staggers project schedules around availability of the strategic resource, yet in a services business with diverse projects it’s fairly common to have multiple cross-project resource constraints simultaneously. Likewise, both Drum-Buffer-Rope (DBR) and Replenishment manage inventory, but there is no inventory per se in a pure services business. Therefore, we had to push the TP tools pretty hard in order to adapt TOC applications to work in se

John Ricketts - Services and TOC

Q5: What would you say is the most significant difference seasoned practitioners would need to take into account when working in services?

A5: You ask an important question, because services comprise the majority of developed economies, and services are the fastest-growing segment in developing economies. But the answer to your question depends on whether we’re talking about TOC practitioners or services practitioners, which still tend to be different groups. The good news for TOC practitioners is familiar TOC principles do apply in services. The better news is traditional TOC applications work just fine in services that resemble factories and warehouses, such as fast food, pharmacies, dry cleaners, and lawn care. The best news, however, is TOC applications can be adapted to work even in services that do not resemble factories or warehouses, such as Professional, Scientific, and Technical Services.  TOC practitioners need to understand the unique challenges that service providers face in order to appreciate why the adaptations are necessary. And TOC practitioners will notice some new concepts for services enterprises, such as a third class of constraints that is neither internal nor external. On the other hand, services practitioners will find that TOC for Services provides fundamentally different ways to think about services. For instance, the notion that there may be just one constraint that governs what an entire enterprise can produce is as alien in services today as it was in manufacturing and distribution twenty-five years ago. For many services practitioners, however, the biggest hurdle to overcome is the misconception that optimizing every individual part of an enterprise automatically optimizes the enterprise as a whole. It doesn’t. Reaching the Goal addresses this and many other core problems that services practitioners face every day.

John Ricketts - the book

You can read more about John Ricketts' new book Reaching The Goal: How Managers Improve a Services Business Using Goldratt's Theory of Constraints on amazon.com.  You can even browse through sections of the book using the search inside feature.

The book is about to ship.  I'll have a few more questions for John once my copy has arrived.

Q&A with Bill Dettmer - author of "The Logical Thinking Process - A systems approach to complex problem solving"

Bill Dettmer has recently published The Logical Thinking Process - A systems approach to complex problem solving which is a significant update to his earlier text, "Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement" (GTOC).

 

I've learned a lot from Bill's books over the last decade so I'm delighted that he has agreed to answer a few questions here on the tocthinkers.com blog.  I'll post the first three questions shortly and more will follow.  If you got any questions you'd like to ask Bill then please send them on to me and I'll post them to the blog if they seem appropriate.

Q&A with Bill Dettmer - Q1 - who are you?

Q1: Your new book arrived in the post yesterday but before I ask you any questions about the new book could you tell me a little about yourself, in particular, your interest in Theory of Constraints?

I discovered constraint theory in 1992, while I was teaching in the Master of Science in Systems Management program at the University of Southern California. A colleague (fellow professor) had gone to the Goldratt Institute in New Haven, Connecticut, for the Jonah Program, back when it was mostly a DBR course. I was intrigued enough to read The Goal, and I subsequently decided that I would go to AGI for the Jonah Program, too. I was surprised to find when I arrived that the Jonah Program had been completely restructured. The DBR part was out, and the entire course was devoted to the thinking process.

Having come to the theory and tools from an already-established deep involvement in systems approach to management, I immediately recognized the potential of the theory and tools to enhance and support the systems management. So for me, constraint theory has not been the "terminal outcome"---it's been an integral part of a larger concept called "systems thinking." And it's one reason why most of my books have the subtitle "The Systems Approach to..."