What is Critical Path Method?
The Critical Path Method (CPM) is a beautiful product of human logic. By highlighting tasks that are most likely to affect the project end date, CPM helps project managers meet deadlines. But often the enthusiasm for CPM wanes when the theory is applied in practice.
Put simply, the 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. The 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 (total float) on a task. Critical tasks have zero slack. Typically, you see that one of the chains of tasks in the network drives the project end date, this is the Critical Path.
CPM with Project Management Software
PM software helps you calculate the Critical Path continuously and can even highlight it in red if you run the Gantt Chart Wizard. By default, the wizard highlights those tasks red that have no slack, and it colours the bars of those critical tasks red. Many times, the result has been disappointing for me when the Critical Path showed up as a partial and fragmented path. It did not seem to find a path that started at the project start date and ran all the way to the project finish date. CPM has run its course, is what I first thought, but then I realized that without CPM there is not much else! So, I went searching for the path and here are my findings. So far, I have found four reasons why your critical path may show up fragmented and as a partial path.
The path will be fragmented if any of the following situations occur in your schedule:
Special Resource Availability
Consider the task to Move an office, that must take place during a weekend. If the resources for the task Move are entered to work only on the weekend, then the task Move is delayed until the next weekend causing slack 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.
Schedule constraints can break the Critical Path. For example, typically business meetings, presentations and other gatherings, which are to occur on a specific date, are entered with schedule constraints. But as fixed dates are entered the schedule, slack is often created on the predecessors of tasks with schedule constraints. The Critical Path can start to look disjointed. In the illustration 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 non-working time. For example, carpet cannot be laid until after the paint is dry. If Drying of Paint’s elapsed duration finishes on a 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.
In this situation, some resources are overloaded. Logically, we then level the workloads to make the schedule feasible. In some instances, however, the over-allocations cannot be solved in any other way than by delaying some tasks. But as soon as a task is delayed, slack can be created on the tasks that competed for the same resource and the Critical Path evaporates before your eyes. You can easily check if this is the case by displaying the task field
- Leveling Delay.
- All tasks that were resource leveled have a non-zero number in this field.
If you have encountered fragmented critical paths and did not understand why it was fragmented, you can check if your Critical Path is jeopardized by one of the previous four causes. Realize that each situation may be in your schedule more than once!!
Application of Critical Path Resource
We have all heard about the Critical Path Method (CPM) that analyses a network of tasks and schedules them to produce the earliest project completion date while respecting the task dependencies. The critical path is the sequence of tasks through the network from the start of the project to the end, in which each task contains zero slack (or float), meaning that a delay in any one of these tasks will delay the project completion date.
For years, we have learned to manage by CPM and track the tasks on the critical path extra closely to ensure there is no delay in these tasks completing. Many people spend much of their time focusing only on the tasks on the critical path, thinking that they are minimizing risk by doing so. To some, this management method may well work, but it ignores risk in tasks not on the critical path. The critical path may well change several times during a project as “off-critical” tasks are delayed such that they now impact the project schedule and appear on the critical path.
Research over the past decade has indicated that there may be better methods of optimizing project schedules which take overall project risk in to account. Eliyahu Goldratt developed the Theory of Constraints (TOC) in 1986. Francis S. (Frank) Patrick, a management consultant and expert on practical applications of Goldratt’s theory, explains that “the basic concept of a system constraint and the TOC Thinking Processes (a set of analytical tools based on cause-and-effect logic), applied to the project environment resulted in the development of the Critical Chain approach to project management.” The Critical Chain Method (CCM) is another way of scheduling project task sequences (considering the common constraint of relatively finite resource availability) to minimize risk in the project delivery schedule.
The CPM does not address resourcing constraints and impact on the schedule, though when commonly applied using tools, most project managers will try to load balance their resource plan which may read just the critical path. The CCM, on the other hand, does address many resourcing issues and does somewhat better than the CPM on resource-constrained scheduling by building a project network based upon both task sequencing and resource dependencies. While the “critical chain” is the resource-constrained critical path, it fails to explicitly capture, like the CPM, the “soft issues”, or human impact of people being scheduled on critical tasks for long periods of time.
Whether we use CPM or CCM, we often construct project networks due to which resource constraints have a key person working nonstop through much of the critical task sequence. While this cannot always be avoided, it can be adjusted to account for the human impact of this level of stress and the resulting increase in project risk. Picture yourself as one of these people — working several weekends in a row, working late into the evening to help make up for delays, trying to meet the project milestones. In some industries, the ability to move a project end date is impossible and the project must make its delivery date. For example, consider a construction project building a speed skating oval for the winter Olympics. The building must be completing prior to the start of the games. It is very common for key people working on these critical tasks to become “burned out” as they sacrifice their family time, their sleep, and maybe even their health for the good of the project. How many times has a key person fallen ill near the end of a project as they have been pushing themselves too hard? How do you calculate and mitigate this risk? As project managers, we should think of this when we build the project schedule, and look for what I call the Critical Resource Path.
If you have key people on a project, try to level their workloads, and then examine their utilization plan. Anyone scheduled at 100% (or more!) utilization over a period longer than two weeks needs breaks scheduled in to the plan. Especially in disciplines such as software development or engineering, where you need a person to be mentally sharp all the time they are working on key tasks, we need to build plans that ensure people can operate at their best. This means we should have periods of less intensity (easier tasks, or lower utilization) to balance periods of high intensity.
The Critical Resource Path is any path (or group of paths) through a project network for which there is a key resource assigned who is planned to be working at high intensity for long periods of time. There is inherently a higher level of risk in scheduling work in this manner, and that needs to be documented and a plan put in place to mitigate the risk by adding scheduled breaks or periods of lower-intensity work. One of the evils of automated load balancing, is that it tends to create periods of consistently high utilization where before there were bursts of intense work with downtime periods in between. Many seasoned project managers know this instinctively, and refuse to use automatic load balancing features on scheduling software, instead preferring to perform manual load balancing to accommodate the working patterns of individuals and the intensity required to perform their assigned tasks.
The next time you build a project schedule where there are key people assigned with no readily-available help, map out one or more Critical Resource Paths through your network and see if there is hidden risk in the plan where you might be working someone too hard. You might be surprised at what you find.