critical chain

[dimpy.handa]

The main features that distinguish the CC method from the critical path are:

The use of (often implicit) resource dependencies. Implicit means that they are not included in the project network but have to be identified by looking at the resource requirements.
Lack of search for an optimum solution. This means that a "good enough" soulution is enough because:
as far as I know, there is no analytical method of finding an absolute optimum (i.e. having the overall shortest critical chain)
the inherent uncertainity in estimates is much greater than the difference between the optimum and near-optimum ("good enough" solutions).
The identification and insertion of buffers:
project buffer
feeding buffers
resource buffers.

 

[satyamsaxena0786]

Critical Chain Project Management (CCPM) is a method of planning and managing projects that puts the main emphasis on the resources required to execute project tasks. It was developed by Eliyahu M. Goldratt. This is in contrast to the more traditional Critical Path and PERT methods, which emphasize task order and rigid scheduling. A Critical Chain project network will tend to keep the resources levelly loaded, but will require them to be flexible in their start times and to quickly switch between tasks and task chains to keep the whole project on schedule.

 

[swatiraohnlu]

In Critical Chain scheduling, uncertainty is primarily managed by (a) using average task duration estimates; (b) scheduling backwards from the date a project is needed (to ensure work that needs to be done is done, and it is done only when needed); (c) placing aggregate buffers in the project plan to protect the entire project and the key tasks; and (d) using buffer management to control the plan.

 

[dimpy.handa]

Critical Chain scheduling typically involves a 2-point range estimate. As a matter of fact, we are probably using "safe estimates" that are bigger and safer than the old processes allow when they're combined with management pressures for shorter projects. What we are doing with the smaller, "aggressive but achievable," estimates is merely trying to understand the potential level of variation/uncertainty within that safer estimate of the task -- how much of the larger estimate is in there to cover the possibility of running into Murphy's Law while working on the task. We're not cutting estimates -- we're understanding them so that we can take their fears and uncertainties into account in a way that protects the project's promise.The shorter estimates are merely used to structure the network of activities so that we can understand what is truly critical.