ProChain Press

Multitasking

February 8th, 2010
Multitasking

Multitasking

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

Goals

January 10th, 2010

Happy New Year! I hope 2010 brings you good fortune and great accomplishments.

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

Harmony

November 19th, 2009

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.

An Implementation is Not a Project

November 13th, 2009

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

Social Processes and Improvement

November 8th, 2009

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?

Multitasking Game

October 24th, 2009

Much has been written about the evils of multitasking. If you think multitasking isn’t a big deal, if you don’t see how it affects you, try this multitasking game, similar to the Confetti Factory discussed in the book. This kind of productivity improvement is at the heart of the Billion Dollar Solution. The game hasn’t been tested on all browser types, so let me know how it works on yours. Note: the approach (click-unclick-drag rather than click-drag) is a little odd, do to how Firefox works, but hopefully not too much trouble.

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

Back to Blogging

October 18th, 2009

It has been a while since I’ve written anything here. Lack of focused time is the easy excuse, and there has been a lot going on, but I’ve also felt a need to write everything as an article. I’m going to try being a little less formal and see how that works.

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.

Implementation Planning, Part 1

June 16th, 2009

       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.

Leverage Puzzler Answers

June 3rd, 2009

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.

Leverage Puzzlers

April 26th, 2009

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.