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