Similarly, after a large provider of IT applications to the telecommunications industry got used to 14 percent higher revenue per person and 20 percent shorter project durations, the part of the organization delivering those improved results was not only expected but required to continue performing at those levels. Even more impressively, as increasing globalization and the 2009 downturn in the economy put more pressure on prices, this group rose to the challenge once again and was instrumental in maintaining corporate profitability.

Step-By-Step Process for Implementing Critical Chain

This section describes seven practical steps developed in the field over the last 12 years for getting results quickly (in weeks, not months or years).

The operative word here is "quickly," not only because results can be achieved quickly but because the actual results (or lack thereof) also provide useful feedback to the implementation teams. In those implementations where results were being achieved quickly, it increased confidence and strengthened buy-in; and in cases where anticipated results were not being achieved, course corrections could be made early.

It does not matter whether an organization is large or small; results can be realized within weeks-in fact, as soon as the first rule of low WIP is put into practice.

The seven-step process is as follows: Step 1: Achieve management buy-in Step 2: Reduce WIP and implement "full kitting"

Step 3: Build buffered project plans Step 4: Establish task management Step 5: Implement surrounding processes Step 6: Identify opportunities for continuous improvement (POOGI10) Step 7: (When applicable) Use superior delivery as a competitive advantage to win more business.

Each step is discussed in more detail in the following sections.

Step 1: Achieve Management Buy-In

Experience confirms that the TOC buy-in process11 works quite well, especially when facilitated by skilled and knowledgeable implementers-people who know the details of the adopter's business and operations as well as Critical Chain. For our purposes, this process translates into getting the following five agreements from management: 1. We need to improve project execution.

2. The solution lies in synchronizing resources by implementing the Three Rules.

3. The Three Rules can be translated into practical procedures.

4. We can take care of all the possible negative side-effects (e.g., loss of accountability when task level measurements are discarded; project managers gaming the priorities by manipulating buffers in their projects; delaying discovery of risks by not starting projects as soon as possible; etc.).

5. All the implementation obstacles (e.g., potential conflicts with "earned value reporting") can and will be addressed.

As the TOC buy-in process of gaining unequivocal acceptance is widely known and documented, this chapter will not dwell on it further.

The major learning to emphasize is that instead of pursuing Critical Chain as a "best practice," successful adopters used business needs to drive the implementation. Critical Chain was viewed as a means to this end. They analyzed how project performance was linked to making more money or achieving more of the goal of their enterprise, quantified the gap between desired project performance and actual project performance, and set improvement goals accordingly. See Table 4-2.

To demonstrate that managers are committed, the improvement goals they set should be ambitious. It has been consistently observed that organizations are more easily galvanized toward ambitious goals than around incremental improvements. Moreover, only when ambitious goals are set are substantial improvements realized. Modest targets are rewarded with moderate results, and lack of targets is accompanied by absence of results.

Improvement goals are usually set for higher Throughput (i.e., how many more projects, features, experiments, studies, etc., a year compared to current performance) and for faster cycle time.

TABLE 4-2 Links between Project and Business Performance for the Basic Types of Projects In just one real life example from among many, leadership of a large military organization set a target of increasing the number of testing projects by 40 percent-even though project people were overloaded and projects were running behind. Within three months, the organization was delivering 25 percent more projects, with 30 percent reduction in cycle times. In addition, the goal of 40 percent increase in Throughput was realized in eight months.

Step 2: Reduce WIP and Implement "Full Kitting"

Since the traditional mode of operation leads to too many projects in execution, there are two aspects to pipelining: one is transitioning from high WIP to low WIP, and the second is maintaining low WIP by releasing projects in a metered fashion. This step is about transitioning from high WIP to low WIP.12 The typical process for transitioning from high WIP to low WIP is as follows: 1. Create a list of projects in the various phases of execution. These phases in different types of projects, for example, can be: IT projects-Scoping, design, coding, and unit testing; system testing; and user testing New product development-High-level design, low-level design, virtual testing, prototyping, physical testing, and production ramp up Engineer-to-order-System design, detailed design, procurement, manufacturing, and assembly and testing MRO-Inspection and disassembly; repair, assembly, and inspection; and trials 2. Specify one of the phases as the drum.13 Drum is the phase that can accommodate the least number of projects at a time. Put 25 to 50 percent of the workload temporarily on hold in the overall pipeline as well as the drum. There is no need to worry about selecting a wrong drum at this time (it can be corrected later), or to be exact in calculating workload from each project. The objective is simply to free up enough resources so that remaining projects will be done substantially faster.

3. For the time being, organize remaining projects using a simple priority process like project due dates. The project that is due first gets the first shot at resources; remaining resources are given to the project due next; and so on. This will accelerate the rate of completing projects. A sophisticated process for synchronizing resources (i.e., based on the rate of buffer consumption) is implemented later (see Step 4).

4. Deploy any unassigned resources to "full kitting" the projects on hold. Full kitting is the process of clarifying requirements, getting sign offs, staging of materials, etc. It is important to distinguish between full kitting and actually doing the tasks: activities that allow project tasks to be done without interruptions are included in the full kit list, whereas activities that directly progress the tasks are excluded.

5. As in-process projects are completed, release the on-hold projects one by one according to their established priority.

Avoid paralysis by analysis. The goal is to get results quickly. For example, a major pharmaceutical company almost doubled its rate of project completion in the first 8 weeks-following the implementation of this step, they finished 11 projects compared to 6 projects in the prior 8 weeks. In other cases of comparable potential, hesitancy led to "more study," initial enthusiasm and momentum were lost, and the implementations were subsequently abandoned.

Step 3: Build Buffered Project Plans

Project plans are needed to provide execution priorities and early warning signals, and require the following data: Tasks and dependencies (precedents and hand-offs) among tasks Duration of tasks Type and quantity of resources needed for each task Task managers Buffers (feeding buffers, contractual milestone buffers, and project buffers) Resource types and the maximum units of a resource type available to the project Project end date and contractual milestone dates While the concept of a project plan is simple, many organizations struggle with defining the right level of detail.

Degree of Detail Required in the Plans

Too many tasks in a project plan induce multitasking, make it difficult to analyze plans and buffer consumption, and generally lead to loss of control. Not enough detail, on the other hand, leads to unclear priorities and hence the same effects.

Based on evidence from a wide range of industries, a task should be 3 to 7 percent of a buffered project's lead time. More than 250 to 300 tasks in a complex project and less than 10 to 15 tasks in a simple project are not recommended. If this guideline yields tasks that are too long and thus not useful for task managers, then subprojects can be used to zoom into detailed tasks instead of adding tasks to the main project. Subprojects that are two to four weeks long can be a network of tasks without buffers, while longer subprojects must be properly buffered project plans. For reference purposes: An IT application development project with 200 people working on it for four months is executed successfully with 150 tasks.

Aircraft maintenance and repair projects with 50,000 hours of work per project and durations of 7 months are managed with less than 200 tasks.

A 3-year pharmaceutical research and development project, with about 50 scientists and professionals working on it, could be managed well with about 175 tasks in the main project.

Development of digital cameras with 100 engineers and 10 projects at a time could be managed with 150 tasks per project.

Ten-day long helicopter maintenance and repair projects requiring about 4500 hours of work are being managed with 15 tasks.

Commercial shipbuilding projects with 750 people working on a project for one year are being managed with 275 tasks.

Construction of five 50-story buildings with 1600 people working on them for three years was managed with 5 projects and 290 tasks in each project.

The Process of Creating Buffered Project Plans

1. Define cycle-time targets.

2. Communicate to all managers that people will not be measured in execution against the task estimates used in planning.

3. Assemble a team of representative project managers and task managers and conduct a workshop to get their buy-in into the possible gains with the Three Rules.

4. Create project plans without buffers.14 Define the project's objective and the task that will signify achievement of that objective. This is the end-task.

Identify tasks whose completion is required immediately preceding the end task.

Identify tasks immediately preceding each of those tasks.

Keep working backward in this fashion until you get to the starting tasks.

From the starting tasks, work forward one-by-one to validate succeeding tasks. This will identify any tasks that were overlooked in the backward pass.

5. Convert project plans into buffered project plans (stagger tasks to avoid resource conflicts within projects and insert integration and project buffers in the required places).

6. Challenge and refine assumptions (data) whenever the calculated project cycle time does not match the expected/desired result (see first item).

7. Share the final project plans15 with all task managers so that they understand their tasks (outputs, precedents, handoffs, etc.) as well as the overall plan.

Additional Tips

A project plan is not a time reporting mechanism. The purpose of a project plan is to provide execution priorities and early warning signals.

Noise factors like "lead and lag" dependencies or "fractional resources" should not be modeled.

A project plan is not a to-do list. Tasks represent intermediate deliverables. If task managers or resources need a to-do list, these activities can be captured under the task as a checklist.

A task is a chunk of work; definitive hand-offs of work characterize task scope. A task should not be broken down into several pieces just because it requires different resources at different times. However, tasks should be broken down to reflect handoffs among main resource types; that is, those resources that are required for most of the task time.

Buffering policy should require projects to have a prescribed minimum amount of buffer before they can be accepted for execution. This will safeguard the buffering rule from project managers who might game the system by having smaller buffers, and from managers who might think buffers are unnecessary. Experience in small as well as large projects, and in one-off as well as repetitive projects, shows that about one-third16 of a project's total buffered lead time should be buffer; shorter buffers make the priorities sensitive to even minor perturbations and longer buffers tend to delay managerial interventions.

Step 4: Establish Task Management

Task management is about assuring tasks are executed in the proper order of priority and with minimal interruptions, and monitoring remaining duration. Implementing and reinforcing this process is the key to sustained improvements in project performance.

Reporting Remaining Duration

Daily during execution, task managers estimate how much longer it will take to finish each of their tasks-in-progress. With this simple information, the amount of buffer consumed for the corresponding legs can be calculated and compared to the work completed in that leg. This information is then used to calculate task priorities and provide task managers with a report of all the current and upcoming tasks in order of priority, along with the rate of buffer consumption on the corresponding leg.

Tendency to procrastinate17 or not report early finishes is automatically curbed in this process. According to the head of engineering at a North American company, when "red" tasks were visible to all the concerned managers, task managers did not need much prodding to make or to report progress; every morning they would come in, follow up on their tasks to make sure progress was being made, and report the remaining duration.

Assigning Resources