I don’t expect to add more posts to this Billion Dollar Solution blog unless I have something specifically relating to The Billion Dollar Solution. In fact, I expect to transfer some of the content of this site to the ProChain site over the next few months.

Thanks for reading, and I hope we’ll continue to hear from you!

Rob Newbold

Multitasking

This just in. Not sure I’d hang it on the wall, but I can’t disagree with the sentiment.

I have recently played with writing a few very short stories that are intended to provoke thought rather than answer questions. Here’s a sample, entitled “Goals.”

_____________________________________

       The potter’s apprentice had spent the entire day working on a particularly difficult technique, without apparent success, and finally cried out in anger. The Master came over to him and said, “Tell me, what is your purpose in learning to be a potter?”
       Despite his frustration, the apprentice barely paused before replying, “The purpose of a potter is to make pots. I would like to make the best pots I possibly can.”
       The Master grunted and said, “Come.” He led the apprentice into the shop where the pots were sold. The shelves were filled with pots – large cooking pots, small eating bowls, pots with covers, pots with beautiful glazes. He pointed to a small bowl and asked, “What is the purpose of this bowl?” The apprentice stared at it for a moment and said, “It could be used for many things – perhaps for people to eat from, or as a place for a beggar to keep his coins.”
       The Master nodded, then pointed to a beautiful bowl with a brilliant glaze. “And this one?” he asked. The apprentice said, “Its beauty uplifts the spirit.”
       As they were talking, a customer came into the shop and bought a cooking pot. While the customer paid, the Master pointed to the cooking pot and asked, “What is the purpose of this pot?”
       The apprentice said, “For the customer, it will be used for cooking. For the potters, it makes money so that we can survive.”
       Again the Master nodded, then asked, “Tell me, what is your purpose in learning to be a potter?”
       The apprentice thought for a while and then replied, “I would like to make the best pots I possibly can, which means making things that are of value to myself and to my customers.”
       The Master pursed his lips and quietly shook his head. After a few moments of thought he said, “Choose the pot in this store that most embodies your purpose as a potter.”
       The apprentice looked around, inspecting the beautiful and the utilitarian, the small and the large, the colorful and the plain. After a time, he selected a small eating dish that was perfectly shaped and exquisitely painted and handed it to the Master. The apprentice said, “This bowl is useful and beautiful. It has value far greater than its size would suggest. This bowl truly embodies the purpose of the potter.”
       The Master nodded and asked, “In making this pot, has the potter achieved more of his purpose?”
       The apprentice said, “Yes, that must surely be so.”
       Taking the bowl in both hands, the Master carefully stretched out his arms and after a brief pause dropped the bowl to the ground, where it broke into many pieces. Ignoring the cry of dismay from the apprentice, the Master softly asked once again, “Tell me, what is your purpose in learning to be a potter?”

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.

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.”

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?

I’d love to expand this into a complete diatribe about multitasking, incorporating also the Mancala Game (see BDS). Maybe one day…

Some of the things that have been happening over the last few months:

• We held our 10th annual Critical Chain conference last week in Philadelphia. With a keynote from Dr. Robert Cialdini (I highly recommend his books Influence and Yes), presentations from Dr. James Holt and Dr. Eric Morfin and from employees of Roche, Intel, Raytheon, and Abbott Labs (among others), I thought it was a great conference. That was borne out by participant feedback. Thanks to all who helped make this such a wonderful event! I can’t wait until next year.
• I recently completed a chapter for a forthcoming TOC Handbook from McGraw-Hill edited by Jim Cox and John Schlier. My chapter is called “Making Change Stick.” In it I’ve expanded on some of the ideas that have appeared here and in The Billion Dollar Solution. Last I heard, there were over forty contributing authors.
• Our Version 10 software is coming along well. It allows some valuable changes to the traditional approach to critical chain scheduling, so stay tuned for more information.
• I’ll be speaking about change management on 18 November at the upcoming Tokyo conference of the Theory of Constraints International Certification Organization (TOCICO), see http://www.tocico.org/i4a/pages/Index.cfm?pageID=3639 for more information.
• I read quite a few books this summer, will comment on a few here.

More soon.

• 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.

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.