To recap, we looked at the padded time estimates, Student's Syndrome, Parkinson's Law, Integration requirements and Multitasking all interacting with the heightened uncertainty (Murphy's Law) found project environments to more or less "guarantee" that projects will be late.



Local Versus Global Optimatisation

To explore an alternative project management approach, we must understand why time estimates are padded. It is to ensure that a project TASK is completed on time by protecting it against the impact of uncertainty. As we saw before, the combined effects of Student's Syndrome and Parkinson's Law then strip off the protection, exposing the project to delays.

What is our aim? Is it to finish a particular task on time or to complete the whole project on time? Of course it is to complete the whole project on time. If we aim to complete the project on time, we must relocate the protection (time paddings) from each task to the whole project. How do we do this?

Anyone with sufficient familiarity with project management knows that the determinants of the duration of a project are tasks on the so-called critical path. The critical path is defined as the path with the longest sequence of dependent tasks. To protect the whole project then, we must ensure we protect the critical path. This is done by stripping off the time pads on individual tasks so the time estimate for each task is reduced to half its original value. Half the stripped off protection is then added at the end of the critical path. Thus the new total estimate is at most 75% of the original. Why does this work?

Because individual tasks no longer have any slack, their performer is cured of Student's Syndrome because it is all he can do to complete it in the new allotted time. On the average because of uncertainty, half the tasks will finish late. Because of the complete absence of slack, the degree of lateness per task will be small. Some tasks will also finish slightly early. In this case the next person waiting to work on the subsequent task ensures that Parkinson's Law does not come into play.

Whatever delays remain (significantly less now because Student's Syndrome and Parkinson's Law have been eliminated) are absorbed by the accumulated protection at the end of the critical path. This protection is known as the project buffer. It is not under the control of individual project team members and so cannot be frittered away.

Critical Path or Critical Chain?

The critical path is defined in project management lexicon as the longest sequence of dependent tasks. In practice however, only structural dependence is explicitly accounted for. Structural dependence between tasks is dependence arising from the nature of the tasks themselves. For example in constructing a building, the foundation must be laid before pillars and beams are cast. Another source of dependence exists. This is resource dependence. This describes the fact that one project worker may need to perform tasks on more than one path in the project. While nothing in the nature of the tasks requires that they cannot be done in parallel, the fact that they are to be performed by the same individual implies it. Failure to explicitly consider resource dependence is responsible for the oft observed phenomenon where the critical path appears to jump from one path to another.

Because of resource dependence, tasks that determine the duration of the project may not necessarily lie on the same path. The name, critical chain was coined to reflect this reality.

Feeding Buffers

What about the non-critical paths? While they may not determine the duration of the whole project, their outcomes often need to be integrated with tasks on the critical chain. Thus delays in these non-critical paths will ultimately lead to the whole project being delayed. To prevent this from happening, each non-critical path that feeds the critical chain is protected in the same manner as described above for the critical chain: time estimates stripped to half their original estimate, with a 50% slack added at the end of the path.

Monitoring Project Progress

Project progress is monitored by assessing the percentage of tasks completed on the critical chain. As an additional measure of the amount of protection remaining, the percentage of buffer time consumed is compared with the percentage of critical tasks completed. Thus is 40% of tasks on the critical chain have been completed, while 55% of the buffer time has been consumed, the project is in danger of being late (no matter how far off the expected completion date).

These measures provide early signals to take extra measure to bring the project back on track.

Track Record (Wikipedia)

Research shows that typically, projects are completed in 222% of their original planned durations at 189% of budgeted costs. In 70% of the cases, the scope is compromised. 30% are cancelled.

On the other hand, for projects that apply the ideas outlined here - collectively known as Critical Chain Project Management, 95% are delivered on time and within budget. Organisations implementing the method as their way of managing projects experience on average 69% percent reduction in lead time, 60% improvement in due date performance and 68% improvement in revenue.