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
Here's the RSS feed for the yahoo group: http://rss.groups.yahoo.com/group/TOCSoftware/rss
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.
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.
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?
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.
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.
Continue reading "Turning the UDE into a cause-effect-cause 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.
Jim took a look at my last diagram (that started with UDEs 21, 22 and 23) and made some tweaks.
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":
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.
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).
Continue reading "Using the three cloud method to find the core confict" »
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.
