Expert, flexible training in the use of the most powerful scheduling software program in the world: Primavera P6 by Oracle. Call today! (916) 779-4145
Primavera Scheduling

All posts in Constraints

When P6 Late Dates are Early

Categories: Constraints, Late Dates, P3, P6 Professional
Comments Off on When P6 Late Dates are Early
Primavera Scheduling

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: 

Primavera Scheduling
Based on everything I have discussed, these curves make perfect sense. We need to perform more work than required by the "early" dates. Otherwise, we finish late. Which means we also need to display the late dates to avoid landing on the "early" curve and therefore finishing late. Yet it still confuses people nearly forty years after I issued my first schedule with negative float.

Primavera SchedulingProper scheduling requires an understanding of driving relationships. These are the most important relationships in the schedule because they drive the start and finish dates of the activities that follow. So it stands to reason that all critical path relationships are driving. In Primavera P6, driving relationships appear on the Gantt Chart as solid lines: red for critical path and black for non-critical activities. When “crashing” the schedule we must focus on driving relationships in order to move up the start dates of critical path activities, thereby shortening the project duration.

Now, if every activity had only one predecessor we could ignore talking about the counterpart to driving relationships: the non-driving relationships. After all, if there is only one person in front of you performing a task, how could they not be driving your work? Well, there is one possible exception. Activity constraints can, in some situations, drive activity dates. For example, if the successor wants to start on August 3rd because the predecessor finishes the day before (i.e. the classic Finish-to-Start relationship) adding an activity constraint that pushes back the start date means that the constraint is driving, not the predecessor.

Finish-to-Start relationships make it easy to separate driving from non-driving relationships. If Activity C is waiting for both Activity A and Activity B to finish, whichever predecessor finishes last is the driving relationship. (I am assuming that both relationships have zero lag, but it is considered bad form to use any lag other than zero days with Finish-to-Start relationships). Where it gets more interesting is when the predecessor relationships are Start-to-Start and Finish-to-Finish. So here is my favorite example from our P6 102 class:

  • The predecessor has a duration of 20 days
  • The successor has a duration of 15 days
  • There are two predecessor relationships coming from the same activity
  • One of the predecessor relationships is Start-to-Start with a lag of 8 days
  • The other predecessor relationship is Finish-to-Finish with a lag of 5 days

Which predecessor relationship is driving?

Keep in mind there is only one predecessor activity, but there are two relationships. I will always add a Finish-to-Finish relationship to a Start-to-Start relationship. It is my insurance policy. I doubt that most Primavera users realize that if you only have a Start-to-Start relationship, the predecessor can finish on the last day of the project without causing a delay. For this reason I consider the Start-to-Start relationship by itself to be an open end – even though technically the predecessor does have a successor.

To be clear, “open end” refers to an an activity that is missing a predecessor or successor. The Schedule Log will display activities that are missing predecessors or successors under the “Warnings” section.

Non-driving relationships appear as dotted lines on the Gantt Chart. Pro tip: the Time-Scaled Logic Diagram (TSLD) in Visualizer (Tools > Visualizer) allows users to choose different colors and line styles for driving and non-driving relationships. There is also the option to show only driving relationships. TSLD also has the unusual feature of placing more than one bar on the same row if the bars do not overlap. This reduces the number of rows in the printout substantially.

Getting back to my earlier question, the Finish-to-Finish relationship is the driving relationship, and the Start-to-Start relationship is non-driving. Here is a visual representation:

 

Note that all durations are in calendar days to make the ordinal days and working days match.

Let’s take a look at the math. The successor is scheduled to start 8 days after its predecessor. The successor has a duration of 15 days. So the successor finishes on day 23 (8 + 15) when only this relationship is considered. But the successor is also supposed to finish 5 days after its predecessor, and the predecessor has a duration of 20 days. As a result, the successor now finishes on day 25 (5 + 20). The Finish-to-Finish relationship adds two more days to the sequence between these activities.

We should also realize that the successor cannot start 8 days after its predecessor because the Finish-to-Finish relationship is dragging the successor by its tail. P6 has a dilemma. The successor’s 15 day duration must be contiguous (other than on specified non-work days according to the calendar). In order to meet both the Start-to-Start and the Finish-to-Finish requirements, the successor would need to be two days longer. In which case both relationships would be driving.

The original Primavera scheduling program, P3, had an option to allow non-contiguous durations. P3 would “stretch” the successor so that both relationships could be fulfilled. But the displayed duration of the successor would not change. I suppose this did confuse some people because the length of the activity bar was occasionally quite exaggerated compared to the displayed duration. P6 dropped this feature, perhaps for good reasons. We must now recognize that not all of our specified conditions can always be met.

Driving and non-driving relationships can also be identified in the Activity Details at the bottom of the Activities window. Select the Predecessors, Successors or Relationships tabs. The columns shown in these tabs can be customized to show the Driving box, which is found in the General category of columns. I always display this box. The example I provided is rather simple because there is only one predecessor activity. Imagine if there are several predecessors starting on different dates and more than one relationship type!

Schedules can get very complex rather quickly because of the available relationship types. Ah, the old days when all relationships types were Finish-to-Start, things were rather simple. What we called the “I-J” or “Activity-on-Arrow” method of scheduling basically disappeared in the mid-1990s. But I am still a big fan of Finish-to-Start relationships because they are the most conservative relationships. I try to make about 80% of my relationships Finish-to-Start.

Keep in mind that as logic and durations are revised, what used to be driving may now be non-driving, or vice versa. Schedules are never static. Out-of-sequence work can also create new situations not previously anticipated. Similarly, new activities representing scope changes or unexpected events can alter the importance of relationships. But ultimately, if the start date of a task just seems wrong, driving relationships must be analyzed first. Don’t let the non-driving relationships become a distraction.


Why Make Open-Ended Activities Critical?

Categories: Constraints, Critical Path, P6 EPPM, P6 Professional, P6 Tricks, Schedule Options
Comments Off on Why Make Open-Ended Activities Critical?

Primavera P6 Professional is obviously a very powerful scheduling program so naturally some of its features exceed the needs of the typical project. I have consulted on projects that span as little as 35 hours to as many as 50 years. Different industries have unique requirements for their schedules as well. Primavera P6 is designed to handle a wide variety of projects. Today I would like to address my reasons for using a feature in Primavera P6 that is rarely used by the typical scheduler: Make Open-Ended Activities Critical. You will find this feature under Schedule Options (Tools > Schedule > Options).

The concept of making open-ended activities critical was introduced many years ago in Primavera P3. And for the longest time I dismissed it as a quirky feature surely not applicable to me. After all, why would I promote an activity to critical status solely because it is missing a successor? That seems akin to me declaring myself the winner of a contest that no one else entered.

Some of my colleagues back in the 1980s figured it was an en easy way to identify activities that should not be critical. Okay, that seems backwards, but the idea was that if some task showed up as critical that did not seem “right” the scheduler would investigate further. But Primavera P3 had a report similar to what we call the Schedule Log in Primavera P6 that was a more definitive (and easier) way of identifying open ends in the schedule. With this in mind, making activities that are missing a successor critical did not seem like the best approach to finding open ends.

I started my scheduling career working solely on construction projects so my viewpoints towards Primavera P3 were based on a single industry. Years later, when I began consulting on a wide-variety of projects I realized another purpose for Make Open-Ended Activities Critical. For example, let’s say I am a manufacturer trying to track progress on several production lines. I would like each production line to have its own critical path, or what Primavera P6 refers to as Longest Path. But this would entail making each production line a separate schedule.

It would be a lot easier to track progress, however, if I incorporated all of the production lines into one schedule. That way I would not have to keep opening up another schedule to track progress. And P3 only allowed four schedules to be opened simultaneously. (Some of you P3 users undoubtedly remember the master and sub-project concept from P3 which was another alternative to what I am describing). But how could each production line have its own critical path without creating separate projects?

Yep. Make Open-Ended Activities Critical. See, by not linking the production lines to each other they would all have an open end at the end of their sequence. So every production line now has critical activities. The float values are not based on the longest of all the production lines. Each production line has activities with zero Total Float. Problem solved!

The concept I just described works the same in Primavera P6 as in Primavera P3. You might be thinking that each production line could have a constraint on the final activity to create zero Total Float and then link the final activity in each production line to some final milestone. Yes, that will work too, smarty pants! It also means that additional open ends do not need to be introduced into the schedule.

Another reason for Make Open-Ended Activities Critical is relevant to projects in any industry. One of my clients currently expects his project to finish early. Owners often don’t allow the original plan to show an early completion date because it might become the basis of a claim (“I planned to finish early and you stopped me”). In this situation the owner allowed early completion. So my client inserted two finish milestones in his schedule: “Projected Finish” and “Final Completion”. The latter milestone matched the contractual finish date.

The “Projected Finish” milestone had no constraint since the date could obviously slip without any ramifications. The “Final Completion” milestone had a Finish On constraint (Mandatory Finish also works) so the date could not move at all. But as you might have guessed, this meant that only the “Final Completion” activity appeared as critical in the schedule. The earlier milestone and all of the activities linked to it (directly or indirectly) carried Total Float values based on the later milestone.

A critical path consisting of just one (the last) activity) would obviously be acceptable to no one. But the solution was quite clear to me. While my client had linked the “Projected Finish” milestone to the “Final Completion” milestone (to avoid unnecessary open ends) we need the “Projected Finish” milestone to have no successor. Then, by choosing Make Open-Ended Activities Critical in the Schedule Options the Longest Path of activities leading up to “Final Completion” all had zero Total Float. Bingo.

Below is how the schedule looked with “Projected Finish” linked to “Contractual Finish”. Not having open ends means there is no logical critical path. Also, the “Projected Finish” milestone is a non-driving predecessor to the “Contractual Finish” milestone, as evidenced by the dotted relationship line:

Primavera Scheduling

By deleting the relationship between “Projected Completion” and “Final Completion” and choosing to Make Open-Ended Activities Critical under Schedule Options, the activities leading up to “Projected Completion” are now critical:

Make Open-Ended Activities Critical is not always a necessary feature, but as you can see, it certainly does have a purpose.

 


What is a “Planned” Date in P6?

Categories: Constraints, P6 EPPM, P6 Professional, Primavera P6, Schedule Options
Comments Off on What is a “Planned” Date in P6?

Primavera P6 has quite a few date fields that are often misunderstood. Perhaps no date field is stranger than the “planned” date. To begin with, there will always be a Planned Start and a Planned Finish date associated with every activity. In a schedule with no progress (or what we would traditionally call the “baseline” if P6 did not use this designation for target schedules) the following is always true:

  • Planned Start = Start
  • Planned Finish = Finish

Once progress is recorded, however, all bets are off. The planned dates will not reflect actual dates, for example. Primavera P6 shows actual dates in the Start and Finish columns, making it easy to see which activities have progress (take that, Microsoft Project!) without having to add the Actual Start and Actual Finish columns. Space is always at a premium in a printout so not having to add the actual columns is a nice benefit.

Here is where it gets interesting. Changing the Planned Start or Planned Finish date on an activity with no progress will change the Start and Finish dates and likewise move the bar in the Gantt Chart. The rules are:

  • Changing the Planned Start changes the Start date, even if the Planned Start is before the original Start date
  • Changing the Planned Finish moves the Finish date and changes the Original Duration to match
  • Changing the Planned Start and Planned Finish will move the Start and Finish dates accordingly
  • No other activities are affected by changes to the Planned dates of an activity

None of this will happen, however, if the “Schedule automatically when a change affects date” scheduling option is selected. This is because scheduling the project wipes out the changes made to the Planned dates. These are not constraints, after all. The logic was never modified. Which may seem like Planned dates are a cruel trick.

Well, we create logic for a reason. Moving bars around is not scheduling. Logic is supposed to drive dates. A few constraints are okay – although some owners are adamant about having none – as long as they do not cause an interruption to the critical path. Postponing the start of a critical activity would obviously make no sense.

Note that if you change the Planned Start or Planned Finish of an activity with progress, nothing happens at all. The Planned dates will not change.

Changing the Planned dates, really, is mostly a bad idea. But let’s say we all agree that some of the dates in a schedule are not right. So we massage the dates using the Planned columns and then create a baseline. Using the baseline as a guide, we then modify the logic and durations to achieve the new dates. Sort of like tracing a drawing with velum paper.

Comments or questions? Please feel free to contact me.


The Case Against “Must Finish By”

Categories: Constraints, P6 Professional
Comments Off on The Case Against “Must Finish By”

When setting up a new project, the user will be faced with the “Must Finish By” option. Our advice is to leave it blank. Yes, every project has a finish date. Otherwise, it does not meet the definition of a project. That is to say, a project must be: (1) unique, (2) have a specified time frame, and (3) a defined scope of work. Unfortunately, projects often end up with a longer time frame and increased scope, but that is a subject for another day.

To review, the “Must Finish By” constraint is presented while setting up a new project or by selecting the Dates tab in the Project Details Window after the project has been added to the EPS. The former situation is presented below:

Must Finish By_1

 

 

 

 

 

 

 

Which begs the question, what is “Must Finish By”. Well, it is basically a project-level constraint that affects all activities. When this constraint is used, no activity can finish after the date selected. In theory, a date prior to project completion could be selected in order to determine how many activities have slipped past a particular date.

Without further ado, here is why we don’t use the “Must Finish By” option:

  • If the user selects a date beyond the latest calculated date, the critical path will have positive Total Float. Showing positive Total Float is a little like putting candy  in the reception area – it tends to disappear. The owner and subcontractors are now aware that activities on the critical path are not so critical any longer. And because Total Float typically belongs to the project, any party is entitled to use the Total Float at their discretion. Without this constraint, the critical path has zero (0) Total Float, even if the project is ahead of schedule.
  • The Schedule Log does not show the “Must Finish By” constraint. Only activity constraints are listed in the Schedule Log, so it is easy for a user to forget (or not realize) that a project constraint has been applied. This can create confusion, especially when the “Must Finish By” constraint is generating negative Total Float. The Schedule Log will not indicate that any constraints are “unsatisfied” because, again, only activity constraints are considered.
  • Activity constraints are revealed in the Start or Finish column (depending on the type of constraint) with an asterisk (*). This feature dates all the way back to P3. There is one exception to this rule – the “As Late as Possible” constraint – but otherwise this is a rather obvious hint that a constraint is being used. Note that in P3, the asterisk appeared in the Early Start or Early Finish column, which is a good reason not to use those columns any longer.
  • The “Must Finish By” constraint does not have a calendar to calculate from so it defaults to midnight of the day before. So a “Must Finish By” date of January 12, 2016 will generate one (1) day of negative Total Float – even when the project is actually finishing on that date. Why? Because the project must finish by midnight the day before to avoid being considered behind schedule. The user must either select the day after the scheduled project finish date as the “Must Finish By” (which makes it seem like the user is unaware of the real contract end date) or choose to show activity durations in hours so that the time of day can be changed. This is illustrated in the next two screenshots.

Must Finish By_2

 

 

 

 

 

 

 

 

 

 

Must Finish By_3

 

 

 

 

 

 

 

 

 

 

This is a lot of extra effort just to adjust the date, and many contractors have no desire to show the time of day in their schedules. In a closed network, placing an activity constraint on the last activity is simply a better solution. An activity constraint is also easier for everyone to see and therefore monitor. Any questions or comments? Please feel free to contact me.