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
