The Critical Path Method and Wrong Project Scheduling
By Shim Marom
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:
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:
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):
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”.
Shim Marom (PMP) has been involved in the business implementation of IT projects in New Zealand and Australia. His background includes extensive hands-on experience in Data Modelling and Information Engineering while over the past 13 years he has been mainly engaged in project managing the development and deployment of IT Business Systems. Amongst other areas, Shim has managed a number of large Data Warehouse projects and led Agile and Infrastructure deployment projects. Shim can be contacted through his blog, the quant.M.leap.