Converting UDE 040 into a Cloud.

Over the last few days I've been working, with Jim's help, and attempting to convert each UDE into a TOC cloud.

Jim is currently helping me to review those, but in this note I'm going to demonstrate the process using UDE 040. 

First though, what is a cloud?  It's TOCs way of visually describing a problem, conflict or dilemma.  If you are new to TOC then this might all seem a bit magical until you've seen a few examples or tried it yourself.  So, I recommend you pop along to the  "TOC for Education" website ( http://www.tocforeducation.com/thinkingtools.html ), click "Cloud" on the menu, then follow the presentation.  If little kids can do it ….

Here's a blank cloud:

 

Now, I've drawn lots of clouds previously but I have never tried to convert a UDE into a cloud before, so  I needed Jim's advice.

1.  Jim said to first re-read the UDE then ask "What action do you find yourself complaining about?" then put this in the D box.

UDE 40 is "The software produced often misses many high-priority features that weren't included in the original requirements specification" and it took a while but I decided that we, in the development team, complain because we are often asked to approve change requests. 

So, I put into the D box: "Allow changes to the spec as we learn".

 

2.  Then Jim said to put the answer to "What need is being satisfied by the action in D, or, why do you put up with D?"  into the B box.  

A couple of years ago I probably would have grumpily filled in "To compensate for the customers not knowing what they want", but that's really me guessing at the cause which comes later.  The real reason for allowing change is that we - the project - want to build the best product.  So I put that into the B box.

 

We read this fragment of the cloud as "In order to (B) Deliver the best product we must (D) Allow changes to the spec"

3.  Looking at the D' box, Jim said to put in the answer to "What is the desired, opposite action of D?".  This one's easy.  The opposite of allowing change is "not allowing change".  So I put that in the D' box.

 

As a sanity check I confirm that D and D' are indeed opposites.

4.  The C box is just a little bit trickier.  Jim suggests asking "What need is being satisfied by the action in D', or, what is jeopardised by D?". 

What need is satisfied by not allowing change? 

For some reason, I find this one easier to answer if I ask what is jeopardized by allowing change.  That's easier, our ability to meet our schedule and budget is jeopardized by allowing change.  So I fill in the C box.

 

5. And finally, to fill in the A box we ask "What is the objective achieved by having both B and C?" and this, for me, is to have a successful project.

That is, a successful project both meets it's schedule and budget commitments and delivers the best product.

Here's the complete cloud.

 

Read it through:

"In order to A we must B" and
"In order to A we must C" and
"In order to B we must D" and
"In order to C we must D'" but
"D and D' are in conflict with each other".

What do you think?  Does it make sense?  Do you see the conflict?

Comments

[Richard Zultner]

It is very helpful is you also spell out the necessary assumptions. For example, is the reason you cannot allow changes to the spec because you did not plan for any changes to the spec? If you did, there is no conflict...

[Ian Chaprin]

Good point Richard. In many cases that would be a solution. It's often true that even if we planned for changes in the spec, something new comes up that could not have been anticipated. Another consideration is that every project has limited time and resources that no reasonable amount of planning can overcome. I think your question leads nicely to the next section where the assumptions and external constraints that affect the initial conflict are spelled out in more detail. This can lead to new ideas for solutions, some of which might include planning for changes.