When Primavera Systems developed Primavera Project Planner in 1983, it pioneered a brand-new idea. Since I had just completed my first CPM Schedule two years before the graduating from university, I believed I had a solid grasp of the fundamentals of scheduling. The consulting company that employed me as a scheduler then possessed a proprietary software application, which I used for several years. But in 1987, when my employer converted to Primavera Project Planner, I discovered an alternative method of CPM scheduling.
All of my earlier plans were predicated on a flexible project finish date. In other words, the project's completion date varies as work progresses. I didn't realize that the early dates weren't all that useful because I didn't know any better. The early adopter is on the crucial route, 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?
With the help of Primavera Project Planner (also known as "P3"), limitations might be imposed on certain tasks or the entire project. The schedule was affected by these "hard stops." The late start and late finish dates essentially became fixed dates (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 found the notion of holding the final thing on the timetable in place to be intriguing.
For those of you who are familiar with forward and backward passes, you know that the length of the project is determined by the forward pass; this is why the term "longest path" is used in Primavera software in place of "critical path." The float for each action is determined by the backwards pass. The longest path will always have 0 days float if there are no restrictions because both the forward and backward passes provide the same outcome. For instance, what shows as Day 70 forward also shows as Day 70 backward. 70 - 70 = 0.
However, if a project is running late, we can see that Day 70 in the future is actually Day 65 in the past. We have a float of five days. Additionally, we have to get there on time. 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 Training in Noida, "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.
The zero days of float when we are on or ahead of schedule is what I like best about "Finish On or Before." My basic project philosophy is as follows. To finish on time, you must set aside time to work ahead of schedule. To support this idea, we might add a contingency or cushion to the timetable, although projects rarely just stay "on" schedule. Activities with zero days float are approaching, which makes those jobs seem more urgent to subcontractors and vendors. The general contractor and owner, presumably, are aware of the truth.
Constraints generally are criticised heavily for sequestering float in favour of the general contractor. It's true that by putting a "Start On or Before" constraint on any action, we can artificially delay the start date. Regardless of the shortest approach, the general contractor is essentially picking a late start date for the activity. It is unwise to manipulate the float in this way, and for good reason. A task's downstream impact on other tasks should be accurately reflected in the float provided on that activity.
Unfortunately, some owners don't understand the subtleties of restrictions and instead severely limit their use. Yes, we can do a quick comparison between the completion date of the present project and the date in the previous schedule, but that only looks at where we are now and not where we need to be in the next weeks. Numerous tasks may be behind schedule, some more so than others. The worst of the worst, which I liken to a game of "whack a mole," where negative float is being pounded, needs to be handled first.
However, I do not support the unrestrained usage of limitations. I pose the following query in my advanced P6 training seminars based on the finding that:
"An activity has just one predecessor, but it is not a driving predecessor. How is that possible?"
In most cases, the start or end date of the subsequent activity is determined by at least one previous work. If not, what exactly motivates the successor? Granted, resource levelling or incompatible calendars might have an impact. The successor is, nevertheless, most frequently attributed as being motivated by a constraint. As a result, the path may now begin with the limited activity, breaking the critical path.
The critical path is described as a continuous, or unbroken, series of tasks that must be completed between the current Data Date and the project's end date. Only the days specified by the activity calendars would be off from work. As a result, we must advance along the vital road every working day. The essential
A few years ago, I was requested to meet with an engineering firm in the (San Francisco) Bay Area to go over one of their schedules. On the phone, they admitted that they were unable to locate the essential path. Hmm. That sounded like a difficult task. How on earth could finding the critical path be so challenging? However, I didn't need to be particularly familiar with their timetable to assume that there were too many restrictions in place.
You may define "too many" differently, but I think we can all agree that 150 constraints in a schedule is a bit excessive. I therefore calmly explained why 99.9% of them weren't required. The engineers refused to correct it or follow the logic.
I can get by on almost any project with just the final activity's "Finish On or Before" restriction. Any additional restrictions must be supported by a clause in the contract, such as an interim goal that carries the risk of liquidated damages. In a CPM Schedule, there are frequently quite a few milestones, but I'm just interested in limiting the ones that are difficult for the contractor. These are dates we don't want to miss.
More CPM Schedules are likely reviewed by the U.S. Army Corps of Engineers than by any other American organisation. It is therefore reasonable to assume that they are the best at understanding software settings. Each project has two constraints: one that says, "Start On," for the first activity, and one that says, "Finish
Now, if the Data Date coincides with the project start date, I personally don't think a start restriction is required on the first activity, thus I could live with one constraint on the last activity. However, since I am using the start constraint, I will forward the Data Date by a few weeks to ensure that the Data Date line does not obstruct the start milestone. It merely appears better.
To summarize, activities that are behind schedule change the timeline when the project's end date is constrained. The latter dates fall before the older ones. In the 1980s, I spent a lot of time attempting to convince skeptic contractors and owners of this.
Also Read: Primavera Training in Delhi
