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?

       Implementation is a major topic in The Billion Dollar Solution, it was also the topic of my talk for TOCICO in May entitled “The Art of Change: Making TOC Stick.” There is much more that needs to be said on the subject, so I’ll post some blog entries to go through the basic ideas.
       Implementation planning for a significant new system is complex. You have installation, training, business process changes, and new flows of information. You have significant changes to how people do their work, and these changes must be synchronized; potentially across dozens of functions and thousands of uncooperative people. There is much that can go wrong and much that does.
       Chances are, any critical chain-based implementation process has elements like: 

• Plan the implementation
• Install and configure software
• Give practical training, potentially to many different types of individuals for task, project and portfolio planning and execution
• Provide mentoring, especially for project and functional managers
• Install sustainment processes such as certification, methodology management, and ongoing training 

       All these are valid implementation tasks. These elements form the basis for most implementation plans. But there are a few essential elements that are frequently overlooked.

Urgency

       Murphy’s Law, “If anything can go wrong it will,” may or may not be technically correct. But it is inarguable that if nothing can go wrong, it won’t. That’s the real message: stuff happens. If you want to be sure nothing will go wrong, make sure it can’t.
       Here’s another popular saying: “Never do today what you can do tomorrow.” But the only sure way to ensure something will happen is to do it. Do it now and it gets done; nothing ever gets done tomorrow. So the real message is, “Don’t do what you don’t need to do.” Most people subscribe to this, at least if it’s something they’re not sure they want to do.
       If you try to implement a change without some urgent reason for it to happen now, chances are it won’t happen now and it won’t happen tomorrow. This tends to be true of simple things like diets, exercise and homework; it tends to be even more predictable with organizational change.
       Some basic principles for change were laid out many years ago by the pioneering social psychologist Kurt Lewin: unfreeze, to make people amenable to change; transition, or make the changes; and re-freeze, to make sure the changes stick. Unfreezing can most easily happen through a sense of urgency. There must be some urgent reason to change today or people will prefer to change tomorrow, which means not at all. Dr. John Kotter has written a great deal about urgency and its importance in change (see, for example, his book Leading Change). 

Feedback

       Implementing a significant change for the first time can be like trying to race blindfold on a new track. Racecar drivers go at amazing speeds, but try putting a blindfold on one. Even if it’s not their car, they’re not going to go very quickly. Anyone who is going to have to make changes over time will need a way to see whether or not they’re on course. Over time, people will re-develop their intuition and their ability to evaluate situations quickly and effectively. Until that happens, they will feel like a blindfold driver.
       We must communicate why a change - critical chain or anything else - is creating value. The value we must communicate is value to those making the changes, because they’re the ones who have to keep making them. When they have made the changes we’re looking for, whether we are early or late in the process, they must get feedback that says why the change made sense and continues to make sense. If I say, “Bet on ‘Name That Tune’ in the fifth race tomorrow,” you may do it if you feel like gambling. But if the horse doesn’t win, you’re much less likely to take my next tip. If you don’t even see the outcome of the race, you’ll lose interest. People base future decisions on past experience, and at the beginning of any change they have very little experience. They feel like they’re racing blind, gambling on a tip.
       But feedback alone isn’t enough. The feedback processes must produce corrections. It doesn’t do the race car driver any good to see the road if the car’s controls are locked. It doesn’t do the project manager any good to set task priorities if people aren’t able to work to those priorities. 

Bottom line messages:

1. Find or create urgency to change.

2. Feed the value of the changes back to those whose changes created it.

3. Help people use that information to create more value.

Next up: the vision for change.

On Wednesday, 25 March 2009, I’ll be conducting a webinar for the Theory of Constraints International Certification Organization (TOC-ICO). To find out more, check http://www.tocico.org/i4a/pages/Index.cfm?pageID=3684. I plan on showing how the Cycle of Results can be used to increase the chances of success of your change initiatives.

     I recently received an email advertising a critical chain course. Some key phrases included, “… no the need for massive cultural or behavioral changes… no intensive company-wide education… requires little preparation…” The implication is that implementation is both powerful and easy: a silver bullet.
     Meanwhile, a recent post on a critical chain discussion list opined, “… a typical multiproject implementation doesn’t last more than three years.”
     The statements are closely connected. In fact, a major reason that critical chain implementations aren’t long-lasting is that behavior changes are ignored, education and communication aren’t planned properly, and the up-front preparation is weak. And one reason those things happen is that the critical chain tools themselves are treated as a silver bullet, causing people to ignore important up-front planning.

Cultural or Behavioral Changes

     You can’t get improvements without behavior changes. (D²G²: Do what you Did, Get what you Got.) You can get improvements to small organizations or individual small projects with localized behavior changes. To get lasting improvements across an organization, you need to plan for lasting behavior changes across the organization. 

Education and Communication

     People who are affected by an implementation, even indirectly, need to know what’s going on. Sometimes lack of perceived urgency from the senior levels means people don’t feel a need to keep moving the implementation forward. Sometimes the urgency is there but goes away: once the initial itch is scratched and the problem is no longer the problem, management attention and resources go elsewhere. In either case, the implementation eventually asphyxiates. The urgency isn’t maintained and communicated. And keep in mind that education is one form of communication.
     Here’s an example for a relatively small (200 people) product engineering organization:

Senior person: I need to fix project management soon. Our technology is old and we’re too slow to update it.
Senior team: We’re on board.
Project managers: When do we start?
Individual contributors: No big deal to us, but it would be nice not to have to continue multitasking.

     There was planning, there was buy-in. The senior person was very much behind the effort. Project plans were created and information flows mapped out. Initially, clear benefits were gained but the implementation went very slowly. Eventually, as personnel moved on, the implementation withered; momentum literally took years to rebuild. What happened?
     It turns out, even for this small company, I left off one important group.

 Line management: You want to do what? Things seem fine to me. Why would I care about that?

     Middle management had been around the organization longer than anyone else. They were the ones who really kept things on track - the old, familiar tracks. The communication and education for this group was poorly done; their apathy was never addressed. They constantly created friction, always expressed in a polite or even cheerful manner. 

Planning

     When a small area that achieved success starts to engage in culture wars with the rest of the organization, they lose. I have often seen bands of hardy explorers adopt critical chain tools and - despite great initial successes - gradually lose ground. The only answer I know: plan the implementation and the communication. It’s never too early to start, because the implementation must be sold internally. Put in place early the pieces needed to keep the ground you’ll gain. I’d say this is the biggest problem addressed in The Billion Dollar Solution; look especially in Part III and study the Cycle of Results.
     Bottom line: If you want success, plan. ProChain implementations begin and end with planning. Enjoy your critical chain course, but ask questions and take nothing on faith.

The use of critical chain tools can result in a lot of value, including decreased cycle times, increased efficiency, and increased predictability. Of course, when I say this, people generally want to know: “If it’s so great, why isn’t everyone doing it?”

Those who make important decisions in organizations recognize that real improvements require real changes, and therefore pose real risks. Failure may not be an option, but it happens a lot, and no one wants the short end of that stick. Most people’s experience is that most “improvement” initiatives accomplish somewhere between a little and less than nothing.

That’s why the typical answer is to go slowly: minimize the risks and, consequently, minimize the value. Take baby steps. Focus on more concrete tools, such as software. Avoid tackling behavioral change head-on. Unfortunately, this mindset is self-fulfilling. It validates people’s prior experience, that improvement projects are useless. And this is the key conflict you need to address when promoting any significant improvement process: how can you demonstrably minimize the risks while you maximize the value?

This question is behind everything in The Billion Dollar Solution. The book shows what you must do to minimize the risk of implementing a set of processes like ProChain Project Management - our methodology - while maximizing value. We’ve learned a lot over the years about what does and doesn’t work, we’ve systematized that knowledge, and we’re ready to make it public. I want to provoke awareness and discussion of the key implementation issues that have prevented your organization from managing projects more successfully, and I want to provide practical answers.

Let me know your problems, questions, and comments related to the book, project management, or change management. What do you think? What worked? What didn’t work? What obstacles do you see? I’ll use that as input for this blog.