Aligning Projects and Resources with Critical Chain Project Management

Critical Chain Project Management (CCPM) still electrifies peoples’ imaginations. More than 25 years after it was first introduced, I still meet people who are fascinated, even inspired, by the concept. CCPM, with its emphasis on resource management, seems to hit a nerve where classic project management techniques no longer help, and agile techniques also don’t seem to work. So, what is behind it?

The Theory of Constraints

The starting point of CCPM is the Theory of Constraints (TOC), or bottleneck theory. This method, developed in the 1980s by physicist Eliyahu Goldratt, optimizes production processes. The core insight is that every production chain always has a bottleneck, and it is precisely this bottleneck that determines how much the entire production chain can produce. It may sound a bit simplistic, but it’s very exciting.

Imagine a huge car factory with enormous machines, thousands of people and constant turmoil. At the windshield-wiper assembly, employees drop out due to illness and only 20 cars can be equipped  per hour. This means that from now on the entire factory cannot deliver more than 20 vehicles per hour. The bottleneck therefore determines the total output. And thus, you only need materials for 20 vehicles per hour.

This is precisely why, according to Goldratt, it is important to find the bottleneck and increase its output. After all, if more flows through the bottleneck, more will flow through the entire system. Interestingly, even inefficient work is permitted at the bottleneck. So, in the example, inexperienced workers who work slower, and whose work needs to be controlled, could install more windshield wipers and thus increase overall output.

Drum-Buffer-Rope

The mental image Goldratt established for this system is the famous “drum-buffer-rope”. Imagine a marching band, the band can only march as fast as the slowest person, so the drum helps keep that pace. In other words, the drum, representing the bottleneck, keeps the pace of the entire system. There should always be enough material used as a buffer before the bottleneck. This prevents the bottleneck from stalling if there are problems upstream. Finally, a mental rope is stretched from the bottleneck to the warehouse releasing material in the first step at the beginning of the production line. When the rope is stretched out to the limit, it acts as a constraint so that the system cannot be sped up beyond that constraint. As a result, there is no unnecessary material in production, the capital remains lean, and a steady flow of output is created.

Critical Chain Project Management

In the 1990s, Goldratt applied the Theory of Constraints to project management – and Critical Chain Project Management (CCPM) was born (Goldratt, Eliyahu M.: Critical Chain, The North River Press, 1997). In the “production system” of a project, CCPM ensures the creation of steady production while considering the resources. The production system is the value creation through the project – represented by the project plan. There, the sequence of activities, their dependencies and the use of resources are defined.

Critical Chain Project Management should not be confused with the critical path (CP). In the latter, the “critical” processes are searched for, i.e., the steps whose delay would endanger the project timing. See the figure below: 

The red activities are on the critical path – a delay there will endanger the end date of the entire project; the blue activity, on the other hand, has more than 7 weeks of time buffer.

CCPM not only addresses the predicted duration of tasks, but recognizes that uncertainties and risks affect the availability of people and equipment. Goldratt therefore proposes several countermeasures to achieve a steady flow of work through the project system.

First:

Multi-tasking, i.e., jumping between different activities, is inefficient. After all, time is lost by mentally switching to the next topic – experts claim this number is around 40%. So, one should not start too many projects at the same time in the first place.

Remember the drum-buffer rope above? Only as much new material (projects) should be released to the system as the bottleneck (humans) can handle. In the figure below, this becomes clear through a “Tetris” screenshot of a resource histogram. Paula seems to be tied up in many – probably too many – projects at once.

Second:

CCPM, just like the TOC, looks for the bottleneck. Bottleneck resources are the people or equipment that are overloaded, which projects must constantly wait on. However, unlike the CP method, resources determine the sequence of operations whose delay endangers the end of the project. This is also possible across chains.

All activities in which bottleneck resources are planned must therefore be “buffered” or, accounted for, during project planning. How?

a) Allow enough time around the use of these resources to anticipate that they will not be available in time. Goldratt refers to these buffers as “feeding buffers”
b) Seek replacement personnel or additional personnel, even if they are not equally efficient. In the following figure, it is clear that “Peter” determines the critical chain here.

Third:

Goldratt assumes that buffers are factored into every activity. This is bad for two reasons, he says: if there was too much buffer, the result is an unnecessary wait for the “official end” of the activity – in fact, it could have been started earlier. If there was too little buffer, the project schedule gets messed up.

Goldratt’s solution: instead of estimating buffers into each task, all buffers are added in their entirety to the end of the project. As soon as a task is completed, the next one is immediately started. If a task takes longer, the total buffer (“project buffer”) is used up.

Fourth:

Intermediate milestones for measuring progress are consequently not used. In contrast to the “earned value analysis”, progress is not measured in terms of completed work packages, but along the time spent. And it is precisely this that is compared to the time buffer consumed. So it’s not primarily about the effort spent, but about the progress over time. Excuse me? That will lead to effort overruns! Maybe – yes, these are not measured any more than effort underruns – it is about the delivery of the result. Have you heard that before?
Sounds kind of agile, doesn’t it? 

Fifth:

CCPM encourages project teams to be open and to communicate both within and across teams. Bottlenecks should be looked for and solutions worked out together, without waiting for management intervention.

CCPM in Summary

CCPM ensures improved flow of work through the project compared to traditional project management. The application of the “drum-buffer-rope” method reduces multi-tasking and unnecessary waiting times. At the same time, it accepts that when people are involved, risks will arise and they must be mitigated before and during important activities. Finally, processes are completed “as quickly as possible” instead of in a predefined period of time. The team focuses on one topic without multitasking and takes as long as it needs. That sounds a bit like Scrum, doesn’t it?

Should You Start with CCPM Tomorrow?

So – is CCPM the solution to all problems? Compared to traditional project management, CCPM was a big step forward – the inclusion of resources acknowledges reality. At the same time, helpful solutions are provided. Agile methods, whose triumphant march has continued since the early 2000s, however, criticize that estimating task durations or buffers or even preparing a schedule is itself “muda” – wasteful.

Instead, they focus on prioritizing work packages and processing them in sprints – the order can and should change after each sprint, depending on the customer’s priorities. Working on what the customer no longer needs is thus avoided, and you don’t spend time working on unrealistic plans. In highly uncertain environments, this is the better alternative. At the same time, agile methods have difficulty synchronizing the work of teams that operate independently of one another.