Once in Red, Always in Red

Critical chain project management (CCPM) assumes a static bottleneck in an organization, called the drum. In reality, these organizations are hard to find. In multi-project environments, the bottleneck is wandering from group to group in many occasions caused by the high variety of projects. It turns out that critical chain in theory is a far cry from critical chain in reality: once you’ve crossed the Rubicon, you tend to stay behind on your projects in a multi-project environment. I will share my experiences with CCPM and what we did to deal with dynamic resource bottlenecks.

Critical Сhain in Theory

The project buffer at the end of a critical chain protects the due date against uncertainties during project execution. A normal size for this project buffer is 50% of the time planned for the critical chain. During execution the focus is on the constraint – the critical chain – and by focusing there we have to do everything we can do to avoid consuming our project buffer. When there’s a resource conflict in a multi-project environment, there’s a rule that tells us to assign the resource to the project with the highest relative buffer consumption (the project most in the red).

Critical Chain in Reality

That’s the theory. But what happens in reality? Scientists question the validity of the CCPM drum approach suggested by Goldratt. In many cases, there’s no clear drum, which makes managing only the capacity of the drum insufficient for controlling a multi-project environment (Cohen et al.,  2004; Herroelen and Leus, 2004). During several multi-project implementations, I’ve personally noticed the following pattern: The project starts in green, and in some cases, even all parallel projects are in green. Until about one-third of the way through the project, the progress seems okay. But after a while the progress gets a bit behind and the project buffer turns yellow. When we’re two-thirds down the road, some project buffers turn red. But this isn’t a problem; we just need to take the right actions. If resources are needed, we’ll allocate them to the red project since its buffer consumption is highest. But after a while, many projects have entered the red zone. Borrowing resources from other projects is filling one gap by creating another. How come?

Feeding Buffers Hide Delays Instead of Protecting Project Progress

In order to analyze how we got into this situation, we have to look at the start of the project. If a resource in a multi-project environment has to choose between a task on the critical chain or a task on a feeding chain, then the priority mechanism will put the critical chain task at the top of the list. In most cases, this means consumption of the feeding buffer of that other task. In reality, this happens quite often. And this behavior was enforced by the measurement system. During progress meetings, we looked at the progress on the critical chain. But in fact, the feeding buffers were hiding delays in the project! However, they can only hide these delays until a certain point when non-critical chains become the new critical chain.

The Problem

Now you have a big problem. Increasing the speed on the critical chain in the beginning of the project was relatively easy: just get rid of all the disturbances on the critical chain or put one extra resource on it who was working on a feeding chain and voila, you can show nice progress to your boss. But now you’re out of feeding buffers and you have several chains that are about equally critical. One extra resource will not help much because then other chains will become critical. So you need a whole bunch of extra resources. Since other projects are also in red, you’ll have to fight for them.

Time vs Сapacity

What went wrong? We looked at the project buffer, which reflects the time dimension. But we forgot the other dimension – capacity! If one group is overloaded, then all projects that need this group will suffer. The constraint in a multi-project environment is not the critical chain – it’s the most constraining resource. And you can hardly find a company where this is a stable drum.

How Сan You Solve the Problem?

Two features are important to accomplish successful project performance:

1) Aligning task priorities

2) Determining capacity needed over time for all resource groups

The first feature is already present in current CCPM tools. The policy is essential to execute the task with the highest priority. The critical chain community has managed to polish this approach quite well. CCPM tools, however, have failed to tackle the capacity issue of the second point. Traditional tools won’t solve it unless you schedule all tasks over time, which is a waste of time according to Goldratt because of the high uncertainty. I totally agree.

Since I couldn’t find any critical chain software that would help me calculate and predict capacity, I started to devise my own tool in 2008 with the help of four members of the Goldratt implementation group. The tool is now called Epicflow, and the Epicflow company has over 25 people on board and many independent resellers. We’ve taken the advice of Dr. Goldratt very seriously. It doesn’t matter if tasks are finished on time as long as the project is finished on time. To meet the deadlines, we’ve developed advanced algorithms that determine the load by taking this principle into account. Not only for the drum, but for all resource groups. And not only their future load, but also their performance. In Epicflow, we emphasize the performance of teams; projects come and go, but it’s your people who stay and get the job done.

As I noticed many people outside the Theory of Constraints community struggle with critical chain tooling, we added the third point: The software must be easy to use, maintain, understand, and set up. Curious what it looks like? Sign up below for a free demo.

References

1. Cohen, I., Mandelbaum, A., Shtub, A., 2004. Multi-Project Scheduling and Control: A Process-Based Comparative Study of the Critical Chain Method and Some alternatives. Proj. Manag. J. 35, 39–50.
2. Goldratt, E.M.E., 1997. Critical Chain. North River Press.
3. Herroelen, W., Leus, R., 2004. Robust and reactive project scheduling: a review and classification of procedures. Int. J. Prod. Res. 42, 1599–1620.