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.

Here’s a blinding flash of the obvious that you may find useful (I do): an implementation is not a project. Sure, you can (and should) use various project management tools such as schedules and risk management when you’re implementing a new initiative. But here’s the problem: projects are defined as “temporary endeavors” and implementations aren’t. The difference is that some activities in an implementation should never be “done.” At what point should you stop measuring how you’re doing? At what point do you stop communicating expectations and results? These are activities that should continue into the future.

So go ahead and construct your implementation plan, but keep another plan too — your ongoing activities. Call it a “communication plan” or a “sustainment plan.”

This summer, I had my arm twisted to read The Structure of Scientific Revolutions by Thomas Kuhn, a classic (early 60’s) view from a scientific historian on how major changes in scientific thought really occur. Kuhn provides example after example of how science doesn’t work according to the classic “hypothesize - experiment - validate/falsify” model. He believes that scientific revolutions are accepted much more through social processes than scientific ones. In fact, he suggests that sometimes an older generation of scientists needs to die out before newer theories will be accepted.

In case that worries, you, he doesn’t demean the importance of science and he’s hesitant to expand his conclusions to other fields. In fact, he explicitly makes a distinction between science and mathematics. That’s ironic, because years ago I was astonished by a paper from the 70’s, “Social Processes and Proofs of Theorems and Programs” by DeMillo, Lipton and Perlis, that applies similar arguments to mathematics (my first major in college). Ironically, it seems we can’t prove anything without getting a bunch of people to agree to it.

Management theories are typically fuzzy and not amenable to controlled experiments. So if proofs in math and science have a big social component, we shouldn’t be surprised that management theories sometimes seem like conga lines. (And let’s not start on politics or economics.)

How do you make a decision about what management approach to use, if you can’t “prove” that (say) something like critical chain is substantially better than critical path? That’s an especially important question in spaces like project management where many niche players are all trying to win converts. There are a few obvious things to recommend: 

• Listen to the experts, read a lot, but never rely on “expert” opinions as a substitute for thinking.
• Don’t just look for successes and failures, try to understand them, and apply them to your world.
• Experiment. 

Also remember that an inability to “prove” things can be great news: to the extent that we don’t artificially limit ourselves, we can always hope for improvement - personally and professionally. And companies can always hope to build competitive advantages.

At our recent ProChain conference, there were discussions on Critical Chain along with Lean, Six Sigma, Agile, and (!) Earned Value. I think the general consensus was that all these approaches, when thought through and applied intelligently, contain different facets of fundamental truths about good management.

If we think we grasp some of these fundamental truths, this “profound knowledge,” how do we test and enhance our understanding? And how do we communicate it?