I just read the book WA: Transformation Management by Harmony by Yuji Kishira. It’s about critical chain, but from a Japanese perspective. It has some pretty wacky stuff, but that’s ok: I found it very interesting and entertaining.

For me, the most important idea it contains is in the title: relating the concept of Wa (harmony) to implementations of critical chain (CC) and more broadly — and only by inference – to theory of constraints (TOC). If you think in terms of a vision and a message needed to promote (sell!) an implementation internally, it’s hard to find a simple concept that everyone can grab onto and say, “yes, that helps me, I want it.” An implementation of anything does best long-term if there is value created that everyone can relate to. A major effect of a properly done implementation is a reduction in conflicts and chaos: increased harmony. Therefore “harmony” can be such a value and can form a core part of a vision.

It seems to be effective in Japan. I’m here at the TOC International Certification Organization conference in Japan (I presented on the topic of making CC stick). I talked with Yuji and heard the Japanese Director-General of the Ministry of Land, Infrastructure and Transport speak. The concept of Harmony is a big part of the culture here, and it’s the main emphasis when Japanese people talk about success stories.

Will it play in Peoria? Maybe, if we measure it and talk about it. It’s worth thinking about.

A second interesting point in the book is equating safety time with responsibility. For example: I feel responsible for finishing my task in the time I committed to, so I add safety time. Moving the safety time to the buffers spreads responsibility to the entire project team. You’re not alone, you don’t have to shoulder the on-time burden yourself, you have a team to help. Harmony again.

Want a flavor? Try this:

A Safety Bug Story Episode 1
Episode 2
Episode 3

Pssssht. Happy, happy ending.

Answers to questions from the last post:

1. Since 95% of the benefits come from the most leveraged 1% of the points, the benefit per leverage point (and hence per leverage point minute, since on average the leverage points take similar amounts of time) for these most-leveraged ones is 95/1. Similarly, the benefits per minute for the least leveraged is 5/99. That means the ratio of most to least is 95/1 to 5/99, or 1881 to 1. Work on the leveraged stuff.
2. The analogous 80/20 rule would give us a ratio of 80/20 to 20/80 or 16 to 1.
3. Note that machine A is less productive overall, so we have to factor its defects by that. If x is the total number of widgets produced and y is the total number of defects, Machine A produces .7y/.4x defects per widget and B produces .3y/.6x. Since the x’s and y’s cancel out, the ratio is .7/.4 to .3/.6 or 3.5 to 1.

The question of “leverage” can be tricky. Suppose we take the set of possible places to put one’s attention, calling this the set of possible leverage points. I (and others) have made the claim that typically 95% of the impact is gained by focusing on the best 1% of the possible leverage points (see Project Management in the Fast Lane, p. 140). Intuitively, we assume that this means (on average) a 95-to-1 difference in productivity between time spent on the top 1% and time spent on the rest.

Here’s a puzzler sent to me by my friend Lee Corbin: Taking the point literally, that a total of 95% of the possible benefits can be derived from addressing the top 1% of leverage points, what is the expected productivity ratio between a minute spent on the top 1% of possible leverage points, and a minute spent somewhere in the remaining 99%? Assume that activities are picked at random from those sets, and that on average the individual activities from both sets take similar amounts of time.

Now, using the same assumptions, do the productivity calculation based on the 80/20 rule (80% of the benefits come from 20% of the actions).

Here’s a similar riddle from Lee: Of two machines producing widgets, A and B, Machine A produces 40% of the total widgets but produces 70% of the defects. Suppose we do an experiment, and have Machine A and Machine B each produce one widget. What is the ratio of the probability that Machine A will make a defective widget, to the probability that Machine B will make a defective widget?

Answers next post.

If you’re familiar with critical chain and Theory of Constraints (TOC) literature, you may have noted a number of topics that The Billion Dollar Solution doesn’t bring up, topics that are virtually always included with discussions of critical chain. Let me describe a few such topics and explain why I didn’t include them. 

SEP Terms

Student Syndrome is the tendency of people, notably students, to delay working on things until as close as possible to the time they’re due. Parkinson’s Law states that “work expands so as to fill the time available for its completion.” Both terms are used to demonstrate problems that cause projects to take longer than they need to.

In one of his Hitchhiker’s Guide books, Douglas Adams invented the SEP Field. You can make something invisible by constructing a SEP Field around it, because then it’s Someone Else’s Problem. Parkinson’s Law and Student Syndrome are SEP Terms. We acknowledge that these things are done frequently - by someone else. Lots of people put things off until the last minute or allow their work to use up safety time, but not me. (Or when I do, I have a really good reason, so that doesn’t count.)

SEP Terms can be very descriptive; the problem is that they cause us to think of problems as Someone Else’s. If you teach someone using SEP Terms, you’re likely to get them to agree that people – other people – should change. At best, they’ll become consultants.

I prefer to stick with terms that help people think about what’s happening, and what should happen, in shared terms. Do you and your colleagues multitask? Of course. Do you struggle with due dates and milestones? Probably. Do you feel like your task lists are a train schedule, as opposed to a relay race? Could be. These shared behaviors are easy to acknowledge, and it’s easy to understand why they slow things down. 

The Five Focusing Steps

The Five Focusing Steps of TOC (Identify, Exploit, Subordinate, Elevate, Go back) are fundamental to its scheduling applications. They have great value that many people have demonstrated in many environments. Why aren’t they even mentioned in The Billion Dollar Solution?

There are two reasons. The first is the simplest: they are dealt with well in many other places, including Project Management in the Fast Lane. The second reason is much more important: in my experience, most project organizations have a lot of work to do before they get to the point where the Five Steps (and many associated TOC concepts, like Throughput Pricing) are really helpful. Starting out with the Five Steps would be like teaching someone snowboarding before getting them winter clothing. They will notice that something is missing. (Yes, it is winter here in the Northeast.)

I do discuss the most crucial of the Five Steps, subordination. I don’t go into it a lot because subordination is - drum roll - a SEP Term. (Other people have a subordination problem, I don’t.) In fact, large parts of the book are spent discussing indirect leverage points: the changes needed to policies, procedures, and culture to help people subordinate to the goal of the organization. That’s where most organizations will need to put a lot of effort. For example, many companies have well-developed milestone systems; you won’t get anywhere near the improvements that are possible without changing those systems and the policies, behaviors, and beliefs that support them. There is a low-risk, low-threat approach to understanding why certain policies and behaviors have to change: try piloting critical chain scheduling (or ProChain Project Scheduling), as described in Chapter 17 of The Billion Dollar Solution.