CCPM also provides some guidelines for managing multiple projects sharing a common pool of resources. During execution, if a given resource is required to work simultaneously on several projects, then CCPM prescribes that priority should be given to the task of the one project that is in the greatest risk of missing its committed date, as measured by the remaining fraction of project buffer.

CCPM assumes that all task owners pad estimates, and that the actual duration expands to fill the time allotted. These two assumptions are plausible, but CCPM theorists provide only anecdotal evidence. In fact, findings in a recent study by Hill et al. (2000) contradict the assumption that task owners will use up all the allocated time, and also indicated that the safety factor, if it existed at all, was certainly not sufficient for the 95% confidence level.

However, if we proceed under the CCPM assumptions there are still two important issues that CCPM does not address satisfactorily. Firstly, how do we estimate the extent of safety factor presumably built into the estimate provided by the task owner. CCPM suggests reducing the estimates by a certain percentage, typically 33%. Clearly such an approach is problematic.

Secondly, the behavioral aspects of taking away the safety margin from the task owner are dealt only superficially by CCPM literature. Imposing shortened duration estimates on the task owners reduces their commitment to the estimates, and could easily encourage them to add larger margins.

In order to contribute to the reduction in the overall project duration, the size of the buffer has to be less than the sum of the safety margins extracted from the tasks on the corresponding chain. However, CCPM does not provide any scientific or objective basis for determining the buffer size. This raises several problems.

First, the concept of feeding chains is based on the assumption that the project network consists of several paths that can start in parallel and then proceed to merge into each other, eventually leading to the final product of the project, as shown in Figure 3

Figure 3 – Typical Project Network According to CCPM

However many projects have much more complex network flows, where a task may have both predecessors and successors from several chains. In such cases, it is not clear at all how much feeding buffer should be allotted to each merging task.

A second issue: CCPM depends on identifying the critical chain, but the mathematical problem of scheduling project tasks under resource constraints is known to be very difficult to solve optimally. Thus, it is hard to assess how good is the schedule upon which the buffers are based.

In addition, the critical chain itself may change due to several reasons. If the feeding buffer exceeds the free slack of the feeding chain, then that chain becomes part of the critical chain (see Hoel and Taylor (1999)). During project execution the critical chain may change as resource availability changes or buffers are used. Changes in the critical chain affect the meaning of the various buffers, bringing us to a third issue, the use of buffers for project control.

CCPM achieves schedule control by monitoring the extent of buffer penetration, defined as: "The amount of time running from the original start date of the buffer, to the projected end date of the last task on the corresponding chain". The remaining-work estimation is also subjected to inflation by safety margins, the very same problem that CCPM attempted to solve by using buffers.

CCPM prescribes that priority for limited resources should be given to the task belonging to the chain with the highest rate of buffer penetration, because these chains are most likely to finish late. However, other things may be more important, such as a project’s strategic or financial impact.

A final point deserves attention. Buffers typically add at least 10-15% to the number of items on the Gantt chart. These additional items, which have to be interpreted differently from the others, add clutter to the schedule and increase the potential for confusion.

Overall, although feeding and project buffers have some intuitive appeal, they have limitations as the main decision-making criterion in project control.

CCPM abhors multitasking, but it is not clear that this is a good idea. In fact, a study of 64 high technology firms carried out by McCollum and Sherman (1991) presents some contrary evidence. Specifically, they found that for two of the most important measures of performance, return on the investment (ROI) and rate of sales growth, assignment to two projects seems to be optimal, while a range of up to three may not be problematic.

Resource buffers as a method of team coordination seems rather chaotic, requiring a great deal of unscheduled communication. It may not be feasible at all with outside contractors. There is value in alerting resources to important (critical chain) early-start opportunities, and CCPM is correct to point out that completing tasks on time is not the same as completing the project on time. However, it is our opinion that this is a supplement rather than a substitute for the traditional way of publicizing an agreed schedule, and maintaining its integrity through an effective change-management process.

CCPM deals with multi-project environment by staggering the projects around the constraining resource. In principle, at any given point in time there could be several constraining resources, each leading to a different schedule. The premise that there is a single constraining resource seems more applicable to manufacturing and operations environments than most project environments. Consequently we doubt the applicability of the solution obtained with CCPM.

Project success and project management success are not necessarily equivalent. For many project managers, "Success" means meeting agreed goals on time and budget. Customers are more interested in the benefits that they realise - Lipovetzky et al. (1997) showed that this is almost twice as important as meeting planning goals.

Like conventional project management, CCPM deals with project management success rather than project success. Further, CCPM focuses on schedule goals, particularly on schedule uncertainty. Rather than addressing the root cause of duration uncertainty, CCPM accepts it as a given, and attempts to manage it by means of buffer management. Although CCPM does not preclude the application of other, more comprehensive risk management approaches, its limited focus makes it ill-suited to serve as the single tool for dealing with project uncertainty. At best, it can help manage the schedule uncertainty that remains after the application of risk analysis and risk mitigation tools.

Further, since CCPM is presented as a revolutionary concept that replaces rather than complements current project management knowledge and practices, it is not properly integrated with the accepted body of knowledge and state of the practice. This situation poses a dilemma to organizations that are new to project management, and are asked to choose between CCPM and mainstream methodologies.

The implementation of CCPM requires that project personnel use a software tool that supports the concept of buffer creation and management. The range of software tool options is limited, relatively expensive, and not mainstream.

However, the software costs of CCPM are likely to be secondary relative to the cultural costs. CCPM is presented as a methodology that has to be adopted in its entirety. As such, CCPM requires massive re-education, including: