TOC 4 Software

Welcome

Hello and welcome to the TOCSoftware blog:  http://clarkeching.blogs.com/tocsoftware/.

This blog has a companion to the Yahoo group  http://finance.groups.yahoo.com/group/TOCSoftware/.

They will be used together to complete a Theory of Constraints analysis of traditional Software devleopment (i.e. waterfall).  The yahoo group will be used for group discussion and this blog will be used as a central repository and archive of the various artifacts (documents and diagrams).

Clarke Ching

 

RSS feed for yahoo group

Here's the RSS feed for the yahoo group: http://rss.groups.yahoo.com/group/TOCSoftware/rss

 

Invites sent

I've sent invites to the cmsig, SellingAgile, ShareholderValue lists and a few special invitees.  Let's see what happens.

I'll wait until tomorrow (Wednesday) morning to post the first stage of the process.

The WhiteBoard 1

These are the UDEs written on yellow stickies and put on our virtual whiteboard.  As I stuck them up I instinctively grouped  - it helped me get my head around things.

 

The process - part 1a - The undesireable effects

Here's the list of undesirable effects I came up with.  I really probably only need 5-7, but I got carried away.  Many of them a related.

Statement	Is it a complete sentence?	Does it exist?	Is it negative?	Do we care about it?
10  Projects often miss their promised deadline.	Y	Y	Y	Y
20  Projects often fail, late in the project, during the integration phase.	Y	Y	Y	Y
30  The software produced contains many features that are never used (45%) , or rarely used (19%)  [Johnson, 2003]	Y	Y	Y	N
40 The software produced often misses many high-priority features that weren’t included in the original requirements specification.	Y	Y	Y	Y
50  Projects often seem to spend 90% of their duration at 90% complete.  Unpredictable	Y	Y	Y	Y
60  Many requirements in the original requirements specification are de-scoped during the project.	Y	Y	Y	Y
70  The change management process (i.e. where changes are assessed then approved or rejected) is time consuming.	Y	Y	Y	Y
80  The relationships between various roles and staff is often stressful (e.g. between customer and developer).	Y	Y	Y	Y
90  Cash flow from the project is delayed until the end of the project.	Y	Y	Y	Y
100  Projects take too long to deliver.	Y	Y	Y	Y
110  Many changes throughout the project are approved, causing rework.	Y	Y	Y	Y
120  Many changes throughout the project are rejected, protecting the schedule but annoying the customer.	Y	Y	Y	Y
130  Relationships between IT and their customer (“The business”) are poor.	Y	Y	Y	Y

Jim took me through this list and together checked that each was a complete sentence, it existed, was negative and we cared about it.

Can I ask each of you to consider each entity and see if you agree with our assessment? 

 

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. 

Turning the UDE into a cause-effect-cause tree

Having converted UDE 40 into a cloud Jim then showed me how to convert the cloud into a fragment of the current reality tree.  You've already seen the current reality tree I ended up with in my dissertaiton - this is similiar, but a fragment.

The top of the tree

Following Jim's process I've now started working on the top of the tree.  Jim suggested picking 1 UDE, or since I had quite a few, a collection of related UDES and mapping out the effects of the UDE(s) and any links between them.

Continue reading "The top of the tree" »

Jim took a look at my last diagram (that started with UDEs 21, 22 and 23) and made some tweaks.

Here are the comments I got from John Sambrook about yesterdays tree.  I've put my initial comments in-line, but this would be an excellent time to get more input especially about 280

 

> Email Address: john_sambrook@yahoo.com
> URL: http://www.common-sense.com
> I'd like to offer some scrutiny, if that's of interest.  It would help if you could number all entities on the tree, instead of just the UDEs. 

[done by Jim]
>
> 1. Cause insufficiency from 10 to [280] "Sometimes project just take too long and are cancelled."
> 2. I guess I have a clarity reservation on "Sometimes projects just take too long and are cancelled as well."  Maybe break it up into "Sometimes projects take too long" leading to the effect that "Sometimes projects are cancelled."

 

 

Yes. I agree.  On reflection 10 obviously doesn't cause 280. 

 

Howabout: IF 10 AND [a differently worded 280] THEN 300.

 

 

 

Any one have any better suggestions for the wording of 280? 

 

 
> 3. Clarity on "Projects are sometimes cancelled late in the project due to insurmountable problems."  In this effect, I'd suggest not saying what this is "due to."  The CRT is supposed to be telling us what causes this.  Having this restated as text in the effect itself is redundant.

Jim did this already!

 
> OK, my build just finished, so I have to get back to work.  I'll offer more scrutiny in the future, if it's helpful.
>
> John
>

I'm trying to convert the cloud for UDE 21 "Many quality problems are not revealed until  the integration phase." and I need some help.

Well it's been an interesting trip so far - for me (and Jim).  I imagine it's been fairly dull for the rest of you.

This entry introduces the "Current Reality Tree":

• The CRT is spread over 5 separate pages.  I'll post each page as a separate blog entry.
• The CRT shows the current reality of the waterfall/critical path environment that I was working in. 
• It links the conflict or core problem (at the bottom) of the tree to the UDEs I started with (several) months ago (at the top). 
• You'll instantly see gaps and have questions, which is good.  Use the yahoo group for discussion. 

BTW: I'll describe how I got here later.  It's feels a bit like (to borrow from Otto Von Bismark) making sausages and laws: it is best not seeing them made.  I could grumble on with a whole list of reasons and excuses why it's been frustrating for me, but it all boils down to a steep learning curve for me.

 

Page one shows conflict at the base of the tree.  I'll explain later how I got to the conflict, but I was pleasantly surprised to see that it's our good old friend the "iron triangle" - the conflict between schedule, scope and budget.  Until I went through the process I steadfastly thought it was something different.

Page 2 shows that even though we try to prevent change, change happens anyway.

Page 3 shows that we try to solve the "manage schedule and budget" side of the tree by having aggressive schedules and that defects and changes result.

Page 4 shows the game that gets played when staff provide estimates and how we often end up with a schedule that has a little, but not much, wriggle room in it.

Page 5 brings it all together.  With the UDEs at the top and feeds coming in from pages 1, 2, 3, and 4. 

Following Jim and Rajeev's comments to the yahoo group, I've updated the visio diagrams.

Here are the 5 new pages:1, 2, 3, 4, & 5.

Several months ago, before I had constructed the communications current reality tree (CCRT) that we've just been looking at, I used the 3 cloud method to create the following core conflict cloud, that you see at the bottom of the CCRT (entities 10, 20, 25, 40, 50).

It took me a long time to come up with the 5-page Communications Current Reality Tree  (CCRT).  Much of that is down to inexperience, confusion, multitasking, holidays, book writing, struggling with visio, long distance learning  ... but mostly inexperience on my part.

This entry, and the few following, summarises the conversation Jim and I had trying to “break” the cloud at the bottom of the CCRT.

1. We started with “The problem” - the conflict at the bottom of the tree - that directly causes all of the UDES in the environment (as shown in the CCRT).

2. Then Jim helped me to surfact the assumptions underlying the arrows in the cloud.

Click the thumbnail for a full size image:

The next step was to turn the "cloud" into the trunk of the tree, which is done by turning it anticlockwise 90 degrees and rewording it.

Now turning to the assumptions surfaced between D and D', we are able to determine a sentence that describes the core problem:

[click on the thumbnail to see a larger image]

[note: small change to wording made 26/10/04]

I defined the core problem as:

We do not have a way of managing projects that allow project managers to make reliable commitments while customers remain flexible with regard to the product specifications.

This might seem intuitively obvious to some (good because it goes part way to confirming it, but I bet you are asking why all the effort for the obvious? The answer is that it wasn't intuitively obvious until I got there - I knew it, though, when I saw it).

It took a bit of work, on Jim's part, to coax this sentence out of me (and a bit of editing since).

Jim got me to think about the conflict from the owner or sponsors point of view (I was looking at it too much from the point of view of someone stuck inside the conflict) and I figured that we’d make the sponsor very, very happy if we could “meet a specific date and allow you to change your mind about features/priority at any time”. It is the absence of a mechanism to do this that is the core problem.

Using this method, the "injection" - i.e. a new action/policy/rule that “breaks” the cloud - is the exact opposite of the core problem.

[note: small wording change made 25/10/04]

i.e. the injection is:

A way of managing projects that allow project managers to make reliable commitments while customers remain flexible with regard to the product specifications.

• Welcome
• RSS feed for yahoo group
• Invites sent
• The WhiteBoard 1
• The process - part 1a - The undesireable effects
• Converting UDE 040 into a Cloud.
• Turning the UDE into a cause-effect-cause tree
• The top of the tree
• A little scrutiny
• John Sambrook's comments
• now I'm having troubles
• Finally ... something to look at.
• Current Reality Tree - page 1
• Current Reality Tree - page 2
• Current Reality Tree - page 3
• Current Reality Tree - page 4
• Current Reality Tree - page 5
• Updated versions of the Current Reality Tree
• Using the three cloud method to find the core confict
• Building the CCRT
• The Bridge I - surfacing the assumptions under "the cloud"
• The Bridge II - turning "the cloud" into the trunk of the tree
• The Bridge III - the core problem emerges
• The Bridge IV - the injection

A little scrutiny

Jim took a look at my last diagram (that started with UDEs 21, 22 and 23) and made some tweaks.

John Sambrook's comments

Here are the comments I got from John Sambrook about yesterdays tree.  I've put my initial comments in-line, but this would be an excellent time to get more input especially about 280

 

> Email Address: john_sambrook@yahoo.com
> URL: http://www.common-sense.com
> I'd like to offer some scrutiny, if that's of interest.  It would help if you could number all entities on the tree, instead of just the UDEs. 

[done by Jim]
>
> 1. Cause insufficiency from 10 to [280] "Sometimes project just take too long and are cancelled."
> 2. I guess I have a clarity reservation on "Sometimes projects just take too long and are cancelled as well."  Maybe break it up into "Sometimes projects take too long" leading to the effect that "Sometimes projects are cancelled."

 

 

Yes. I agree.  On reflection 10 obviously doesn't cause 280. 

 

Howabout: IF 10 AND [a differently worded 280] THEN 300.

 

 

 

Any one have any better suggestions for the wording of 280? 

 

 
> 3. Clarity on "Projects are sometimes cancelled late in the project due to insurmountable problems."  In this effect, I'd suggest not saying what this is "due to."  The CRT is supposed to be telling us what causes this.  Having this restated as text in the effect itself is redundant.

Jim did this already!

 
> OK, my build just finished, so I have to get back to work.  I'll offer more scrutiny in the future, if it's helpful.
>
> John
>

now I'm having troubles

I'm trying to convert the cloud for UDE 21 "Many quality problems are not revealed until  the integration phase." and I need some help.

Finally ... something to look at.

Well it's been an interesting trip so far - for me (and Jim).  I imagine it's been fairly dull for the rest of you.

This entry introduces the "Current Reality Tree":

• The CRT is spread over 5 separate pages.  I'll post each page as a separate blog entry.
• The CRT shows the current reality of the waterfall/critical path environment that I was working in. 
• It links the conflict or core problem (at the bottom) of the tree to the UDEs I started with (several) months ago (at the top). 
• You'll instantly see gaps and have questions, which is good.  Use the yahoo group for discussion. 

BTW: I'll describe how I got here later.  It's feels a bit like (to borrow from Otto Von Bismark) making sausages and laws: it is best not seeing them made.  I could grumble on with a whole list of reasons and excuses why it's been frustrating for me, but it all boils down to a steep learning curve for me.

 

Current Reality Tree - page 1

Page one shows conflict at the base of the tree.  I'll explain later how I got to the conflict, but I was pleasantly surprised to see that it's our good old friend the "iron triangle" - the conflict between schedule, scope and budget.  Until I went through the process I steadfastly thought it was something different.

Current Reality Tree - page 2

Page 2 shows that even though we try to prevent change, change happens anyway.

Current Reality Tree - page 3

Page 3 shows that we try to solve the "manage schedule and budget" side of the tree by having aggressive schedules and that defects and changes result.

Current Reality Tree - page 4

Page 4 shows the game that gets played when staff provide estimates and how we often end up with a schedule that has a little, but not much, wriggle room in it.

Current Reality Tree - page 5

Page 5 brings it all together.  With the UDEs at the top and feeds coming in from pages 1, 2, 3, and 4. 

Updated versions of the Current Reality Tree

Following Jim and Rajeev's comments to the yahoo group, I've updated the visio diagrams.

Here are the 5 new pages:1, 2, 3, 4, & 5.

Using the three cloud method to find the core confict

Several months ago, before I had constructed the communications current reality tree (CCRT) that we've just been looking at, I used the 3 cloud method to create the following core conflict cloud, that you see at the bottom of the CCRT (entities 10, 20, 25, 40, 50).

Building the CCRT

It took me a long time to come up with the 5-page Communications Current Reality Tree  (CCRT).  Much of that is down to inexperience, confusion, multitasking, holidays, book writing, struggling with visio, long distance learning  ... but mostly inexperience on my part.

The Bridge I - surfacing the assumptions under "the cloud"

This entry, and the few following, summarises the conversation Jim and I had trying to “break” the cloud at the bottom of the CCRT.

1. We started with “The problem” - the conflict at the bottom of the tree - that directly causes all of the UDES in the environment (as shown in the CCRT).

2. Then Jim helped me to surfact the assumptions underlying the arrows in the cloud.

Click the thumbnail for a full size image:

The Bridge II - turning "the cloud" into the trunk of the tree

The next step was to turn the "cloud" into the trunk of the tree, which is done by turning it anticlockwise 90 degrees and rewording it.

The Bridge III - the core problem emerges

Now turning to the assumptions surfaced between D and D', we are able to determine a sentence that describes the core problem:

[click on the thumbnail to see a larger image]

[note: small change to wording made 26/10/04]

I defined the core problem as:

We do not have a way of managing projects that allow project managers to make reliable commitments while customers remain flexible with regard to the product specifications.

This might seem intuitively obvious to some (good because it goes part way to confirming it, but I bet you are asking why all the effort for the obvious? The answer is that it wasn't intuitively obvious until I got there - I knew it, though, when I saw it).

It took a bit of work, on Jim's part, to coax this sentence out of me (and a bit of editing since).

Jim got me to think about the conflict from the owner or sponsors point of view (I was looking at it too much from the point of view of someone stuck inside the conflict) and I figured that we’d make the sponsor very, very happy if we could “meet a specific date and allow you to change your mind about features/priority at any time”. It is the absence of a mechanism to do this that is the core problem.

The Bridge IV - the injection

Using this method, the "injection" - i.e. a new action/policy/rule that “breaks” the cloud - is the exact opposite of the core problem.

[note: small wording change made 25/10/04]

i.e. the injection is:

A way of managing projects that allow project managers to make reliable commitments while customers remain flexible with regard to the product specifications.

Summary page

• Welcome
• RSS feed for yahoo group
• Invites sent
• The WhiteBoard 1
• The process - part 1a - The undesireable effects
• Converting UDE 040 into a Cloud.
• Turning the UDE into a cause-effect-cause tree
• The top of the tree
• A little scrutiny
• John Sambrook's comments
• now I'm having troubles
• Finally ... something to look at.
• Current Reality Tree - page 1
• Current Reality Tree - page 2
• Current Reality Tree - page 3
• Current Reality Tree - page 4
• Current Reality Tree - page 5
• Updated versions of the Current Reality Tree
• Using the three cloud method to find the core confict
• Building the CCRT
• The Bridge I - surfacing the assumptions under "the cloud"
• The Bridge II - turning "the cloud" into the trunk of the tree
• The Bridge III - the core problem emerges
• The Bridge IV - the injection