ON THE SURFACE Critical Path Method (CPM) is a beautiful work of human logic. By highlighting tasks that are most likely to affect the project deadline, CPM helps project managers meet deadlines. But often enthusiasm for conventional CPM wanes when the time comes to apply the theory in practice.
Put simply, CPM works by making a forward pass through the entire schedule, determining the early start and finish dates. The earliest finish date for the last task or milestone in the network establishes the earliest project end date. CPM then uses a backward pass to calculate the late start and finish dates. The difference between the late date and the early date of a task is the amount of total slack (or float) on a task.
Traditional CPM has its place, but for most organizations it is time that resources be fully recognized as part of the formula.
Flaws in the Critical Path Method
The shortcomings of CPM theory show up in the following situations.
Resource Availability. Consider the task to Move an office, which must take place during a weekend. If the resources for the task Move are entered to work only on a weekend, then the task Move is delayed until the next weekend, causing slack (or float) to appear on its predecessors. The result is that tasks prior to the move are not viewed as “critical” and the critical path becomes disjointed.
Fixed Dates. Schedule constraints can break the critical path. For example, typically business meetings, presentations, and other gatherings that are to occur on a specific date should be entered with a schedule constraint. But as fixed dates are entered into the schedule, slack is often created on the predecessors of the tasks with a schedule constraint. The critical path can start to look disjointed; only the task Meeting will be indicated as critical.
Elapsed Duration Tasks. An elapsed duration is measured in calendar-days, not business-days. An elapsed duration task can end during nonworking time. For example, carpet cannot be laid until after the paint is dry If Drying of Paint's elapsed duration finishes on Saturday, the task Lay Carpet is scheduled to start on the Monday. This creates one day of slack on Drying of Paint and its predecessors, because the paint also dries on Sunday; the critical path is broken. Elapsed duration tasks have slack if its successors are tasks that start on the next regular business-day.
Leveling and the Critical Path
The Domino Effect
Workload Smoothing
Resource Leveling. Exhibit 1 shows a situation where some resources are overloaded. Logically we decide to level the workloads to make the schedule feasible. In some instances, however, the over-allocations cannot be solved in any other way than to delay some tasks. But as soon as a task is delayed, slack is created on the tasks that competed for the same resource and the critical path—artificially—evaporates before your eyes.
Toward a Solution for the Critical Path Method
It is arguable that the first three situations create real slack in a schedule; real slack in the sense that it is a real buffer of time that can be used to resolve earlier schedule conflicts. The tasks with slack do not drive the project end date; hence, they should not be critical. Still it is frustrating for the novice scheduler who expects the critical path to be one complete sequence of tasks from the beginning to the end of the project. CPM training and software models rarely expose project managers to realistic examples of CPM applications. Where theory meets reality, practitioners wake up from their dreams.
As to the fourth situation in Exhibit 1, the flaw in CPM is more serious. CPM uses the unrealistic assumption that resources are available in unlimited quantities. However, this is only applicable to a few organizations that can quickly hire—and release— extra resources.
Exhibit 1 has two independent tasks, Write and Read. This exhibit illustrates the most serious flaw in the critical path algorithm. Harry is assigned full time to both tasks, but clearly cannot do both at the same time. Reassigning one of the tasks to other resources is not an option, because in this case there are no other resources. Therefore one of the two tasks will need to be delayed. But by delaying one task, slack is created in the other task. Unlike the first three situations, however, this slack is not real slack. If this time is used, the project end date will slip.
Despite the fact that both tasks are resource critical, the current critical path algorithm suggests that only Read is critical. The CPM algorithm only looks at dependencies when it calculates the early and late dates; it does not take resource workloads into account.
Should we revise the definition of the critical path to include tasks that can cause a leveling delay?
Probably not, because the traditional CPM still applies to organizations that can easily add and release resources. A modified critical path—Resource Critical Path (RCP)—is needed for all other organizations with fixed resources. The RCP is defined as the sequence of tasks that determines the project end date, taking into account resource availability. The definition has not changed much from the critical path definition. But other definitions of the critical path, “tasks without slack” for example, do not apply to the RCP, because resource critical tasks can have slack. In the Write and Read situation, the task Write has slack but still drives the project end date and is therefore as critical as Read. Both, however, are resource-critical tasks.
Reasons to Focus on the Resource Critical Path
There are several reasons why we need to enhance CPM.
The Resource Critical Path is the true path that drives the project end date. The objective of project time management is to meet the project deadline, for which we need solid project management tools and techniques.
When crashing a schedule, workload problems may be created if one's only focus is on the critical path. One may work a long time to create a shorter schedule, only to discover that time problems have been changed into workload problems. The short schedule is now not feasible. Assuming unlimited resources encourages the creation of short but unfeasible schedules. In our consulting practice, we often see companies burning out critical resources, especially on IT projects, severely hurting the individual and the organization. The RCP keeps track of workloads continuously, because it is driven by workloads. The RCP therefore allows one to monitor and manage workloads better.
If the relationships between workloads are not made visible, a disastrous domino effect may be triggered when changing a schedule. One cannot realize this if only the conventional critical path is monitored. Exhibit 2 illustrates this domino effect. John's task slips because of illness, which then pushes into Mary's scheduled vacation, causing her task to be even further delayed. By the time she is ready to deliver to Gord, he has been temporarily reassigned to another project and will not return for two weeks. Thus John's relatively minor illness has resulted in big delays in the project because of resource dependencies, not task dependencies, that would not be revealed in the traditional CPM environment.
There is a huge cost involved with erratic workloads, as shown in Exhibit 3. How much does Fred's workload cost before and after workload leveling? Prior to leveling he has some completely free time, yet there are other periods when he is overloaded. It may not be possible to find an alternative use for his free time, and that can carry a significant price tag.
Behavior of the RCP. An analysis of many schedules would show that only when many tasks are done in parallel do resources become more critical than tasks. This will occur somewhere along the traditional critical path, when the RCP takes over from the critical path as shown in Exhibit 4.
The white task bars show the traditional critical path. After resource leveling some of the white tasks are delayed, which are shown as the black task bars. The RCP is the combination of the white critical tasks early in the schedule and all the black resource-critical tasks. If any of these tasks slip, the project will finish later.
Critical Path vs. Resource Critical Path
Each resource can be critical, but often only one resource is driving the project end date. For example, Harry's workload pushes the end date out further than Ed's. When shortening Harry's RCP, you will arrive at a point after which Ed is more critical than Harry. At that point the focus shifts to Ed's workload instead of Harry's. This is a similar phenomenon to what happens when we are working with the traditional critical path and another path takes over from the one we are working on.
Why Companies Should Care About the Resource Critical Path?
Organizations have to optimize the usage of their resources in order to be competitive and cost-effective in the global marketplace—particularly those with scarce resources, such as pharmaceutical or information-system companies. I expect RCP will be a standard for most companies in the near future. Does this mean a well deserved retirement for CPM? The answer is no, because the critical path is still part of the RCP and is still applicable to some organizations.
Why are we only now proposing RCP as a solution to the inherent problems with CPM? The reason is simple: Until recently the computing power was just not available to level the workloads of a large schedule. Once we were responsible for consolidating 9,000 tasks on a 486-computer with Microsoft Project 95. The system could not recalculate the schedule, even without having any resources assigned. That was the end of our lofty intentions to address workload issues. We were pleased just to be able to run the conventional critical path.
THE FUNDAMENTAL MESSAGE in this article can be summed up by yet another acronym: ERIC—Each Resource Implies Criticality. ERIC and the RCP are enhancements to the traditional CPM, and need to be recognized in most of our projects.
Eric Uytterwaal, PMP, ([email protected]) is director of Microsoft Project Certification at the International Institute for Learning in New York. He trains people in project management concepts and in the use of project management software. He is the former president of PMI‘s Ottawa Valley Chapter. He thanks Ed Bottrel, Ed Kilner, John Rakos, Bruce Morris, Don Emmens, and Bill Dawes for their comments on this article.