As you may have heard, we just started a new blog at www.prochain.com/prochain_blog. Both Andreas Scherer and myself will be writing posts. By involving Dr. Scherer and by putting it on the ProChain web site I believe we’ll do a much better job of creating regular posts that are of interest to a large number of readers. I encourage you to check the site frequently.

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

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.

       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.

     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.

Introduction

Nowadays, agile software development techniques routinely bring a number of important benefits to software development organizations. By focusing on frequent iterations (short-term code releases), the cycle time for certain key aspects of development is shortened. This shortens distance between developers, who are creating code and features (along with bugs); and customers, who need working applications to solve real-world problems.[1] Rapid communication (e.g. through co-location) allows faster responses to changing situations. Intermediate releases can even be delivered to customers to provide critical features more quickly.[2]

Some say that agile is fundamentally at odds with critical chain scheduling because they incorporate fundamentally different approaches to planning. With agile, the emphasis is on flexibility and - well - agility. Things change. You prioritize features and plan iterations, understanding that plans may shift at any time with shifts in risks, business needs, customer requirements, and technology. With critical chain you create longer-term activity networks that are, typically, resource loaded.

Boehm and Turner[3] make a strong distinction between plan-driven and agile methods. This implies a full-blown conflict: do you plan, or are you agile? The authors present ideas for creating a balance between agility and discipline, which sounds like a good idea but also raises suspicions of compromise. I suggest that the reality is not “either-or.” There are no conflicts between critical chain planning and agile, but there are myths. I’ll talk about a couple of myths and suggest an approach for using critical chain scheduling in an agile world. 

Myths 

Myth: Critical chain is incompatible with fundamental agile principles.

Reality: I like to go back to the agile manifesto, http://agilemanifesto.org/principles.html, to consider this. When I do, I can see only a couple of issues that might cause friction:

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
With critical chain, we do try to make commitments far in advance. However, you can always change tasks and requirements. The schedule is a tool, not a straightjacket. If your long-term commitments need to change, change them. (But I also recommend you define clearly what you mean by “commitment.”)

7. Working software is the primary measure of progress.
This reflects the agile emphasis on customer needs trumping documentation and process. From that perspective, I don’t see a conflict. On the other hand, the real measure of progress - the critical chain and ProChain emphasis - is satisfaction of the most important business needs of the developers’ company, which usually translates to satisfying customer needs. Be careful not to interpret this principle to mean, “more working software = more progress.”

Myth: Critical chain implies that you have to plan each iteration in detail, far to the future.[4]

Reality: This isn’t a real requirement. The critical chain schedule provides the longer-term picture; detail comes from shorter-term iterations. As you complete features and higher-level tasks via iterations, as customer needs shift, the critical chain schedule is updated accordingly. When you first start work to construct a critical chain schedule for a release, you may not know all the requirements in detail. That shouldn’t be a problem; in the worst case, you can add very high-level tasks to the schedule to estimate the work and fill out the detail later. You may also find it difficult to make iterations work with a critical chain schedule unless the iteration plan is kept separate from the schedule. Again, that shouldn’t be a problem, as long as both provide credible information.

It could be useful to go the other way and look at critical chain principles relative to agile. But the truth is, I don’t see any conflicts between agile and the six principles discussed in The Billion Dollar Solution (Ownership, Leverage, Priorities, Status, Planning, and Uncertainty). 

When and How to Use Critical Chain with Agile

Let’s be more concrete and talk about when and how to use critical chain with software development. We should recognize that it’s hard to give a detailed prescription, because there are many variations of agile and there are many types of software development projects.[5]

To start, if you don’t have (or want) a well-developed agile methodology, I would recommend critical chain (and, of course, ProChain Project Management), for the kinds of reasons discussed in The Billion Dollar Solution. If you already use agile, critical chain will be valuable for software development projects if you need any of the following: 

• A long view of your projects, to reliably predict releases months or years to the future;
• A view of resource loading, both to pace projects and to staff appropriately;
• A means of setting priorities between projects, to reduce churn and multitasking; or
• Transparent, credible communication and discussion of resource needs and release dates.

Regarding “how,” think of the critical chain schedule as the high-level picture that helps predict deliveries, predict resource utilization, and manage cross-project interactions. Think of agile as the lower-level picture that helps make sure the work is managed well and flexibly. To apply critical chain scheduling in an agile world, adapt these kinds of steps: 

1. Set overall release objectives based on business needs and real customer requirements. You may need to plan multiple releases over time.
2. Examine two types of priorities as you review features: priorities based on those business needs, and priorities based on risks.
3. Create a critical chain schedule for at least the critical, required features at a high level, with adequate buffer and approximate resource requirements. In general, schedule the higher-risk features earlier, to give more time to control the risks. New or risky development will require larger buffers.[6] Use focused (not padded) durations for tasks and take into account on-market support and documentation in your overall resource picture.
4. Plan short-term work in more detail, future work in less. Short-term detail can be added to the schedule as time goes by; this is sometimes known as the “rolling wave” approach. For many projects, it won’t be worthwhile to merge the iteration plans with the critical chain schedule. That’s fine, as long as they match approximately and both are reasonably credible. Just make sure both types of plans subordinate to the business priorities.
5. Add lower-priority features to a release only if you’re confident that you’ll still have the time and resources needed for downstream tasks such as testing, bug fixes, user documentation, and so on. This is the same principle as the common agile practice of dropping features for which there’s insufficient time. Testing, so often squeezed between development and release dates, should never be used as a buffer.
6. Look at aggregate resource capacity vs. requirements and pace releases according to global resource availability. 

Key Points 

• Agile and critical chain do not conflict.
• You don’t have to include your detailed iteration planning in your critical chain schedule.
• Testing is not a buffer.
• If you’re going to be agile, it helps to stay flexible in the way you approach scheduling. 

Notes 

[1] This is very much analogous the advantages of shorter batch sizes for manufacturing; see Eliyahu M. Goldratt and Robert E. Fox, The Race (North River Press, Croton-on-Hudson, 1986), see also David J. Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Upper Saddle River, NJ: Prentice Hall, 2004), chap. 23.

[2] For a quick, useful read, see http://www.rocksintogold.com/.

[3] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed (Addison-Wesley: Boston, MA, 2003).

[4] For example: “The underlying assumption [behind critical chain] is you can define all the work and their dependencies. This is counter to the underlying agile assumption that the end state keeps changing.” http://forums.construx.com/forums/t/775.aspx.

[5] And agile projects. For a non-software agile/critical chain case study, check Matt Gelbwaks, “Segway and an Agile Critical Chain,” Cutter IT Journal, March 2003, 24-28, available at http://www.billiondollarsolution.com/downloads/cutter_it_0303.pdf.

[6] Buffer sizing is discussed briefly in The Billion Dollar Solution, I also cite chapter 4 of Anderson’s book. 

Other references:

Frank Patrick has blogged on this topic; see, for example, http://www.focusedperformance.com/2003_06_01_blarch.html#105602920068889601.
Clarke Ching has also written about agile and critical chain; see http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=13948.
And … you’ll also find information on David Anderson’s site, www.agilemanagement.net.

If you’re familiar with critical chain and Theory of Constraints (TOC) literature, you may have noted a number of topics that The Billion Dollar Solution doesn’t bring up, topics that are virtually always included with discussions of critical chain. Let me describe a few such topics and explain why I didn’t include them. 

SEP Terms

Student Syndrome is the tendency of people, notably students, to delay working on things until as close as possible to the time they’re due. Parkinson’s Law states that “work expands so as to fill the time available for its completion.” Both terms are used to demonstrate problems that cause projects to take longer than they need to.

In one of his Hitchhiker’s Guide books, Douglas Adams invented the SEP Field. You can make something invisible by constructing a SEP Field around it, because then it’s Someone Else’s Problem. Parkinson’s Law and Student Syndrome are SEP Terms. We acknowledge that these things are done frequently - by someone else. Lots of people put things off until the last minute or allow their work to use up safety time, but not me. (Or when I do, I have a really good reason, so that doesn’t count.)

SEP Terms can be very descriptive; the problem is that they cause us to think of problems as Someone Else’s. If you teach someone using SEP Terms, you’re likely to get them to agree that people – other people – should change. At best, they’ll become consultants.

I prefer to stick with terms that help people think about what’s happening, and what should happen, in shared terms. Do you and your colleagues multitask? Of course. Do you struggle with due dates and milestones? Probably. Do you feel like your task lists are a train schedule, as opposed to a relay race? Could be. These shared behaviors are easy to acknowledge, and it’s easy to understand why they slow things down. 

The Five Focusing Steps

The Five Focusing Steps of TOC (Identify, Exploit, Subordinate, Elevate, Go back) are fundamental to its scheduling applications. They have great value that many people have demonstrated in many environments. Why aren’t they even mentioned in The Billion Dollar Solution?

There are two reasons. The first is the simplest: they are dealt with well in many other places, including Project Management in the Fast Lane. The second reason is much more important: in my experience, most project organizations have a lot of work to do before they get to the point where the Five Steps (and many associated TOC concepts, like Throughput Pricing) are really helpful. Starting out with the Five Steps would be like teaching someone snowboarding before getting them winter clothing. They will notice that something is missing. (Yes, it is winter here in the Northeast.)

I do discuss the most crucial of the Five Steps, subordination. I don’t go into it a lot because subordination is - drum roll - a SEP Term. (Other people have a subordination problem, I don’t.) In fact, large parts of the book are spent discussing indirect leverage points: the changes needed to policies, procedures, and culture to help people subordinate to the goal of the organization. That’s where most organizations will need to put a lot of effort. For example, many companies have well-developed milestone systems; you won’t get anywhere near the improvements that are possible without changing those systems and the policies, behaviors, and beliefs that support them. There is a low-risk, low-threat approach to understanding why certain policies and behaviors have to change: try piloting critical chain scheduling (or ProChain Project Scheduling), as described in Chapter 17 of The Billion Dollar Solution.

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.