The Definitive Guide to Project Management: The fast track to getting the job done on time and on budget (2nd Edition)

Appendix A. The critical chain method

This appendix describes the critical chain approach to project management. It differs from the approach given in the book thus far in its focus on managing buffer, or reserve. The central idea behind critical chain is that people naturally tend to add too much buffer or contingency reserve when planning and estimating, for good reasons. But the overall effect is that there is too much slack built into projects, unless this human tendency is tightly managed. Critical chain seeks to make a virtue out of this feature of human nature.

Critical chain has been shown to deliver great benefits over conventional project management techniques, but it differs significantly from other project planning and management techniques. It may be a new way of working even for some experienced project managers. For this reason, only the key points of the technique are summarized here.

The critical chain method evolved from work by Eliyahu Goldratt on improving factory efficiency^[1]. Goldratt advocated identifying the bottlenecks in production and concentrating all effort on ensuring that these stages in the production process worked at maximum efficiency, thereby maximizing the efficiency of the overall process (this was an application of his theory of constraints). Goldratt applied and extended this work in the domain of project planning and management, and this led to the critical chain method^[2].

When a project is planned, most of the activity durations have to be estimated, and the actual durations of those activities may differ from the original estimate (see Figure A.1). Critical chain provides a means not only to retain control in the face of such uncertainty but also to exploit it.

One of the problems with the uncertainty of task durations is that the variability is predominantly positive: tasks often take longer than the estimate, but are very rarely shorter. There are several reasons for this:

• It is well documented that most people do not fully apply themselves to a task until at least half of the allowed time has elapsed (sometimes known as 'student syndrome'). This is entirely normal, and people may subconsciously or consciously allow for this behaviour in their original estimate. But it means that by the time the real work starts, there is often only just enough time left to complete the work package as it was originally understood, and the slightest problem is enough to push the duration beyond the deadline. Hence there is a tendency for tasks to be completed late no matter how much time is allowed.

• When several workstreams merge together into a single dependent activity, that dependent activity cannot start until the last of the merging workstreams has finished. Thus, even if three out of four merging workstreams have finished early, the downstream tasks will start late if the fourth workstream finishes late. All project workstreams must eventually merge together to produce the deliverables, but the fact that only the worst workstream matters means that project duration is again much more likely to be late than early.

• Parkinson's Law^[3] states that work expands to fill the time available. On projects, people hardly ever report that a task is completed early, even if their work was of acceptable quality long before the deadline. People may assume that there is some duty to spend the allotted time on the task or they may be tempted to add additional refinements to make the work better, or they may delay delivering the completed work until the deadline because they know that they will be given more work to do if they signal that they are available. Hence project managers rarely get the benefit of tasks being completed early.