Subordinating Merging Paths

Most projects have multiple task paths. All task paths must merge into the critical path by the end of the project, if for no other reason than to achieve a milestone that identifies project completion. Usually, the path merges tend to concentrate near the end of the project. One reason for this is that "assembly" or "test" operations tend to occur near the end of the project, requiring many elements to come together. The following demonstrates how this becomes a primary cause of the well-known project "truth" that many projects complete 90% in the first year and the last 10% in the second year. Figure 4.8 illustrates the filtering effect of merging paths. The successor task cannot start until the latest of the predecessor tasks is complete.

15 days late

15 days late

Figure 4.8 Merging paths cause critical-chain delay if any of the feeding chains are delayed.

Task-path merging creates a filter that eliminates positive fluctuations and passes on the longest delay. The reason is that merging task paths means that all of the feeding paths (outputs of the predecessor tasks) are required to start the successor task. Therefore, the successor task cannot start until the latest of the merging tasks completes. Consider a task on the project critical path that requires three separate inputs in order to start. This is very common in assembly operations and in many project results, such as a major show or meeting event, where everything has to be ready on opening day. Usually, there are many more than three. However, even with three, if each has a 50% chance of being done in the estimated time, the probability that at least one is late is over 88%! Even if each individual task had a 90% probability of completion, the probability that at least one will be late is still 30%, or nearly one in three.

CCPM protects the critical chain from potential delays by subordinating critical-chain feeding paths, placing an aggregated feeding buffer on each path that feeds the critical chain. Figure 4.9 illustrates the placement of the feeding buffers. This includes paths that merge with the critical chain at the end of the project. The feeding buffer provides a measurement-and-control mechanism to protect the critical chain. Figure 4.9 illustrates how the buffers absorb the late paths.

This innovation immunizes (to an extent) the critical chain from potential delays in the feeding paths. It also provides a means to measure the feeding paths, while keeping focus on the critical chain.

Many experienced project managers have confused the feeding buffer with project float, or slack. They are very different. You size feeding buffers based on the variation in the chain of activities that precede the feeding buffer. Thus, its size depends on the variation of the task. Inserting a properly sized feeding buffer may cause a gap in the critical chain.

15 days late 20 day Buffer

15 days late 20 day Buffer

Figure 4.9 Feeding buffers absorb fluctuations in critical-chain feeding paths.

Float, or slack, is a result of calculating the network using deterministic singlepoint task durations. It has nothing to do with the variation of task duration. A chain of tasks that is nearly as long as the critical path gets near-zero float, or slack, and probably requires the most relative to other chains. The idea that float, or slack, can help protect the network from merging paths is fundamentally flawed.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment