Like all improvements, the concepts of Critical Chain are straightforward. However, just like other breakthroughs, the science behind a concept doesn't automatically deliver its benefits. The results shown in Table 4-1 came from "engineering" the nitty-gritty details of putting Critical Chain concepts into practice. To paraphrase, success was 1 percent science and 99 percent engineering.

Copyright 2010 Realization Technologies, Inc.

TABLE 4-1 Examples of Critical Chain Results The purpose of this chapter is to share how successful adopters have put Critical Chain concepts into practice and achieved durable results. It is based on experience from more than 200 enterprise-level3 implementations of Critical Chain. The range of these includes development of high-tech products; R&D and commercialization of pharmaceuticals; IT applications; design and manufacturing of complex equipment; shipbuilding; building, erection, and commissioning of physical infrastructure; and maintenance, repair, and overhaul of aircraft, submarines, and ships, as well as steel plants and oil refineries.

Starting with a quick recap of Critical Chain, this chapter discusses practical challenges in implementing it successfully. Then, a step-by-step process of implementation is described, followed by an overview of lessons learned over the last 12 years. Finally, before the summary, there are answers to the frequently asked questions that have not been covered in the rest of the chapter.

Recap of Critical Chain

Executing projects is like conducting an orchestra. Various inputs, resources, equipment, decisions and corrective actions have to be brought together at the right place and the right time throughout the life of a project.

Unfortunately, uncertainties get in the way. Tasks take longer, vendors don't deliver on time, technical glitches happen, requirements change and so on. As these uncertainties unfold, even the most carefully prepared plans go awry. Execution priorities become unclear (which tasks to do first) and unsynchronized (every department, every person starts prioritizing their tasks differently). Consequently, a project is mostly waiting for something or the other (see Fig. 4-1). For example: Waiting for resources because they have been assigned to other tasks.

Waiting for specifications, approvals, materials, etc., because the supporting resources that were supposed to supply or obtain them were busy elsewhere.

Waiting for issues to get resolved because experts are firefighting other issues.

Waiting for decisions because managers have too much on their plates.

Waiting for all feeding legs of the project to come together at integration points.

FIGURE 4-1 Time-traps in projects.

As these wait times accumulate, projects become late, firefighting starts, and resources are pulled in multiple directions at once. Priorities keep changing and people are forced to multitask.4 Managers' ability to control outcomes is compromised and they often suffer a near-total loss of control. They cannot predict when a project will finish because holdups keep happening; and they don't know how much capacity is really needed because no matter how many resources they provide, resources are still overloaded while projects continue to run late.

The net impact is that projects take much longer than they should, deliver less scope than originally planned, and are costlier than they need to be. In addition, resources are less productive than they might be.

Critical Chain solves all these problems by synchronizing task priorities within and across projects, and within and across departments. To synchronize, Critical Chain uses three precepts, or Rules: 1. Pipelining: Limit the number of projects in execution at one time.

2. Buffering: Discard local schedules and measurements, and use aggregate buffers5 to protect against uncertainties.

3. Buffer Management: Use buffer consumption to measure Execution, and to drive execution priorities and managerial interventions.

Rule 1 Pipelining: Limit the Number of Projects in Execution at One Time

When too many projects are in execution compared to available capacity-hereafter referred to as high work-in-progress or high WIP-it automatically causes execution priorities to become unsynchronized.

For example, if several projects are simultaneously in execution, different departments might prioritize their work differently. All projects can make some progress but then become stuck at integration points where work-streams from different departments have to come together. Task priorities within departments could also get unsynchronized, in which case even the departmental work-streams would take longer. Unsynchronized priorities also create schedule conflicts, which can cause the individual resources to multitask, which results in lower quality.

If fewer projects are in execution, the chances are much higher that task priorities within and across departments are synchronized. The higher the WIP, the smaller the chances that task priorities will be synchronized!

Therefore, the first rule for execution success is: Limit the number of projects being run at a time. Projects should be staggered based on the most limiting resources because at any time only as many projects can be executed as you can get through those constraints. Any extra projects will only spread resources more thinly and destroy synchronization. Enforce this rule even if it means leaving some resources idle!

Rule 2 Buffering: Discard Local Schedules and Measurements, and Use Aggregate Buffers

The traditional project management approach is to turn task schedules and estimates into commitments. It assumes that if people are held accountable, they will finish individual tasks on time and on budget, and the entire project will consequently be on time and on budget.

Unfortunately, this traditional approach only leads to longer projects while causing execution to become more unsynchronized: In planning, accountability for task-times causes people to include contingencies in their commitments-they have to plan for uncertainties as well as the reality that most of this time will be spent waiting for one thing or another. That is how project plans are extended.

In execution, resources now not only are scattered across too many projects, but also have an incentive to work on easy tasks-tasks that will help them beat or meet their estimates-instead of working on tasks that are most critical to the project.

Therefore, the second rule for execution success comes down to: Allow individual tasks to exceed their planning estimates. To protect projects from task delays, buffers are inserted before integration points and at the end of the project. With lower WIP, with the pressure to meet estimates gone, and with buffers to take care of uncertainties, the contingencies embedded inside task estimates are no longer needed and can be stripped out.

Not only does this second rule allow for shorter project plans (because buffers are smaller than the sum of task-level contingencies), execution becomes easier as well. With shorter project plans there is significantly less pressure to start projects as soon as possible; extra time can be used to get ready for execution through better preparation.

Rule 3 Buffer Management: Use Buffers to Measure Execution, and Drive Execution Priorities and Managerial Interventions

With low WIP and adequately buffered project plans, a single priority system can be firmly established in execution. The essence of the third rule is simple, but profound: Prioritize tasks according to buffer consumption. The highest priority is given to project legs that are consuming buffers at the fastest rate.6 When every person and department follows these priorities, they are all synchronized-automatically!

Buffer-based priorities not only are synchronized, but they also cause project status to be reliable. If resources work on the right tasks at the right time, it is assured that current project status is an accurate predictor of the future-despite uncertainties, most of which can be absorbed into the properly sized buffers. If recovery actions are initiated whenever buffers are showing "over consumed," many abnormal uncertainties can also be combatted.

Practical Challenges in Implementing Critical Chain

Experience shows that no matter what the environment, there are three sets of challenges in realizing the benefits of Critical Chain. These challenges all arise from the fact that Critical Chain is an enterprise solution for synchronizing project execution, rather than a planning and control technique for individual project managers.

Challenge 1: Gaining Managerial Commitment for Implementing the Three Rules

To state the obvious, without managers' commitment it is not possible to activate any new management rules.7 To be clear, commitment is not about managers agreeing with the idea of Critical Chain. It is about them thoroughly thinking through the details of the changes, overcoming the hurdles that will come up, and getting results.

Buy-in needed to gain the commitment: As many would attest, even after managers are trained by experts and even after the method has been successfully piloted on one or two projects, organizations may not undertake a full implementation. Not surprisingly, lofty visions and abstract mission statements advocated by change management gurus don't break the inertia either.

True buy-in is achieved only when managers realize why improving project performance is vital for the business (why change?). They also need to appreciate that the management challenges they face daily and the inordinate waste of time and capacity stem from the same root cause, that is, poor synchronization of tasks and resources.

Challenge 2: Translating Concepts into Practical Procedures and Instructions

Once managers have bought into the need for change and the validity of the Critical Chain Rules, a host of technical questions arises. What is the right level of WIP? How do you transition from high WIP to low WIP? When do you release new projects into execution? How do you size buffers? How much detail do you put into project plans? How do you ensure that removing local due dates and local efficiency measurements does not lead to loss of accountability? What does it mean to actively manage buffers?

Many such questions are answered throughout this chapter in a summary form. "TOC Insights into Project Management"8 and "The Goldratt Webcast Program on Project Management"9 provide more in-depth explanations.

Challenge 3: Sustaining the Critical Chain Rules and Results

How are organizations prevented from sliding back into their old mode of running projects? How do you adjust Execution as business needs change? Can the implementation be protected from changes in personnel, especially at the top?

These issues are not unique to Critical Chain but common to all management systems. Moreover, sustained superior performance is not a natural state for organizations; it requires strong leadership to produce great results on an ongoing basis. Still, hands-on experience in many environments has repeatedly shown that the following actions significantly increase the odds of sustained success with Critical Chain.

Mechanizing the Changes

Embedding the Critical Chain Rules into management policies, management processes, and management information makes an implementation less dependent on people. It makes sure that the Rules are not subject to individual choice; and it also allows them to be easily understood and translated into decisions and actions. Following are some examples of such mechanization, and making the fruitful practices routine: WIP Policy: Set a limit on the number of projects that can be in execution at a time.

Pipeline Reviews: Are WIP limits being followed and, if not, why?

WIP Alerts: Highlight if the actual WIP exceeds the allowed WIP.

Task Management Policy: Make task managers accountable for following the buffer-based task priorities.

Task Management Reviews: Are task managers assigning resources in order of priority and, if not, why?

Priority Compliance Reports: Show if tasks are being worked out of priority.

Establishing a Process of Ongoing Improvement

With Critical Chain, improving performance should not be, and does not have to be, a onetime event. Analyzing buffer consumption highlights the problems to solve to keep getting incremental improvements in overall performance. For example, a leading provider of food packaging increased its Throughput from 72 sales projects per year to 116, and then from 116 to 171. Originally completed in 2003, this implementation is still going strong.

Identifying improvement opportunities by analyzing buffer history ensures that local improvements will not only have a global impact, but also not violate the Rules. Actually, making those improvements will only increase the value of the Rules.

Turning "Execution" into a Business Asset

Improving performance is not just about catching up with the backlog and due-dates. It is also about building a business advantage. Once project speed, efficiency, and predictability become a business asset (high margins, low investment in operating infrastructure/equipment, or a competitive edge), the pressure to sustain results, as well as the Rules that enable them, will not subside.

For example, when the U.S. Air Force got used to having fewer aircraft in maintenance and more aircraft available to fly missions, its logistics centers had to sustain the fast turnaround times-the frequent changes in their military leadership notwithstanding.