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?
A3: I have to start with a typical TOC facilitators answer – it depends. Let me start with your case. If I remember rightly you asked for people to view your CRT – this then became the subject matter of the TOC Software list – I duly responded and the rest is history as they say. Like many other cases I immediately recognised a problem with your tree. It was impossible to see the core problem and as a result I think you were floundering to identify the core conflict and build the cloud. I think my reaction was something like this, it looks like a plate of spaghetti I cannot get hold of any of the ends. How did I so quickly see why you were having trouble? There were simply too many open ended entries into the tree and no obvious “Vee” connection. Your tree was typical of the many that I had seen that had tried to emulate Bill Dettmer’s examples in his books. Until recently it wasn’t clear to me as to why Bill stopped drilling down the CRT sufficiently to find the core problem – only late last year did I learn that he was reluctant to take a management team to the conclusion that they couldn’t manage properly: Seems to me that this was based on a fear that they would resent him and stop working with him. He had apparently found that he could make good progress with a client by merely working on sufficient root causes. Perhaps he’s much smarter than I am – I must admit that my training and Yorkshire upbringing encourages me to go for the jugular and want to get to the heart of the matter. People may not like me doing so but I wouldn’t feel right if I hadn’t done a proper diagnostic on the problem.
I also assisted another guy who was into software development, but he had tried working with Lisa J. Scheinkopf’s book – again I started with his CRT because he was having trouble identifying the core problem and cloud. Unlike yours his tree was one sided. I immediately saw that what he’d constructed was a negative branch – he was completely ignoring the other side of the cloud. He had nicely connected all the entities relating to the operations but had ignored things from the point of view of their clients – I recognised this from a problem that I had had during my first real project where I followed the TOC Roadmap on my own. I had constructed the CRT but couldn’t see a “Vee” connection. Then it occurred to me that part of the tree was missing: The UDEs had led me nicely through one side of the tree about the operations but to make it complete I had to include something about the organisation itself. If you want more detail on that then you might like to look at my attempt at a book: the Armeg Ltd., example.
So is there a secret recipe I use? I look at the open ended entries and ask some basic questions: is it negative, is it a fact of life, and is it a proper statement. When you have seen a lot of trees produced by others you learn to spot tell tale wordings. But once I have gone through this process I then look at the entries that are negative and form a sentence with their wording – this (entity) exists because ….. And complete the sentence with my best guess – mostly the answers are intuitive. I’ve worked with managers and organisations for sufficient years to have a good bank of causalities. All I have to do then is ask the question of the person I am working with – I gave you an example of this when I critiqued Bill Dettmer’s Wurtzburg example last year.
