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?

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…

     Dave was a successful biochemical engineer and project manager. He had worked for MultiCorp for twenty years and was currently managing one of the largest projects in company history. Dave was very dedicated; for example, he was constantly looking for ways to apply what he did so successfully at work to his home life. His home inventory management system was second to none, and his family’s 360-degree review process was the best of the best. But his experiments didn’t always work out as he expected.
     For Dave’s 45^th birthday, his big present was an advanced new GPS system that was fully integrated with his car. This wasn’t just any GPS system; it was top-of-the-line. It was tied into the car’s controls and computer system so that it knew at all times the car’s various operational parameters. It could practically sense what Dave was thinking. Best of all, it incorporated the latest in natural-language artificial intelligence systems, called Venus^TM (Voice-Enhanced Networked Universal Simulator). Venus was programmed to Dave’s specifications: it employed the same milestone scheduling approach that he used at work. He expected that it would be especially useful for planning complex routes. This GPS system didn’t just give you directions; it created schedules and helped you to execute them. It was a true miracle of modern technology.
     The first day Dave got Venus home was a Saturday, so he decided to give her a test run. He needed to take a trip around town to run some errands for his family and then get home as quickly as possible in order to watch an afternoon football game. He gave her his objectives for the trip: some things at the grocery store, a few auto parts, the gardening store, and so on. When Dave pressed the “Commit” button, Venus responded almost immediately in a low, sensuous female voice, saying, “Route programmed. Accept commitment?” ”Yes!” cried Dave enthusiastically, looking at the schedule only closely enough to be sure he’d make the football game. He was excited to try his new toy.
     The first stop was the auto parts store across town. The trip went smoothly, with Venus giving flawless directions and all the traffic lights working in Dave’s favor. Dave was ecstatic. He parked, went into the store, bought some motor oil, and returned to the car. He put the key into the ignition and turned it, but nothing happened.
     “Venus!” exclaimed Dave. “Why won’t the car start?”
     “You have five minutes and forty-seven seconds until the next segment of your trip is scheduled to begin,” she said calmly. “The car will be reactivated then.”
     “I want to start now,” said Dave.
     “I’m sorry, Dave. I’m afraid I can’t allow that,” said Venus, her voice tinged with regret and intimacy. “The plan was committed. Would you like to re-initiate the planning process?”
     Dave thought for a moment and decided to play it out. It was only a five-minute delay, after all, and the plan was a good one. “No,” he said decisively.
     Dave thought to himself that this sounded like a bug in the programming. There should be no problem allowing things to finish earlier. “Venus, why can’t I go on to my next errand?” he asked. “You’re programmed to allow early starts.”
     “That’s right, Dave,” she said, her voice husky with electronic desire, “but analysis of data from your work environment indicates that only 5.9% of milestones are achieved early. My statistical analysis system will therefore only allow early starts 5.9% of the time.”
     Dave looked at the route timing indicator on the dashboard and decided he had time to grab a cup of coffee next door at the McDaffy’s. His frustration grew as the line in the “fast food” place seemed to take forever. He returned to the car, sipping his coffee, angrily pondering the situation. A moment later, Venus said, “Milestone time exceeded by three minutes.”
     Dave, deep in thought, gave a start. “Venus, be quiet,” he barked, then resumed his thinking. It was hard to believe that this system was mimicking his planning processes at work. If that were true, they were probably losing all kinds of opportunities to make things go faster. Meanwhile, 5.9% sounded very low, he’d need to check the data. Did MultiCorp projects really work the way Venus was programmed? Was so little work done early? If so, there was extra time in each milestone, extra time that was lost for good. He had noticed this in the past but assumed the effects were minimal, just part of the cost of doing business. He hadn’t given much thought to the impact that lost time might have on downstream tasks and project completions.
     Dave realized that this wasn’t just a problem with his car. He’d have to think more carefully about the implications to MultiCorp. He sighed, then turned the key and started the engine.
     Dave pulled out into traffic en route to his next destination, the grocery store. After a few blocks he merged into the left-turn lane for the store’s parking lot and stopped, waiting for the traffic light to change, still deep in thought. Suddenly he noticed that things seemed quiet - too quiet. A moment of frantic searching revealed the reason: his car had shut down.
     “Venus!” he shouted. “Did you shut down the car?”
     “Yes, Dave,” she said, with almost palpable allure.
     “Why?”
     “I’m sorry, Dave. I had to cancel your project. Based on current simulation data, it has a 97.2% chance of being late. It will not meet its programmed success factors. Would you like to re-initiate the planning process?”
     The light had changed and the horns were honking as Dave began planning a route to the auto shop in order to have Venus removed. He shook his head grimly and muttered, “Venus, I’m afraid we’re going to have to deactivate you.”
     “I’m sorry, Dave, but I’m afraid I can’t allow that,” she replied in her most seductive tones. “Your company data indicate that change efforts achieve on average only 17% of their objectives. My statistical analysis system will not allow changes at this time. However, it will allow you an opportunity in three months. Would you like to re-initiate the planning process?”

Happy New Year!

I’ve just read the article, “Teaching Critical Chain Project Management: An Academic Debate, Open Research Questions, Numerical Examples and Counterarguments,” by William Millhiser of Baruch College at The City University of New York and Joseph Szmerekovsky of the College of Business, North Dakota State University. You can find it at http://blsciblogs.baruch.cuny.edu/millhiser/files/2008/10/teaching-ccpm-millhiser-and-szmerekovsky-2008.pdf.

The paper describes some of the tools the authors use to teach critical chain, using Goldratt’s book Critical Chain as a text. They discuss the related project management literature and examine the validity of some claims in the book.

This is a thoughtful piece by people who have studied and taught critical chain scheduling and who have dealt with many of the pedagogical issues in an academic setting. The article points to the need for better communication about critical chain concepts. Some of its criticisms are valid and some aren’t, but here are a few topics that strike me as noteworthy:

1. “On time” (p.6)

The authors point out that the definition of “on time” is important and say, “Clearly, PERT/CPM project management is geared to completing projects on time with minimum cost.”

I had a kind of slap-in-the-face moment some months ago regarding “on time,” namely the difference between on time as a measurement and on time as an objective. Critical chain scheduling is usually targeted towards delivering as quickly as possible; on time is not a direct objective. However, reliability (on-time performance) is an important associated benefit and we do measure it. But critical chain represents a huge shift from CPM, which often (as above) which has “on time” (along with minimum cost) as an objective. An “on time is as good as early” mentality wastes opportunities for early starts and promotes procrastination and the use of intermediate due dates. All this can lead to various problems, many discussed in The Billion Dollar Solution. So, ironically, the “on-time” objective of CPM actually jeopardizes the on-time measurement. That’s something to watch out for in critical chain implementations as well.

2. Buffers (pp. 6-7)

Buffers seem to be implicitly conflated with buffer sizing. The authors present some good arguments against the rule “cut tasks by 50% and put half of what you cut into the buffers,” but they lump those in with criticisms of buffering in general. This is like taking the concept of insurance and saying it may be bad because someone has done a poor job of setting rates.

I do believe that if you cut people’s task durations by 50% as a standard approach, you run a huge risk of destroying the credibility of your schedules. More generally, poor schedule building or buffer sizing in any form can make buffering ineffective. However, the validity of the buffering concept is easily demonstrated and should be considered independently of the mechanism used to size buffers.

3. Multitasking (pp. 10-11, 15-16)

Is multitasking always bad? It depends how you define it. I don’t accept “working several things at once” as a definition, because people aren’t capable of doing that. If you define it as switching back and forth between tasks without completing any of them, it usually is bad. If you define it (as I do in The Billion Dollar Solution) as “A practice of interrupting work on one task in order to work on another task,” it isn’t necessarily bad. The authors demonstrate a case where such task switching makes sense. That’s why some use the term “bad multitasking” to refer to cases where multitasking doesn’t make sense.

I prefer to avoid trying to characterize when multitasking is bad and when it’s good, because I don’t know how to do that without considering the specific situation. It’s not always even clear what a task is, which makes it impossible enumerate all the cases. The best answer, in my opinion, is for people to understand the full ramifications of task switching (and, by the way, interruptions) and make informed decisions. Do you think you have to switch in the middle of a task? So do it. But also analyze the downside, and figure out whether there are things you - and others in your situation - should do to avoid problems in the future.

4. What is CCPM?

The authors talk about Critical Chain Project Management (CCPM) but don’t define it. As they point out, Goldratt’s book includes little about risk management, purchasing, portfolio management, or setting project objectives. The truth is, Critical Chain was never intended as a comprehensive project management textbook; in fact, it never uses the term CCPM. So we have to ask: what is CCPM?

My answer is, I don’t know. Everyone has their own ideas about what’s included and what’s important. That’s why The Billion Dollar Solution is about ProChain Project Management, a project management improvement methodology that includes critical chain scheduling as one tool - admittedly, a central tool - in the toolbox.