Common CPM Scheduling Mistakes

/

Critical Path Method (CPM) Scheduling mistakes we observe in many schedules, those built prior to lateralworks FTTM Scheduling training. These include 1) no contiguous critical path, 2) negative float, 3) date constraints, 4) wrong updates (of actual progress), and 5) no successors. Each individually or together result is inaccurate / wrong critical paths, and therefore potentially wrong dates for key milestones. The result is a schedule that can’t be used as a management tool and can not be trusted. This post discusses each problem.

There are four (4) serious technical scheduling mistakes we see repeatedly in our consulting practice, working with teams to accelerate new product development projects. These mistakes cause the critical path to be distorted, to the point where the schedule is not usable.

image.png

The goal is to use the schedule to accelerate the project. The objectives are to use it to accurately predict the project end date, improve the quality of the schedule, and to increase manageability of the project using quality schedule data.

All four of the problems I’ll discuss cause the schedule to have no contiguous critical path. The critical path is the “longest pole in the tent,” so if the path to the end of a project is incorrect, then the schedule is of no value to be used to drive a project.

We see many CPM (Critical Path Method) schedules that are technically wrong, or in other words… they are giving the wrong end date for the project because of technical mistakes in the construction and maintenance of the schedule data.

Let’s look more closely at the four common errors. They are…

  • Date Constraints

  • Negative Float

  • Wrong Updates

    • Wrong Updates include tasks with actual progress not to the current date, or updated out of sequence — which also causes negative float, and updates of progress beyond the current date into the future, and

  • No Successors

All four of these problems result is schedules that can give you the wrong answer — kind of like an accounting system that generates the wrong financial statement because of a math error. You would not knowingly publish erroneous financial statements, so why use erroneous schedules to make decisions?

Date Constraints

We want a schedule to ebb and flow because we want it to tell us if the project is slipping or accelerating. We want early warning while there is enough time to make corrections. The schedule should not be restricted by date constraints. Notice how the schedule end date moves in and how as I change duration of task 1.

Now watch what happens when I introduce a date constraint. I’ll add a “start-no-earlier-than” constraint on task 2. This causes the critical path to be broken and to start at task 2. Task 1 now has float and we can’t see what is causing the delay in task 2’s start. When I remove it, the schedule pops back. Rather than a date constraint, I should have added a task between 1 and 2 to indicate the work that pushed out task 2. Then it could be tracked and we could see the contiguous critical path from the current day to the end of the project.

This “must-finish-on” constraint will introduce negative float. Note the complicated error message, basically this is telling you that there is no longer enough time to do task 1, task 2, and task 3 assuming they all required 5 day durations and finish-to-start dependencies.

Negative Float

Technically negative float means that the late schedule is before the early schedule. Negative Float is indicated as red lines before the task with a negative value, these are the days that don’t fit within the available time frame. So in this example I’d have to start the project 5 days earlier than today which is the dotted red line. Since it is already today, I can’t turn back time and start earlier. Schedules can’t be run with negative float. It is like putting 10 pounds of flour in a 5 pound sack… 5 pounds just falls all over the floor.

Of course you can cheat the schedule to remove negative float by arbitrarily reducing the durations on the critical path to force-fit the schedule within the available time frame. The problem with this is that the team defined the 5 day durations and the shorter ones may not be feasible, and task 3 still has a date constraint, so the project can’t move in and out as things change. When the end does not move, you can’t determine the health of the project through studying the movement trends of the final milestone versus its committed target date.

Wrong Updates

This is perhaps the most common problem we see. Incorrect entry of actual progress on tasks. When I make task 1 50% complete and task 2 75% complete, then add a date constraint to task 3 and update it to 25% complete… I can completely screw up the critical path. Microsoft Project lets you do it, even though all the data entered is wrong.

Notice what I did to the schedule in the bottom pane. Task 1 is 50% complete, yet the remaining duration should be on the right side to the current date or dotted red line. Task 2 has updated actual progress into the future past the current date — which is impossible and task 3 was forced by a date constraint and is causing negative float. All wrong.

Here is a correct update using our wizard, which has more than 30 rules to prevent you from making the mistakes I just illustrated.

For Task 1 we will say is started, but is not finished. We will say it has 2 days remaining. Notice how it correctly put the remaining 2 days on the right side of the current date. This schedule has a five day work week, which is why the weekend is considered a non-work day.

I’ll say task 2 is started, not finished with 1 day remaining. This will also introduce negative float which we will fix later. This is called an “out of sequence update,” since task 1 was planned to finish before task 2 was to start, yet in reality it didn’t.

I’ll also start task 3, and say it has 4 days remaining to complete.

Notice that all the green bars of actual duration line up to Friday night and all the remaining duration is on the right side of the current date, plus the weekend. Actual progress can’t be in the future and must come up to the current date in order to have the correct schedule.

I can fix the negative float problem by deleting the Finish-to-Start dependencies that are no longer valid, but this introduces the forth common mistake — no successors.

No Successors

When I link task 1 and 2 into the final milestone, I’ve corrected the problem. I turn on multiple critical paths to see the critical path to task 5. The critical path was somewhat hidden because task 4, the target, was fixed in time past the end date for task 5. So in effect the critical path was to the target, which has a date constraint holding it in time.

Targets can have date constraints because they are not connected to any of the tasks in the network. The target is the reference point by which you monitor project health by comparing the predicted end data with the target date to see the gap. We want to know the trend over time to see if that gap is getting larger or smaller.

Starting again, I remove the connector between task 2 and 3. I’ve lost my critical path. Also, if task 1 or 2 grew in duration I would not see the impact on task 5 the end milestone. Missing successors will kill the schedule and can be very dangerous since it may result in a project end date that is wrong. We’ve seen schedules slip many months when these missing successors are added. Most of the time they are missed by simple human error.

Fortunately, we have a tool that checks for all four of these problems called ScheduleAnalyzer, which is the subject of another screencast. But these 4 are the most common problems we see causing CPM schedules to produce the “wrong answer.” When they do, you can’t use these bad schedules to accelerate a project, since the schedule no longer reflects what is really happening on the project. First you have to identify where these schedules are wrong, then you need to fix them.