Critical Path Method (CPM) Basics

The following is an overview of Critical Path Method (CPM). The critical path is the longest contiguous path to the end of the project.

Let’s start with one of the best practices of fast teams. Fast teams understood and recognized the gap between the real schedule and the expected delivery date, called the target. They used this gap to create urgency before the schedule slips, in order to take actions to avoid the slip and/or to accelerate the schedule.

Often, the actual schedule is confused with the target. Or, because the target date is so critical, teams are forced to create schedules that fit within in the time specified for its completion. We see schedules “that just fit” and an equal number of teams de-committed to the to the top-down target date because they don’t believe that they can hit it on time.

Let’s apply this core concept using this simple critical path network schedule.

In this example; the target is 2.18. Also, the project is completing on 2.18. This is called a “good” schedule. No worries. In many cases, this is the extent of the planning, given the result is what is desired by top management. The next step is to get team members to “buy in” and “sign up” to the “growth opportunity.” And we wonder by people are so syndical about schedules.

When asked to build a schedule to hit 2.18, the team determined they needed to do three things, task a, b, and c. Each five days in duration and all starting when the previous task finished, called a finish-to-start. Since this is a five-day work week, the total duration of our little project is 15 days. The red tasks are critical, notice they have no float, which is in fact the definition of the critical path. When the final milestone is linked, we see the project finishes on 2.25. Notice the link being made in the bottom view or by dragging and dropping in the gantt view above.

When the team presents their schedule to management they are told, “You got the wrong answer, go back and fix the schedule…” and further, “That this an opportunity, the team must be challenged, raise the bar higher and people will reach for it, and so forth…” They are told they “padded durations” and “to cut durations to make the schedule fit.” It’s relatively easy to make a schedule fit a desired time frame, just cut durations on the critical path. However, this usually results in a team’s quiet de-commitment in the end goal.

Notice the effects of duration change on the end date; increasing and decreasing the overall duration of the project.

The alternative to arbitrary “duration shaving” is to look for opportunities to do things in parallel. This increases risk, but it will also shorten a project duration. This is how fast teams do it. When the dependency link is double clicked, the lag between task a and task b can be modified. A negative 1d lag is entered, causing the project to pull-in one day. The same technique is used on the link between task b and task c.

A new task is added called “float.” It has a 1 day duration and 12 days of float, one day less than the 13 day project duration. It’s floating to the end because it does not have a successor link, which means it can float to the end of the project. The earliest time it can start is 2.7 and the latest time it can start is 2.23. The difference between the early and the late schedule is float.

When the duration is increased to 3 days, the float drops by a corresponding amount. On slow projects, people tend to work to the late schedule, in this case starting on 2.21. Should the task takes longer than expected, it will become the new critical path. This is how slow projects get slower, with hundreds of tasks doing this throughout the project.

By adding a finish-to-start (FS) link between task a and the float task, float’s “float” is eaten up to five days. When it is linked to task c, such that it must finish before task c can start, “float” is now on the critical path. This illustrates two equal length critical paths.

When the negative lag is removed from the link between task a and task b, task b pushes to the right by one day. This makes it the longest path and causes float to have float again. Float has 4 days to accomplish 3 days of work.

When the negative lag is removed from the link between task b and c, the project pushes back out to 2.25 and float has 2 days of float. As long as float gets done on the friday of the second week, the project will stay on schedule. If it slips, then the project slips.

Reducing the duration of float will increase the float time, in this case to 4 days. When the duration is increased to 5 days, the float is gone and the second critical path is visible. When the duration of float is increased to 7, it becomes the critical path and task b has float. This simulates what happens on real projects, the critical path will change every week after each update and pull-in cycle. As the project pulls in and pushes out, so do the tasks that are on and off the critical path. This project pushed out to 3.1.

What are the four ways float can be eaten up? Reduce the duration of task b from 5 to 1 day. Notice “float’s” float is gone.

Reduce the duration of task b from 5 to 4 days, this eats up one day of float’s float.

Add a positive lag to the link between task a and float, 1 day of lag eats up one day of float on the back end. 2 days of lag eats up the remaining day of float, causing two critical paths again. Reducing the duration of task b eats up a day of float’s float and drives it back on the critical path.

While adding a negative 50% lag between task b and task c further erodes float’s float.

To have an accurate critical path and project end date all tasks must have a successor dependency or link. When float’s successor is deleted it floats to the end of the schedule. Here is the problem; when float’s duration is increased to 20 days, the end of the project does not move out to the right. We are not seeing the true critical path.

Lets look at dependencies; the links between tasks. Float’s finish-to-start (FS) link with task a is deleted. In the bottom view, a new link is added between task b and float. This is a start-to-start (SS) dependency. Task b and float must start at the same time. Notice the 2 days of float. When the link is changed to a finish-to-finish (FF) dependency, the float task is pulled to the right to finish when task b finishes. This is a dangerous link since it eats up float time. Fast teams work to the early, not the late schedule.

Lets look at the effects of lag on the schedule. A 25% lag is added to the link between task a and and b. The advantage of “percent lags” are that they are relative, so when the predecessor’s duration changes, the lag proportion is maintained.

A negative 25% FS lag causes the opposite reaction and the schedule pulls-in.

A 2 day lag is added and the schedule pushes out two days since this is the critical path.

A negative 2 day lag is added and the project pulls-in by 2 days correspondingly.

The most disruptive thing to a critical path is a date constraint. Many of the networks we see are loaded with date constraints. Date constraints override the network logic and force a task to happen on the specified date. When the schedule is pinned down like this, it does not move. If it does not move we can’t see if it is slipping or pulling in. We have no early warning system. We can’t track trends and therefore can determine the health of the project; is it getting better or worse over time?

Watch the last milestone “project completion” when the duration of task a is reduced to 1 day, it moves in. Then the duration of task c is reduced to 1 day. You would expect the milestone to pull in to 2.15, but it gets stuck at 2.18. This is caused by a “start no earlier than” date constraint on the milestone “project complete.” This will not let it move earlier in the schedule, when the schedule did in fact pull ahead of the target date of 2.18.

Removing the date constraint will let the milestone flow to the left. Notice the indicator on the far left is gone, this means there are no constraints on this milestone.

A worse constraint is a “must finish on” date. This is often used to force a schedule to fit a desired time frame. After the constraint is added, the warning says that a schedule conflict has been introduced. Basically, the conflict is that 10 pounds of flour just got poured into a 5 pound sack, and 5 pounds just fell on the floor.

The date constraint caused negative float. Notice the late schedule is before the early schedule. This defies time and space and must be corrected. You can’t run a schedule with negative float in it. Negative float, in this case, indicates that this project should have started 5 days earlier in order to finish on 2.18.

The classic top-down way to fix this is to cut the durations on the critical path. Since durations rarely decrease after a project starts, “duration trimming” becomes an exercise in trying to make people feel good at the start of the project — to show that the project is on schedule. This “management technique” has disastrous effects on “professionals” that know their work. We’ve observed the exact opposite effect with teams when this is done to them, they don’t “reach down” or “jump higher,” rather they get “pissed off” and de-commit. Eventually it becomes the “manager’s schedule,” the team does not own it anymore, yet management does not realize until the first major milestone is missed.

Notice, by cutting durations the negative float is gone. The project finished on time and everyone is happy, except the people that actually have to do the work.

Be careful, date constraints can be introduced without knowing by manipulating the start and finish dates below.

Date constraints can also be introduced by dragging and dropping the bars on the gantt chart.

As discussed earlier, fast teams find ways work in parallel or work differently. They know the difference between “team-driven innovation” and “top-down management imposed” edicts, which rarely achieve the desired outcome.