The Critical Chain Method
The Critical chain method – also known as critical chain project management (CCPM) is a planning approach that claims to resolve many problems that are seen as endemic in traditional project management.
Critical chain management is included in the list of project management methods that PMI expects candidates sitting the PMP exam to be familiar with.
What is CCPM?
Critical Chain Project Management is a project management methodology defined as a set of interlinked techniques and tools that work individually and collaboratively to significantly improve the processes and operation of scheduling and execution in project, program, and portfolio environments.
Specifically CCPM seeks to develop realistic schedules where contingency is protected, whilst putting great emphasis on efficient working practices, progress visibility, focus and control.
Eliyahu Goldratt developed CCPM. Goldratt had been working on improving factory efficiency and advocated identifying production bottlenecks and focusing on keeping those stages in production operating at maximum efficiency. This in itself was an application of the Theory of Constraints (TOC) from the early 1980s, which he writes about in one of his business novels, ‘The Goal.’
Goldratt extended his work beyond factories and into project management, publishing ‘Critical Chain in 1997.
The problems Critical Chain Project Management tackles
One of the challenges with estimating projects is that by their nature, estimates are uncertain. But what most project managers will recognize is that whilst task estimates may be uncertain, their variability is almost always positive. That is to say, tasks often take longer than the estimated time but very rarely get delivered early. Goldratt cites three reasons for this:
- Student Syndrome: This truism suggests that most people do not fully apply themselves to activities until at least half the time allocated has elapsed. This idea of planned procrastination has been backed by research and appears to be entirely normal behavior. But it does mean that any margin for error is removed, resulting in a tendency for work to be completed late, no matter how much time has been allocated.
- Dependencies: When several workstreams on a project come together into a single dependent activity, that dependent activity cannot start until all of the preceding workstreams have been completed. This means that if you have five workstreams all coming together for (for example) an end-to-end system test phase, then even if 4 of the 5 streams finished early, the testing will still start late if the fifth stream is delayed.
- Parkinson’s Law: Attributed to C. Northcote Parkinson, Parkinson’s Law on the pursuit of progress states that work expands to fill the time available for its completion.
Work Expands so as to fill the time available for its completionC Northcote Parkinson (Parkinson’s Law)
Given what we know of Student Syndrome and Parkinson’s law, adding contingency to tasks on a project simply results in the project delivering later. Often, because contingency is mentally factored in by people working on the project, they will start fully applying themselves later than normal when there is an understanding that contingency exists. This can often end up with situations where adding contingency not only makes delivery later, but the contingency is actually over-run, and projects get even later.
The other issue with adding contingency to individual tasks is that it can artificially inflate timelines. For example, if we have four tasks that run sequentially, and we allocate a week of contingency time to each. In our schedule development plan, this contingency would add a month to our timeline. But our reality is that we do not expect to use that contingency on every task. With Critical Chain, we use statistical analysis to model out contingency. Keeping it simple, if we say that we believe there is a 50% chance of a task needing to use its one-week contingency time, then it follows that on aggregate, we only actually need to allow for a single two-week project buffer, rather than four weeks of contingency.
For the four tasks in our example, this is a simple concept to follow. But on more complex plans, with multiple tasks, each with different risk profiles, things can get complicated pretty quickly! Before you know it, you find yourself learning about statistical terms such as standard deviation, skewed distributions, and Central Limit Theorem. For this reason, CCPM usually requires specialist software to calculate and keep track of the time buffer.
‘Remaining Duration’ Reporting
This is one of those simple things that can make a big difference on a project. When using the CCPM, we avoid focusing on milestones for delivery. Instead, we focus on encouraging and rewarding behaviors that lead to the delivery of critical activities as fast as possible. This requires a change of reporting and a change in mindset. Firstly, the question ‘Will you get it done by the planned end date” ceases to exist in the project manager’s lexicon. To avoid Parkinson’s law, we focus on delivering as fast as possible, rather than focus on milestone dates. The second change comes with reporting. Rather than getting updates in terms of ‘percentage complete’, we ask for estimates of ‘Remaining Duration’. Reporting in this way provides a more realistic picture of when activity is likely to complete and prevents late-emerging issues. Crucially, it removes one of the most irritating symptoms of project management: The tasks that are perpetually 90% complete, but where the amount of time required to deliver the final 10% seems to bear no correlation to the time taken to complete the first 90%!
Most projects will have a critical path of activities. These are identified using the Critical Path Method. The critical path can be identified because a delay to any one of the critical path activities will directly impact the end date of the entire project. But there are usually lots of paths and tasks that are not on the critical path, and in the world of project scheduling, we want to keep them that way!
The Critical Chain model handles this by introducing Feed Buffers for the noncritical chain. Feed buffers are not included in the overall Project Buffer but are used as a way of insulating the critical path of the project from non-critical workstream elements. By building in Feed Buffers, CCPM reduces the risk of projects overrunning due to dependencies
Chart afficinados will be delighted to find that CCPM introduces a new type of chart to track projects: The Fever Chart!
The fever chart plots the percentage of the Project Buffer that has been consumed against the percentage of the critical chain that has been completed. Progress is plotted as a line graph, giving a running commentary of how the project is performing.
Fever charts can also be used at the Program or Portfolio level. In the example below we have a real-time view of five projects and where they sit on the fever chart. Such a view allows the PMO or portfolio manager to see at a glance which projects need additional attention because they are burning through their buffer faster than they are getting critical chain actvities completed.
By plotting projects in this way, we start to use the buffer as a diagnostic tool: Projects straying into the red are likely to end up being late, and thus require support and action.
Finally, CCPM is very clear on its views on multitasking. It advocates for strict discipline where no one working on a critical path activity should be working on anything else at the same time. Eliminating multitasking can have a significant impact on productivity. As we noted in our article about Pull Systems and Mini-Motorways, multitasking can impact 20–80% of your overall productivity.