Q3: You helped me get to where I am today when you helped refine the amateur TOC analysis which I did for my MBA dissertation and turn it into something that eventually became my book. I don't owe you just a pint for that ... I should probably give you an entire brewery. I know you've helped several others via skype and email ... without giving a way any trade secrets or names ... can you tell us a little about the process you use to do this?
A3a: It occurred to me this morning that it may be worthwhile mentioning a refinement to the TOC Roadmap that I developed whilst helping people like yourself. During the development of the Thinking Processes we had an opportunity to work with many different individuals and groups. We were able to conduct trials of different ways of teaching people how to use the TP based on our experiences of what worked and what didn't. For example I was assigned to work with a group of people from the National Milk Records.
Their organisation had a problem in getting milk samples from different herds around the country to the test laboratories and then getting the results back to the dairy farmers in a timely manner. It was a quality system service that had been developed when the organisation had all been part of The Milk Marketing Board. As an integrated unit they had been able to coordinate and control things that were becoming more difficult as the different parts of the organisation were sold off as private entities.
[Perhaps a good example of Eli's warning about not segmenting resources.]
The lead-times to get results back to the farmers were becoming a major concern. Many results got back within a few days but it was a process with a long tail – some results could take about three weeks. I was instructed to work with this group of twelve people in a new way.
They defined their UDEs and then I took them through what we called a parallel process. Firstly they each constructed a negative branch: building upwards from the UDE. Once each branch had been posted on the wall of the room it was easy for them to see where the links occurred between each branch: they quickly constructed the top of the CRT. But we had learned that drilling down to the core problem often proved difficult for most people. One way was to draw an empty box below the tree that had been constructed and ask them to find a form of wording that created a link between that box and the open ended entries in the top of the tree. [Those entities that people like Bill Dettmer call root causes] This then became a two way process, drilling down by using the structure I described earlier: this entity exists because ….. : Thus completing the sentence intuitively. Or the alternative being to speculate a cause by wording the empty box below and checking, using the "If…. Then" connections between that entity and the open ended entries. By using this approach they were able to complete the CRT in one day. But what about the parallel process part – before they started speculating about the core problem I asked them to return to the UDEs and showed them how to construct a cloud. The advantage of this process is that it helps them see that there are two sides to the problem – one side that they will often see clearly, the other side that is often less obvious. But most importantly of all by converting the cloud into a tree they begin to see links between the two types of logic and it helps to take them to the lower reaches of the CRT. It was during such trials that we found that it was possible to start with the cloud to form the trunk of the CRT. This gave a much clearer picture of the core conflict than we had had previously trying to determine the core problem. In the early stages of the development of the TP we were invited to closely examine trees and clouds. Finding the core problem at a "Vee" connection and tracing the legs of the cloud through the CRT. This was painstaking work but it allowed us to clearly see the link between the two structures reading the CRT using "If – Then" logic one way but then reading it backwards as it were using the necessity logic of the cloud. For example everytime the UDE "due date performance is poor" occurs at the top of a tree it can be traced back to an entity in the lower part of the tree which will show what need (requirement) is being served that results in this UDE. So it became clear that the CRT is an elaboration of the legs of a cloud with the entities and underlying assumptions forming the trees. This led to the development of the n-cloud method (in many cases three are sufficient to construct the core conflict cloud). I have also learned that there are many situations which are so dire that one cloud is sufficient to do a whole TOC analysis from – those situations I call the do or die ones, or choice between life and death but perhaps that is the subject of another question.
But how did I use this knowledge to help people?
Many of the people that I have helped simply couldn't find the core problem/conflict. The processes used for constructing a CRT aren't easy to use to do this if you do not have good intuition of the subject matter and only those at the heart of managing the system will really know the founding assumptions of the system. In cases where the system has matured well beyond that of the founders it can be even more difficult to determine the assumptions that sustain the conflict. But we can help people from the organisation construct the cloud. Once they have that they can ask the right people to help them surface the assumptions that maintain the core conflict.
To assist others I have done a fair amount of exchanges using emails. This is not one of the easiest mediums to use between a tutor and student so I began to experiment with different ways of presenting and exchanging data with them. I found that once we had the UDEs out in the open I could build a table using an Excel Spreadsheet. By taking my students through a sequence of questions (built into the spreadsheet). They listed the opposing actions, the needs that drove those actions, and the common objective of each cloud. But an interesting thing occurred each time I got someone to tabulate their data this way. As they filled in the columns the core conflict seemed to jump out at them. It became easier to determine and validate the core conflict.
All I had to do then was to show them how to convert that generic cloud into the base or trunk of the CRT and connect all the UDEs to the top and you have a first class Communications CRT.
