Primavera Systems introduced a novel concept when it released Primavera Project Planner in 1983. Having just graduated from university two years earlier with my first CPM Schedule already under my belt, I assumed I understood basic scheduling concepts pretty well. I then spent several years using a proprietary software program owned by the consulting firm that hired me as a scheduler. But when my employer switched to Primavera Project Planner in 1987, well, I learned another approach to CPM Scheduling.
All of my early schedules relied upon a floating project end date. That is to say, the project end date changes depending on progress. Not knowing better, I did not consider that the early dates were not very helpful. On the critical path, the early start/late start dates are identical. Likewise, the early finish/late finish dates are the same. So how do we get back on schedule once there are delays?
Primavera Project Planner (or "P3") allowed constraints to be placed on individual activities or the project overall. This created "hard stops" in the schedule. The late start and late finish dates became fixed dates, more or less (I say "more or less" because progress and logic changes mean that the late dates will often change over the life of the project). But in particular I was intrigued by the idea of the last activity in the schedule being held in place.
Those of you familiar with forward and backward passes understand that the forward pass determines the length of the project - hence the phrase "longest path" that is used in Primavera software in lieu of "critical path". The backwards pass determines the float on each activity. Absent any constraints, the longest path will always exhibit zero days float because both the forward and backward passes generate the same result. For example, what exhibits as Day 70 going forward is also Day 70 working backwards. 70 - 70 = 0.
But on a project that is behind schedule we might see that what is Day 70 going forward is Day 65 working backwards. We have -5 days of float. And we need to reach that point in the schedule by Day 65 if we want to get back on schedule. This assumes of course that we have constrained the last activity in the schedule. In today's Primavera software, "Finish On or Before" is the preferred constraint. If we are on track to finish early, the float will be zero days because the backwards pass starts with the finish date of the last activity in the schedule. When we are behind schedule, the constraint date is the starting point for the backwards pass.
What I really like about "Finish On or Before" is the zero days of float when we are on or ahead of schedule. I have a basic philosophy about projects. You have to plan to finish early in order to finish on time. We might insert a contingency or buffer into the schedule to reinforce this concept, but projects rarely just stay "on" schedule. Subcontractors and vendors see activities with zero days float coming up, which makes those tasks seem very important. The general contractor, and presumably the owner, know otherwise.
One of the biggest criticisms of constraints in general is that they sequester float for the benefit of the general contractor. True, we can create an artificial late start date for any activity by assigning a "Start On or Before" constraint. The general contractor is literally choosing a late start date for the activity irrespective of the longest path. Manipulating the float in this manner is certainly frowned upon, for good reason. The float displayed on an activity should accurately reflect how this task affects other tasks downstream.
Unfortunately, some owners fail to appreciate the nuances of constraints and instead restrict their use altogether. Yes, we can compare the current project finish date to the date in the previous schedule, but that is a cursory examination that does not address where we need to be in the next few weeks. We may have dozens of activities that are behind, some more than others. The worst of the worst need to be addressed first, what I think of as a "whack a mole" game where negative float is being hammered.
But I am not advocating unrestricted use of constraints. A question I present during my advanced P6 training classes is based on the following observation:
"An activity has just one predecessor but it is not a driving predecessor. How is that possible?"
Under normal circumstances there must be at least one predecessor task that drives the start or finish date of the next activity. Otherwise, what exactly is driving the successor? Granted, it could be affected by resource-levelling or mismatched calendars. But the most common explanation is that the successor is being driven by a constraint. This can break the critical path so that the path now starts with the constrained activity.
We speak of the critical path as being a contiguous, or unbroken, string of activities from the current Data Date to the end date of the project. The only nonwork days would be those defined by the activity calendars. Therefore, we must make progress along the critical path each and every work day. The critical path is a difficult taskmaster, as it should be.
A few years ago an engineering firm in the (San Francisco) Bay Area asked me to meet with them to review one of their schedules. "We can't find the critical path", they told me over the phone. Hmm. That sounded like a challenge. How on earth can the critical path be all that difficult to locate? But I did not need to know much about their schedule to presume that too many constraints were being used.
Now, you might have a different definition of "too many" but I think we can all agree that 150 constraints in a schedule is a bit much. So I patiently explained why 99% of them were not necessary. The engineers refused to trust the logic, or fix it for that matter. A typical example was a predecessor with a Friday finish constraint followed by a successor with a Monday start constraint. Um. Finish to Start relationship?
On nearly any project I can live with just the "Finish On or Before" constraint, placed on the last activity. Any other constraint should be justified by a contractual requirement, such as an intermediate milestone that can generate liquidated damages. There are often quite a few milestones in a CPM Schedule but I am only interested in constraining the ones that cause pain for the contractor. We don't want to miss those dates.
The U.S. Army Corps of Engineers probably reviews more CPM Schedules than any other agency in the United States. So it seems rather safe to say that the USACE understand software settings as well as anyone. The USACE require two constraints on each project: a "Start On" constraint on the first activity, and a "Finish On or Before" constraint on the last activity. Additional constraints require approval.
Now, I personally don't feel that a start constraint is necessary on the first activity if the Data Date matches the start date of the project, so I could live with one constraint, on the last activity. But since I am using the start constraint I will move the Data Date up a couple of weeks so that the start milestone is not obscured by the Data Date line. It just looks better.
So, to wrap this up, when the project end date is constrained, activities that are behind schedule flip the script when it comes to dates. The late dates are earlier than the early dates. I spent quite a lot of time explaining this to doubtful contractors and owners back in the 1980s. Surely the software is broken! But the logic is sound. The late dates, being constrained by the last activity, are indicative of how to get back "on" schedule. Following the early dates would be a mistake, as they would maintain the status quo.
This scenario introduces the inverted cash flow curve, which I always find interesting. In the graphic below you can see the late curve rises above the early curve:
