Project managers-According to a provider of telecommunication switches, there was tendency in their implementation to use project review meetings only to explain "red" buffers. Only when the division managers started expecting actions for recovering buffers did the projects begin being brought on track.

Resource managers-At a provider of IT applications, resource managers initially did not see a role for themselves in managing execution. However, after Buffer Management was in place, it became evident to them how to anticipate and prevent resource bottlenecks rather than scrambling for resources post facto (one of the outputs of Buffer Management calculations is an accurate list of upcoming tasks in every department and corresponding workload). Moreover, their earlier resistance evaporated.

Frequently Asked Questions

Following are some additional implementation-related questions and answers drawn from field experience.

Can Critical Chain be implemented without basic project management in place first?

It is worthwhile debunking the myth that Critical Chain might be too advanced; that project management basics have to be well in place before Critical Chain can be implemented. It has been observed that many of the so-called "basics" actually propagated and reinforced the old ways of running projects. Organizations that were mature in "basics" actually had to let go of some of the practices they had acquired; for example, making detailed project plans and issuing precise task schedules. Organizations that did not have the required fundamentals such as good project plans or management structure could quickly establish them as part of their implementation. The effort is not on establishing the "basics," but on implementing Critical Chain itself.

Should a pilot be run before a full rollout of Critical Chain?

Not necessarily. The application of Critical Chain is now well understood for a wide range of project types. A pilot is not needed if experienced implementers who have successfully performed similar implementations elsewhere are engaged.

If implementing alone and for the first time, without help from experienced implementers, a pilot might help19 in understanding the implications of all Three Rules.

If external help is available but does not have experience in a relevant business or operational environment, pilots may be advisable for the same reason. However, it is important to set clear objectives for the pilot (e.g., what specific changes to test and what effects to measure) and structure a pilot accordingly.

What about cultural and behavioral changes?

Organizational culture and peoples' behaviors cannot change before results happen. The culture and behaviors under Critical Chain are undeniably quite different from traditional culture and behaviors. At the same time, culture and behaviors are broad and nebulous terms; if not careful, they can become a smoke screen to hide real implementation issues.

More importantly, culture and behaviors stem from how you manage. Change the rules and associated policies and measurements, and the culture and behaviors will begin to change as well. Results that come from new rules will only accelerate those changes.

What is the role of software in Critical Chain?

The main role of Critical Chain software is enabling and leveraging Buffer Management.

Many project planning tools can create satisfactorily buffered project plans (albeit with a lot of manual effort), and even spreadsheets can adequately plan pipelines. However, for Buffer Management, specialized software components are required: A computational engine to monitor buffers and calculate priorities A central database to collect the inputs and outputs of buffer management A Web-based platform to capture and disseminate information in real time across the enterprise Specialized software can also play a significant role in sustainment by monitoring and reporting the results as well as adherence to the Three Rules.

Is a Project Management Office (PMO) needed with Critical Chain?

While a specialized group is needed to support a management system based on Critical Chain, it is quite different in nature from a traditional PMO. Whereas the traditional PMO is mostly about planning and reporting, often with an explicit focus on improving and enforcing task estimates, a Critical Chain support group is about facilitating synchronized execution. Its role is applying and enforcing the Three Rules by helping: senior staff maintain low WIP, create pipeline and capacity based on business goals, slot new projects into the pipeline, and monitor results and adherence to the Critical Chain Rules; project managers create properly buffered project plans; task managers follow priorities; identify and capitalize on opportunities for continuous improvement; and train and coach new managers.

To communicate and reinforce a clear change in focus, it is probably appropriate to term the Critical Chain support group as Execution Management Office (EMO). This group should be professionally knowledgeable in Critical Chain Rules and practices, and expert in execution management software.

How is non-project work handled with Critical Chain?

Up to 10 to 50 percent of work that a typical project-based operation has does not come from projects. Examples of such work include sales support, field support, and special tasks that cannot be classified as projects. All such work potentially interferes with following buffer-based priorities for project work. To make matters worse, non-project work often does not go through a central coordination and control point, or gate; it just lands on people's desks.

When non-project work is little (~10 to 15 percent of the total workload for a set of resources), a practical solution is to establish a central gating and dispatching mechanism. Emergency work is immediately assigned, preferably to those people who are not working on red tasks, while other work is assigned to people as they finish their project tasks.

If non-project work is substantial (more than 20 percent of the total workload for a set of resources), it is best to dedicate capacity for it. Otherwise, not only will it be difficult to follow buffer-based priorities for project work, but non-project work will suffer as well. If it is important to give everyone a chance to perform project as well as non-project work, a rotating pool can be established whereby people are assigned to non-project work for only a few weeks at a stretch.

Should the scope of a Critical Chain implementation include vendors and subcontractors?

If vendors supply long lead-time items, and procurement of those items is on the projects' critical path, the improvement in project cycle times may be limited if vendors are not included in the implementation. Organizations can still achieve the full potential increase in Throughput of internal resources (typically 20 to 25 percent), but only 10 to 15 percent reduction in overall cycle times. Achieving greater reduction in cycle times requires offering vendors an incentive for faster supply, and perhaps implementing Critical Chain (or Drum-Buffer-Rope) in the vendors' operations.

If subcontractors perform a significant amount of work for the project, the improvement gains in Throughput as well as cycle time may be limited if they are not involved. If proper incentives are provided, subcontractors can be persuaded to execute their work in accordance with the Three Rules of Critical Chain-to the benefit of both parties.

How does Critical Chain improve quality?

Critical Chain helps improve quality by cutting down firefighting and multitasking and by creating time at the beginning of a project for full kitting. Moreover, metered release of projects checks the temptation to start them before fully defining the requirements, which minimizes later changes and the rework, errors, and multitasking that emanate from them.

Critical Chain seems to be all about timelines; what about controlling costs?

Of course, costs of a project cannot be managed without regard to project benefits. It is sometimes possible that the benefits far outweigh the costs of doing projects faster. In most other cases, costs can be a relevant concern.

There are two viewpoints about timelines and costs. One viewpoint is that they are in conflict-shortening timelines costs more money. The other is that the longer projects take, the more they cost, so there is no need to worry about costs as long as projects finish faster. However, both these assertions are only partially correct.

Many adopters of Critical Chain have found that project costs can be divided into three categories: 1. Costs of Capacity: Costs of people, equipment, and facilities fall into this category. The faster projects are done, the earlier the capacity is freed up, and the capacity costs incurred by individual projects are lower. This applies if projects are done faster without increasing the rate of expenditure on resources (e.g., by expediting, spending overtime, etc.). If resources are fixed, and these resources can complete more projects within a fixed time, then the average cost of the completed projects declines. Similarly, if projects are delayed, the (assigned) cost of individual projects could increase.

2. Costs of Purchased Items: Costs of material and components, and firm-fixed price work done by subcontractors, fall into this category. Such costs likely will not change with project duration, except if supplies are expedited. Such costs are best controlled with traditional methods, within the framework of Critical Chain policies and practices.

3. Costs of Expediting: The exceptions to the previous characterizations are the costs that can be incurred to recover buffers; this includes costs of extra capacity as well as paying premium prices to expedite materials, buying materials that are more expensive, or transporting materials using faster modes of transportation, and the like. Of course, such costs should be incurred only if the benefits of improved delivery or reduced risk outweigh the costs.

Potential conflict between timelines and expediting costs can be mitigated by recognizing that buffer recovery actions at additional expense may be required during execution. A useful and prudent practice is to set aside monies to help recover buffers as necessary. This "budget reserve" is part of the total budget, not in addition to it. Experience says that 10 to 20 percent of the total budget is appropriate for "budget reserve," and setting it aside upfront helps prevent cost overruns while delivering projects on time.

Do we need project-level budgets in multi-project operations?

Since costs of capacity in multi-project operations are not incurred project-by-project but in aggregate, it is not necessary to budget these costs at the project level. An aggregate budget is generally sufficient for controlling the costs of capacity. However, a project-level budget may be helpful for managing the costs of purchased items. In addition, organizations might still need project-level budgets for reporting to their customers and for financial accounting purposes.

Does Critical Chain work with Earned Value Reporting?

It is quite straightforward. Organizations contractually obligated to report Earned Value metrics continue doing so even after they implement Critical Chain. However, they do not use CPI20 or SPI21 to measure Execution and drive execution priorities. They use Buffer Management for that.

How does Critical Chain work with Lean?

Lean has three well-known elements: Kanban, which is about synchronizing execution priorities and tying them to the actual demand; Flow Lines, which are an alternative to Kanban; and Kaizen, which is about a process of continuous improvement.

Kanban normally does not apply to projects. Flow Lines have been tried in project-based manufacturing but without much success. The reason is that Flow Lines require reliable estimates of time and effort required to do a task, which are not possible in projects. In short, there is no alternative to Critical Chain for synchronizing project execution.

The difficulty with Kaizen in projects is that on the one hand, almost everything can be improved, and on the other, most local improvements do not translate into better project performance. Buffer diagnostics can enable Kaizen by helping to isolate and prioritize meaningful improvement opportunities.

In other words, Critical Chain is Lean for projects.

What are the likely causes of failure in implementing Critical Chain?