« January 2004 | Main | March 2004 »
Here's another real life example of a TOC Current Reality Tree that I produced it for an MBA assignment along with a mock memo (in word format) I wrote (as part of the assignment) that explains the tree.
If you study both side-by-side you'll see how they compliment each other when trying communicating the problem. It took me probably 3-4 hours, over 2-3 weeks, of subtle questioning within my team, to get the facts together and link the cause and effect. [IRS in the diagram = FLOP in the memo.]
[read the diagram from the bottom-up and follow your nose].
The root cause - the aggressive schedule - should be a lesson learned for future projects but the current constraint is (a) the lack of credability with the business which is preventing new work and (b) a knowledge bottleneck (all the knowledge is held in the designers head) that makes it very slow to produce any new work.
My first post in this series introduced the following evaporating cloud:
This cloud shows the conflict faced by projects - do we allow changes and keep the customers happy OR do we not allow changes and keep the date and budget? Now I want to talk about how the most common way of producing software - the Waterfall Software Development Lifecycle - try's, but fails, to break the conflict. The essence of the waterfall approach is to "prevent change": thus preventing rework, thus only doing the bare minimum, thus being the most efficient way of producing software. It does this by spending the proper time upfront to get the customer's requirements fully, unambiguously, documented and signed off before starting the design. With change (theoretically) prevented the designers can do the very best design, without interuption, and then hand it over to the programmers, who can too work without interuption. The developers eventually hand over their code to be user acceptance tested by the future users who check that everything they signed-off on all those months ago is complete. Then the software is implemented in one BIG-BANG and everyone lives happily ever after. Unfortunately, there are some unpleasant sideffects - as I've tried to show in page 1 of the "Current Reality Tree" (CRT) below. This CRT is a Theory of Constraints thinking tool that shows the cause and effect at play within my "current reality" - the project I currently work on. It's not, perhaps, the prettiest CRT on earth and I've broken a few of the rules, but it's GOOD ENOUGH for my purposes. Read the tree from the bottom up. The boxes at the tail of an arrow cause the boxes at the head of the arrow. Follow your nose and you'll get the idea. 
In short, there are some pretty icky side-effects of this approach - late integration failure, bloated software being two. But it gets worse. The rationale for the waterfall is that you can prevent change, but you can't, as shown in page 2 of the CRT below. 
Try as you might you can't prevent change. In fact, because the software takes so long to specify and build - and don't forget it's probably about 40% bigger than it needs to be, there's ample time for things to change. So your setup "change control" procedures to eithor approve or reject the change. Since you're working on virtually everything, all at the same time, you can't easily swap functions in the changed function and swap out something else to maintain the same finish date. Instead you slip your promised date, enforce overtime or miraculously absorb the change into your plan. At some stage this "scope creep" results in too much slippage and the product is descoped (triaged is the politically correct term) to bring the dates in. At the end of the day your customers aren't happy with the final product because you've produced bloated software that doesn't suit their needs AND you've probably slipped your schedule a couple of times or more.
[BTW: The seminal waterfall article was written by Winston Royce in this 1970 article. Poor chap Royce since he preferred the iterative/incremental approach, now favoured by the "agile" community, but is labelled as the inventor of the much disliked waterfall].
[updated 12 Feb 06 - removed broken link]
In my previous post I described how projects are stuck in a conflict. We can't both allow change and not allow change. We can't have our cake and eat it too. So what do we do?
In the next post I'll look at how the waterfall lifecycle approach try's - but fails - to resolve this conflict. But first a bit of background about TOC's approach to conflict resolution - the evaporating cloud.
The evaporating cloud has 5 parts as shown below:
Although in text environments such as email it's often written like this:
....D' a prerequisite that conflicts with D'
..B - requirement
A - common objective
..C - requirement
....D' a prerequisite that conflicts with D
Read this: "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".
Also, be wary that D' is sometimes called E and I'm afraid I constantly mix the two.
The cloud's inventor Dr. Eliyahu Goldratt believes that all conflicts can be expressed as a cloud, then resolved by surfacing and challenging the assumptions underling each arrow (i.e. AB, BD, AC, CE and DE) in the cloud.
Dr Goldratt, a physicist, says that conflicts simply don't exist in reality unless we humans make them. He gives the analogy of two scientists both measuring a tree's height. If one says 10 feet tall but the other says 20, they won't compromise on 15 feet. Rather, they would examine their assumptions, calibrate their tools and resolve the conflict scientifically. Goldratt suggests we should do the same with all conflicts. When the conflict is solved the cloud is said to have "evaporated" - hence the name "evaporating cloud".
Evaporating clouds results in win-win solutions. Compromising results in win-lose, lose-win or lose-lose solutions.
Here's an example of technical conflict from a prior post.
