The Critical Path does not tell you everything you need to know about your Project’s constraints
Introduction
One of the key techniques project managers use to monitor and control progress on their projects is the Critical Path Method (CPM). This method, promoted by the PMI through its PMBoK, is meant to assist the project manager in identifying areas of high risk on the project. Given that, by definition, the Critical Path consists of the activities that have no float (or slack) and as such (again, by definition) a delay in any of these activities will cause a delay to the project’s planned completion date.
In order to ensure that the project does not miss its deadline, project managers are encouraged to protect the Critical Path by monitoring progress against plan and taking corrective and/or mitigating actions in order to ensure critical path activities are complete on time.
To illustrate the above comment let’s review the following example:

Resource leveled project schedule
In this overly simplified example, we have a schedule with 10 activities that have been leveled to ensure optimal use of assigned resources.
The Critical Path, clearly marked in red bars, is made of activities 2, 3, 6, 7 and 8. Activities 4, 5, 9 and 10 are not considered to be part of the Critical Path as they have a positive slack such that they can get delayed (limited by their available slack) without affecting the whole schedule.
Being an attentive project manager, and given the above schedule, your attention would naturally be drawn to ensuring that all critical path activities commence on time. You will review each of the activities on the critical path and identify the potential risks that could put your schedule in jeopardy. Having examined task 1.1, you would immediately realize that although this is not graphically marked in your project schedule, there is a dependency between this task and an earlier task 2.1. The reason for this dependency is that both tasks are planned to get performed by the same resource ‘Res-A’. Further examining your schedule you will also make the observation that the next task on your critical path, task 1.2, also has a resource dependency, and can only begin once task 2.2 is complete, as both tasks are performed by ‘Res-B’.
The conclusion we would immediately draw from the above cursory schedule analysis is that although not marked as forming part of the critical path, there are other tasks on our schedule that if delayed, will cause a delay to the project’s completion date.
So what is going on here?
The above discussion lies at the heart of the argument promoting the Critical Chain Method (CCM). It is not in the scope of this discussion to detail the intricacies associated with implementing this methodology. All we are suggesting is that even in projects where a complete Critical Chain Project Management (CCPM) is not implemented, some common sense components of this methodology should be considered and implemented, as otherwise, as demonstrated above, wrong scheduling conclusions could easily be made.
Given the discussion so far we should be able to define a revised rule for determining whether or not a task should be considered to be on the project’s critical path. But before we do that we need to create a new term ‘Task Resource Float’. The ‘Task Resource Float’ is the amount of delay that can be applied to a task, performed by a Resource, without introducing a delay into another Critical Path task, performed by the same Resource.
So given the following scenario:

Task Resource Float’ > 0
In the above case, both tasks 2 and 3 are performed by resource ‘B’. The ‘Task Resource Float’ for resource ‘B’ in task 3 is 2 days. This means that task 3 can be delayed by 2 days without affecting the overall project completion date. Assuming, however, that the planned duration for ‘Task 3’ was 3 days, the ‘Task Resource Float’ would be 0, in which case, for all practical purposes, ‘Task 3’ would need to be considered as forming part of the project’s critical path (see the below chart):

Task Resource Float’ = 0
From the discussion above we can now derive an enhanced Critical Path definition:
“The Enhanced Critical Path consists of all the activities with either a ‘0’ float or a ‘0’ Task Resource Float”.
Have a great week.


No related posts.
This is CPM from a different perspective. I did publish quite a few articles on critical path, most of them were an explanation on how to calculate the CPM.
I am interested in publishing this article on PM Hut, please either email me or contact me through the “Contact us” form on the PM Hut site in case you’re OK with this.
This is why DID 81650 in the US Federal procurement domains mandates Monte Carlo Simulation.
There is a vast amount of information regarding the issues with CP, but it is still a starting point for assessing the risks in the schedule.
Agree Glen, CP is definitely a good starting point. All I’m suggesting is that without much effort it can become even better starting point. And your comment re. Monte Carlo Simulation is definitely valid as it addresses the inherent risks built into the schedule in its entirety.
The Critical Path (CPM) does not tell you everything you need to know about your Project’s constraints | quantmleap http://bit.ly/4BQOnW
This is why DID 81650 in the US Federal procurement domains mandates Monte Carlo Simulation.
There is a vast amount of information regarding the issues with CP, but it is still a starting point for assessing the risks in the schedule.
The Critical Path does not tell you everything you need to know about your Proje[..] – http://b2l.me/m83d8
quantmleap: The Critical Path does not tell you everything you need to know about your Project’s… http://is.gd/qQBEl9 #pmot #ftpm #pmp