TOC Thinkers

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

Q&A with Bill Dettmer - Q2 - Why the new book?

Q2: Your new book arrived yesterday and since then I've only been able to spend a couple of hours reading through it. It looks good. Can you tell us why you decided to write it?

In 1996, when I wrote Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement, I intended to write the "how-to" for those interested in learning the logical thinking process. Though the first chapter laid the foundation in constraint theory (of which the thinking process was a part), the balance of the book described the "state of the art" in the thinking process at the time. But as with any such book, it could only be a "snapshot in time." The thinking process was not fully matured when I wrote GTOC. I used it as the primary text in my seminars and workshops on the thinking process. But over the next several years, I found that I was having to supplement the original material with newer, improved instructions and explanations in order to see better results from my seminar participants. By 2005, I had a fairly thick three-ring binder that I was distributing with the GTOC text. And I was telling students to disregard certain parts of GTOC and use the material in the binder instead.

In 2006, my publisher, Quality Press, asked me if I would be interested in updating GTOC to a second edition. I saw the opportunity to incorporate a lot of the three-ring binder into the original text, delete the material that I considered no longer relevant, and simplify the learning process. But as I became involved in the modification of the original, I realized that the manuscript was turning into a completely new book. It had substantial overlap with GTOC, but is was different enough that it warranted a change in the title and structure, rather than merely being labeled GTOC, second edition. My later thinking about the thinking process was also strongly influenced by my writing of Strategic Navigation in 2003.

Additionally, the passage of 11 years has afforded me the opportunity to replace outdated examples with newer ones and to improve the quality of the graphics. Ad added benefit (not a rationale for writing a new book in the first place) was the opportunity to include tree-drawing software with it. That wasn't possible when I wrote GTOC.

Q&A with Bill Dettmer - Q3 - Where've the Transition Tree's gone?

Q3: I've always felt guilty for not using the Transition Tree. I tried a few times but it just didn't work for me. I'm relieved to see that you no longer recommend it. Can you tell me a bit your rationale for that?

The original concept of the Transition Tree was to "flesh out" the Prerequisite Tree. As Goldratt originally conceived it, the Prerequisite Tree's purpose was only to identify obstacle to implementation and determine ways to overcome them. But besides overcoming obstacles, there are many more activities that usually take place in most implementations. So Goldratt created the Transition Tree to add all that detail. The repeating-structure nature of the Transition Tree (reality, unfulfilled need, action, leading to new reality) made for some ponderously detailed trees. They also inevitably included detail required to satisfy logical requirements that was obvious to most implementers. Moreover, very few FRT injections requiring Prerequisite Trees involved completely new kinds of creative activities---things that had never been done before. In most cases, overcoming obstacles involved doing things that most professionals already knew how to do. They didn't need the "work-task instruction" detail---and the rationale for why they should do each step.

All this became clear to the students to whom I was teaching the thinking process. As I scrutinized their Prerequisite Trees, I found them including some of these necessary-condition task detail that had no particular obstacle associated with it. But to satisfy the format of the Prerequisite Tree, they were contriving "obstacles that weren't really obstacles" just so they could have an obstacle-IO pair for an activity that they intuitively knew needed to be done. And they were reluctant to replicate all that detail AGAIN in the Transition Tree.

So I bowed to the inevitable---or the practical. I started building (and teaching) Prerequisite Trees that had IOs with no associated obstacles, but there were many more total IOs this way. I concluded that if the "new" Prerequisite Tree included IOs to over come real obstacles, plus IOs that were crucial to successful implementation that did not have an obstacle associated with them, most people could execute the Injection directly from the Prerequisite Tree, without needing a Transition Tree at all. Because my students were almost exclusively professionals, they didn't need a Transition Tree to tell them how to do their jobs, or why. All they needed to know was what to do---and the Prerequisite Tree gave them all of that.

Moreover, there was an additional benefit to a "more robust" Prerequisite Tree. If it included ALL the key tasks and activities that needed to be done to implement an injection, the IOs in total represented all the tasks, in sequence, required to manage implementation as a project---in other words, the activity network that forms the basis for a project schedule. This makes the natural follow-on to a Prerequisite Tree NOT a Transition Tree, but a Critical Chain project network.

However, I should emphasize that the "more robust" Prerequisite Tree approach to project network-building is NOT intended for traditional complex technical project tools. It won't replace a Work Breakdown Structure in a construction or development project, for example. But for organizational change? That's another matter. Most organizational policy change---which is really the purpose of the thinking process in the first place---is not conceived by professional project managers, nor is it managed by people with project management experience. It's usually managed by non-project-oriented people with little or no exposure to Work Breakdown Structures, or any of the traditional project management tools. For such people---at whom the thinking process is primarily aimed--converting the "more robust" Prerequisite Tree into a Critical Chain project network, and managing the change as a project, can be an ideal approach.

Jim Bowles on using clouds to find the core conflict

Unless you participate on one of the main theory of constraints lists then you won't know who Jim Bowles is.  So let me tell you quickly that he is one of the most helpful people I know in the TOC world, he's been around since almost the beginning of the TOC TP and used to teach it until a few years ago when he retired.  He's also the guy who really and truly taught me how to use the TOC Thinking processes. 

A few weeks ago Jim sent me the following note via the cmsig@yahoogroups.com list which was in response to this post on this blog where Bill Dettmer, prolific TOC author, puts his reasons for not using and not recommending what is known as "the 3 cloud method":

Hi Clarke

You wrote: I'll soon be following up with an interview with Bill Dettmer about his new book.

Last week I went on an interesting journey of discovery after I had written my take on Bill Dettmer’s attempts to discredit the cloud method of determining the core conflict. As you know some time ago I started a critique of Bill’s work in his book Strategic Navigation – the case study of Wurtzberg. As I showed you several months ago Bill’s trees do not go down as far as a core problem. They stop at root causes. I think you and others (many of whom I have helped) can confirm that by following Bill’s guidelines you had a very difficult time completing your attempts at a CRT. “I cannot find the core problem” has been a common plea from people who wanted to learn the method.

There are two common failings that I have seen:

1. Not constructing the whole tree. As you have said in your recent writings on software project management you tended to focus on one side of the cloud (that of a developer) – so may I suggest that you may even have ignored or been ignorant about the other side. So in effect what gets constructed is merely a negative branch of the side that you are most familiar with. [Anyone familiar with the full CRT process can spot this a mile away] An injection to break such a branch is merely a “Half-baked solution”.

2. Not diving down deep enough to find the core problem or conflict. Unfortunately all the examples I have seen of Bill’s have this weakness. He only shows root causes. Look at any of his root causes and construct the following sentence. “This (root cause) exists Because……” the answer in every case is a weakness of the system or a failure to manage in a systematic way. You might ask Bill why he is afraid to take his clients to the core problem. The truth of this is already documented in the Goldratt library on “Buy-in”.
If you show someone the core problem leading to all those bad effects – you are in fact finger pointing. And those responsible will not like you for doing so. If you are their consultant you may be afraid that they will kick you out and terminate your contract. Those of us inside the Goldratt Network started to use the cloud more and more to start a presentation to those responsible. This shows the problem in a different light. It is no longer finger pointing in the most critical form that you can have. It acknowledges that the person responsible is in a bind. He is caught between a rock and a hard place. As you now know – for the software project manager it was a case of “look after your team of developers” or “comply with the demands of the hierarchy or clients”. Quite painful at times – forcing you into many compromises.

The cloud method of determining the core conflict overcomes this potentially dangerous step. Why - because we drill down to that deeper cause early on in the process. Bill’s assertion that it is an Intuitive process and so fundamentally flawed is just plain wrong. Even Sir Isaac Newton started with an inductive guess (in the case of social and behavioural research we have little choice). But it doesn’t stop there. Newton taught us how to validate a cause not how to validate an effect or observation. So once we have our speculated cause we have to check that it leads to other (predicted) effects.

So in the three cloud method (I usually get my participants to list more than three) we start with observations that are measureable. We construct the clouds (or tabulate them as I have shown you). We are looking for patterns and from this as you know the core conflict becomes more and more apparent (just as it does from a CRT) –When we were critically scrutinising the Wurtzberg CRT it took me seconds to determine the core problem. “A management failing to manage in a systematic way is the politest I can offer.”

What does Bill’s attempt to discredit the method miss? He misses out on the most important step of all. Once we have determined our core problem or conflict (even if it is done intuitively) we then have to validate that we have indeed found a valid one. We do this by linking it to all the other effects that we have on the table. Once we have what we can now call a “Communication Current Reality tree” we can go out there and check it with measureable data and everyone close to what is really happening.

So please when you speak to Bill ask him sincerely to re-examine his own work. At least he needs to revise or remove Appendix E – which is more about him than it is about the subject matter of the Thinking Processes.

I am truly glad that I took the time and trouble to examine Bill’s false claims. I learned a great deal myself in doing so. I learned that there’s nothing wrong in using inductive methods: sometimes this is the only place we can start. What is wrong is if we rely on our conclusions without validating them with the solidity of deductive methods – but we do this when we use the cloud method. What we should be looking at is a complete cycle of inductive and deductive reasoning. It is too easy to pick off simple examples to show something is flawed but any true student of TOC and in particular the Thinking Processes should be able to show why they are flawed.

I hope this helps in the writing of your book. And that it meets your criteria as something useful to say on TOC.

Regards

Jim Bowles