A Guide to Implementing the Theory of
Critical Chain Project Management – A Performance Engine For Projects
Critical Chain Project Management is the Theory of Constraints logistical application for project operations. It is named after the essential element; the longest chain of dependent resourced tasks in the project. The aim of the solution is to protect the duration of the project, and therefore completion date, against the effects of individual task structural and resource dependency, variation, and uncertainty. The outcome is a robust and dependable approach that will allow us to complete projects on-time, every time, and most importantly within at most 75% of the current duration for single projects and considerably less for individual projects within multi-project environments. The shorter duration provides a sterling opportunity in the marketplace to differentiate ourselves from our competitors who deliver poorer outcomes, and late at that, via other project management methods. It also offers the opportunity to deliver more projects over all, in the same amount of time, and at no increase in operating expense, thus significantly improving the bottom line. Would that be useful? Absolutely!
I like to think of Critical Chain Project Management as a performance engine for projects. And, by “engine” I don’t mean the thing under the hood of a bright red Ferrari, I was thinking more of the 4000-6000 horsepower turbo-charged diesel engine that sits under the long hood of each locomotive at the front of a North American transcontinental intermodal freight train. The analogy isn’t so far off. Such a freight train is long and sinuous and interconnected, it is challenged by some fairly impressive upgrades and is rewarded by coasting down some equally long downgrades, it makes a number of “meets” or passes along the way, sometimes having the right of way, sometimes having to wait for something else. But in the end the objective is to move the freight quickly and effectively from one coast to the other and to arrive on time.
Critical Chain Project Management is an amalgam of two parts; we need both parts to make a really good show. If the chain of critical tasks is the engine for projects, then buffer management is the monitor. Buffer management is the second part of this two part act. We use buffer management to guide the way in which we fine tune the motor for peak performance.
In the older notion of planning and control, or planning and execution, the first part; the critical chain, is the planning stage of the approach. This is the overall agreement on the logic and duration of the steps in the project. The second part, buffer management, is the execution control system that allows us to keep a running check on the system. However, I want to reserve the words “planning” and “control” for localized activities within individual projects. For the moment I want to step out a level and instead use the terms “configuration” and “monitoring.” Configuration becomes the generic rules for all Critical Chain Project Management, and monitoring via buffer management becomes the feedback into these generic rules. Let’s draw this.
The way that we configure the solution, the rules and understanding that we use to configure the critical chain, will determine the characteristics and the behavior of the system as a whole. The configuration feeds forward into the execution of the project. Buffer management allows us to monitor the behavior during execution and feeds back into future configuration decisions. It’s a bit like changing gears, as we get more speed up we can change into higher gears and go faster still. Keep this model in mind as we will return to it. Now, however, we must return to our plan of attack and work through the development of the solution.
Let’s remind ourselves of our “plan of attack,” the focusing process.
On the measurements page we introduced the concept of our “rules of engagement” which was to define; the system, the goal, the necessary conditions, the fundamental measurements, and the role of the constraints. On the paradigms page this was extended to include the role of the non-constraints as well – an important and too often overlooked aspect. On the process of change page, we introduced the concept of our plan of attack – Goldratt’s 5 focusing steps that allows us to define the role of the constraints (and therefore also the role of the non-constraints). Once again, the 5 focusing steps for determining the process of change are;
(1) Identify the system’s constraints.
(2) Decide how to Exploit the system’s constraints.
(3) Subordinate everything else to the above decisions.
(4) Elevate the system’s constraints.
(5) If in the previous steps a constraint has been broken Go back to step 1, but do not allow inertia to cause a system constraint. In other words; Don’t Stop Improving.
In all of the logistical applications of Theory of Constraints we have used these same 5 focusing steps as a scheme or a road map for explaining the detail of each application. There is no need to change our approach here, so let’s start at the start, with step 1; identify.
Let’s have a look at our simple project – the one that we used on the previous page in our prior discussion on buffers. However, let’s forget about buffers for a moment, we will incorporate that newfound knowledge soon enough. Let’s concentrate first on the critical chain. Here is the project plan.
We have 6 simple tasks in our project. Task 1 must be done before task 2, and task 2 must be done before task 3. Task 4 must be done before task 5. In addition, both tasks 3 and 5 must be completed before the final task, task 6, can be started. The two arms; tasks 1-3 and tasks 4-5 converge on task 6.
Let’s add some additional information, some task durations, and some colors to represent differing resource allocations.
We can see that each task takes a duration of 8 units of time and that 4 different resources are involved; we will call these, green, blue, lavender, and gray. Immediately, it is clear that the blue and gray resources have more than one task each to perform. In the case of resource blue, there is an apparent conflict. The resource must be in two places at once, or rather probably one place at once but doing two tasks. Hardly an unusual occurrence in projects – right? Just be thankful the tasks are for the same project with the same project leader rather than for two different projects with two different project leaders! That’s not so uncommon either?
How does the earlier approach of Critical Path Method deal with such conflicting resource allocations? There are two answers. The first is that it doesn’t deal with it at all, it just ignores it completely. This can be achieved by failing to resource the tasks or by resourcing the tasks and then failing to “level” the project according to the resourcing. But by far the better answer is to level the plan according to the resources. This is what we get.
The duration of the tasks that are resourced by the blue resource must both double in duration in order to accommodate the 50% availability of the resource for any one task at any one time. The project must then start earlier than initially planned, or customer willing, it must finish later than initially planned.
Once we have leveled the plan according to the resource availability we can determine the critical path in Critical Path Method.
Let’s have a look.
The critical path is the longest path of dependent tasks is the sequence; task 1, task 2, task 3, task 6. It has a duration of 40 units.
What then would be the critical chain? Let’s have a look.
In Critical Chain Project Management we also look for the longest chain of dependent events, but include resource dependency. The longest chain of dependent events is; task 1, task 4 , task 2, task 3, and task 6. Of these, task 5 and task 6 constitute a structural dependency, task 5 therefore constitutes a feeding chain into the critical chain prior to task 6, and task 4 and task 2 constitute a resource dependency, as a consequence task 4 is included in the critical chain.
In Critical Path Method the resource contention is addressed by leveling. Here the resource contention is addressed by moving task 4 back to an earlier start. There is no reason why a project manager using Critical Path Method would have not have used a similar solution to address this particular resource contention. It is important to stress, however, the principle of Critical Path Method, and that is that there is more than sufficient resource capacity to undertake all the dependent tasks. Reality is often different. Reality requires resource leveling or moving resource dependent tasks out of contention. In Critical Chain Project Management, principle and reality are aligned. Tasks are dependent and resources are always finite. We plan using that logic from the very start.
The strength of Critical Chain Project Management comes into its own when we see how the buffering of the critical chain and the buffering of the feeding chains protects the whole project. But we are getting ahead of ourselves. We have identified the critical chain, the longest chain of dependent variables; both resource and structural, and hence the shortest duration in which we can safely hope to complete the project. Or is it? Let’s see how we can exploit this chain.
We have identified the constraint, it is time. The only way that we can exploit this is to achieve the same outcome in less time. We can do this without working harder by addressing the mechanistic and psychological factors that confound the safety time embedded within individual tasks of the project. Indeed, we have addressed all of these in some detail in the preceding page on project buffers. The result, the generic configuration for Critical Chain Project Management, is that we can safely reduce the total project duration, the total touch time, to 75% of the initial estimate. This is what we will get.
Our 8 unit tasks are shorten to 75% of their former duration and are now 6 units long.
It is the generic or global configuration that determines the degree of exploitation of the Critical Chain. We don’t normally see it like this because we arrive at this deduction from a different direction; identifying the safety time, taking the safety time out, aggregating it, positioning it, and then reducing the excess that arises as a consequence of aggregation and global positioning. Because we have already “been there done that” on the previous page, jumping to this step shows clearly what constitutes exploitation. It is the shortening of the critical chain that constitutes exploitation. The project buffers are not an exploitation step, they are a subordination step – they ensure that our shortened project remains feasible. If we were to leave the safety time localized and embedded within individual tasks we would have no better chance of exploiting the critical chain than we currently do. We will come to subordination soon enough.
At a local level, for each unique critical chain project there is another level of exploitation, I want to call this local planning. This is the determination of each individual task in the project – or indeed whether something is treated as one task, subdivided into two tasks, or amalgamated with another task to create one larger task. It also involves the determination of an appropriate initial task duration estimate. This is an estimate that has a reasonable chance of completion. It is not a generous estimate that will ensure completion and it is not a tight estimate that will ensure non-completion. It is something that we should be reasonably comfortable with. We have previously addressed this as the 80% estimate.
At a local level, for each unique critical chain project we must also determine the correct sequence. This might appear trivial, but there are very many projects where task B is done after task A because; “we have always done it that way.” If we can, we should take tasks that in the past were serial and make them parallel. This is what I mean;
Where tasks or a set of tasks fall into something like a repeatable unit from project to project, we should take efforts to reduce the variability within that subset as much as possible. Yes, I know, this is motherhood and apple pie – but like motherhood and apple pie, there is a world of difference between knowing and doing. And it is doing that we are interested in. The excuses for not doing this (and making the same mistakes again and again) are; “ our projects are not that similar” or “our staff turnover is quite high.” Well if your staff turnover is quite high, ask yourself why, and also try to capture some of the detail explicitly (= write it down) so the next “lot” will have something to go by and may as a consequence be more inclined to stay. Yes, I know; “we don’t have time to do that!” Well, we will have time, by the end of this exercise, if we wish to make use of it.
Lastly, at a local level, for each unique critical chain project, resource the tasks with appropriate people. A good place for less experienced people is on the feeding chains, a good place for experienced people is on the critical chain.
Here is a summary diagram of the local planning aspects.
Anything at a local level that reduces a task duration will have a positive benefit to the overall project when we apply our global task sizing rule. It should go without saying, but let’s say it anyhow, reducing exposure to non-project work (at the very least for the duration of an active task) is another important and often over-looked exploitation tactic. These are generic exploitation strategies.
Let’s have a look then at subordination.
Here is our Critical Chain once again, showing 75% of the original task duration.
These tasks still contain the remainder of their embedded safety. The remaining safety as we determined on the previous page is one half of one half, or one quarter, of the original task size (or one third of the reduced task time). One quarter of 8 units is two units.
We then reduce our task touch time estimate accordingly – by 2 units, to 4 units.
The task touch time is now half of the original. Let’s call this the reduced task time, or the focused task time. We must then aggregate the critical chain safety into a completion buffer at the end of the critical chain and a feeding buffer at the end of feeding chain. Let’s do that.
We now have a critical chain; tasks 1, 4, 2, 3, & 6, and one feeding chain; task 5. The feeding chain has a feeding buffer and the critical chain has a completion buffer. The whole project can be completed in 75% of the initial project estimate because when we share the safety we need less overall than if it was locally distributed. The buffer in each case represents 50% of the preceding reduced tasks.
Let’s remind ourselves once again, Critical Chain Project Management is a sequence, not a schedule. The task touch times are made short enough that indeed some tasks can be completed within that time. Most, however, will probably need to use some of the buffer time that is aggregated and available to the whole project.
The buffers subordinate the tasks to the total project completion time and ensure that we are able to fully exploit the 25% reduction in completion time.
We will take a journey through time and show how the individual tasks and buffers operate and interact. But first, there are a few more subordination issues to cover.
The eagle-eyed amongst us, might have seen an opportunity to further reduce the completion time and thus further exploit the system. Because this option ends up giving us two choices, it is worth following up as an alternative on a separate page.
What else do we need to protect? Well if Critical Chain Project Management is a sequence, not a schedule, then how do the various resources know when to start their tasks? The answer is that we must keep them “in the loop” as the project progresses. Although this has been termed a “resource buffer” (1,2), it is really a “please let me know in advance” of the intended task start date. The only scheduled dates in this plan are the start and finish dates.
A much more important subordination activity is the removal of multi-tasking
There seems little point in exploiting the constraint, the amount of time taken to complete the project, if we then go and extend the completion time by multi-tasking – the market won’t thank us for doing that because it will not perceive a difference.
Multi-tasking is the habit of having more than one task from more than one project on the go at the same time. We “slice and dice” between the competing priorities of the various projects. If nothing else, we extend individual task time by the multiple of the number of concurrent tasks that we are working on. If everyone in the system is doing this – that is, it is happening to most tasks, it shouldn’t be surprising to find whole projects taking longer as well as individual tasks. Here is a simple case, just two projects. Let’s see what happens.