Project Constraints and the Longest Path

If you want to optimize your schedule it is advantageous to look to shorten activities that are along the critical path. But what do you do if you have a project constraint that causes your scheduling software to either display multiple critical paths or completely obscure the true critical path?

It is generally stated that an activity is critical if it cannot be delayed without impacting the schedule end date. Well, there are exceptions to every rule. And in this case the exception is that the activity may not be delayed without affecting an activity constraint date, such as a ‘Finish On or Before’ constraint date. Here the critical activity is not causing the project end date to slip, but an interim activity constraint date.

.....

Read the post on Ten Six

Is Retained Logic the best Scheduling Option in Primavera?

Written by Amit Parmar

Primavera has three Scheduling Options to choose from when you are scheduling your project. Retained Logic is the default scheduling option. When you are building a Baseline, the default option works fine. But things change when you start updating your project, activities start getting delayed and do not get executed as planned.  You then have to make a decision on whether you want to continue using Retained logic or choose Progress Override or Actual Dates as your Scheduling Option. A lot has been discussed over the internet forums on which option is the best for a project and Retained Logic has won with an overwhelming majority. But I have a different opinion.

Has your project ever followed the exact logic that you planned in your baseline?

If your project has followed the exact logic as planned in your baseline then you are an awesome planner and you don’t need to read this blog post any further. But in my experience, on most of the projects activities don’t get executed exactly as planned in the baseline. Some start earlier than planned, some start later than planned and some might get delayed during execution. This is where Scheduling Options in Primavera play an important part. Choosing different scheduling options changes the way Primavera’s scheduling engine executes its calculations for Forward Pass and Backward Pass. This then changes the way dates are calculated for the activities in your project and it has an impact on your completion date.

The three scheduling options available in Primavera are:

• Retained Logic

• Progress Override

• Actual Dates

For this post let us assume 3 activities with names; Activity A, Activity B, Activity C. They are connected by a Finish to Start (FS) relationship. We will update them out-of-sequence and schedule our project with all the three scheduling options and see what impact does it have on our project.

1) Retained Logic – assumes that you wish to Retain Logic of your relationships when you are scheduling your project. This means that the remaining duration of an in-progress activity is not scheduled until all predecessors are complete.

Retained Logic- Retains the logic of your relationships while scheduling the project

Let’s take a look at an example and see how this works. We have updated our activities out-of-sequence on the following dates:

You can see above that Activity B has been updated out-of-sequence but Activity A is still in progress. We then choose Retained Logic as our scheduling option and schedule our project.  Due to Retained Logic, Primavera assumes that we are retaining the logic of relationships between our activities even though the activities are being updated out-of-sequence. This means that Primavera calculates the Remaining Start of Activity C as per Finish-to-Start logic with Activity A (and not Activity B).  This makes Activity C non-working between the period of 1-Feb-15 to 5-Feb-15. The non-working period can be seen in the Gantt chart below:

Lets review the calculations for this example; the Data Date for our project is 1-Feb-15. The scheduling engine calculates that for Activity A Remaining Early Finish is 06-Feb-15, due to this the Remaining Early Start for Activity C is calculated to 6-Feb-15. The scheduling engine is told to retain logic for the relationships and picks the Remaining Early Start for Activity C after Remaining Early Finish of activity A because Activity B is already complete.

The non-working period calculated due to Retained Logic can be misunderstood as, no work will be performed on Activity C between the time period of 1st Feb-15 and 05-Feb-15. This non-working period also adds an extra 5 days to the completion of the project. Now, the purists can make an argument that in such cases we should change the logic of the activity because the logic has actually changed. But if your contractual obligations do not allow you to make changes to your current project without approval of the client then it might force you to keep your relationships fixed and decrease the Remaining Duration on the activity to adjust the non-working period.

2) Progress Override – this scheduling option assumes that network logic can be ignored in case of out-of-sequence activities and the remaining duration of the activity can be scheduled without delay. This means that Primavera’s scheduling engine will ignore the relationship logic between the activities and schedule the activities without any non-working periods.

Progress Override – Assumes that relationship logic can be ignored for out-of-sequence activities

For our example this means that, Activity C will not have a non-working period and the remaining duration of the activity will be scheduled from the data date of the project as seen in the screenshot below.

Lets review the calculations for this example: The Date Date for the project is 1-Feb-15. The scheduling engine calculates that for Activity A Remaining Early finish is 6-Feb-15 and Activity B is completely finished. Due to this the Remaining Duration of  Activity C is scheduled from 1-Feb-15 and the relationship logic from Activity A is ignored. Since there is no non-working period in Activity C, it finishes on 19-Feb-15.

It is clear from the above example that Progress Override reduces the project duration by 5 days by not adding the non-working period. This seems logical according to the work that is being done on the project as you might be working on Activity C continuously and unlike Retained Logic there will be no non-working period.

3) Actual Dates – this scheduling option uses the Actual Dates for Forward Pass and Backward Pass calculations.

 Actual Dates – Uses the Actual Dates of the activity for Forward Pass and Backward Pass calculations

When you choose Actual dates option, the scheduling engine does the forward pass and backward pass based on the actual dates. This means that you can update an activity with an Actual Start and Actual Finish after the Data Date and Primavera will schedule the successor activities based on the actual dates of the activity. For this example we will finish Activity B after the data date of the project.

In the above screenshot we can see that the Data Date (Blue line) is 1-Feb-15 which is before the start of Activity A but Activity B has finished on 14-Feb-15, after the Data Date. Activity C is then scheduled after finish of Activity B and starts on 14-Feb-15.

Lets review the calculations for this example: The data date for the project is 1-Feb-15. Activity B has finished on 14-Feb-15 but both Activity A and Activity C are not progressed. When we schedule our project on 1-Feb-15, the scheduling engine schedules Activity A from 01-Feb-15 (data date) as the activity has no predecessor but Activity C is scheduled from 14-Feb-15 because Activity B has an actual finish on 14-Feb-15. This method eliminates the out-of-sequence logic from the project.

Actual Dates option can be used to fix dates for activities which you know will happen in future for sure.  It can be used in situations when we know that an activity will for sure finish on fixed dates and we want to schedule the successor activities after that actual date. While this sort of thing doesn’t usually happen on projects, we can use this option to prepare some what-if scenarios.

After looking at the above examples, we now know that Retained Logic and Progress Override are the two main options that we can use to schedule our projects. I prefer using Progress Override over Retained Logic for scheduling on my projects because I know it represents the actual scenario. It doesn’t add non-working periods to projects and potentially extending their duration. I know a lot of my readers will think otherwise, please comment below if you don’t agree with my justification.

Why Project Calendars Are Preferable to Global Calendars

One criteria on the scheduling review checklist used by a government naval command agency looks to confirm that calendars are defined at the project level. Why? Let’s explore this issue.

The Naval Facilities Engineering Command (NAVFAC) scheduling review checklist specifies that schedule calendars should be project-specific data and not global. Obviously, if you are submitting your schedule to NAVFAC then you have a compelling reason to use project calendars instead of global calendars. There are other sound reasons, however, that make project calendars preferable to global calendars. And these reasons may be the driving force behind the NAVFAC project level calendar criteria.

This article explores the reasons that Primavera P6 Professional project calendars are preferable to P6 global calendars.

The great thing about global calendars is that they are available to all users in the Primavera P6 Professional database, so all users have access to your defined global calendar. This is a double edged sword, however. Other users may not only use your global calendar; they may have the ability to actually change your global calendar. The implications are that their calendar changes are applied to any project schedule using that global calendar. Not good!

Another reason not to use global calendars is that exported global calendars clutter the recipient’s database. When you export a schedule assigned global calendars, those global calendars wind up in the global calendars list of the recipient importing your project. It’s amazing how quickly ones database becomes cluttered with rarely used global calendar definitions.

There is another reason not to export global calendars. Imported global calendars having the same name as global calendars already in the system are not renamed. They, however, inherit the properties of the global calendar currently in the system. So your global calendars of the same name, but in two different databases may not have the same global calendar definition.

Summary

Yes, it’s nice for your calendar to be available to all your projects and all your database users. Global calendars appear to be the way to go when creating a new calendar definition. But there are sound reasons for defining a calendar limited or restricted to a specific project.

Global calendars do not have the same security that project calendars have: other users can change your global calendar, and the respective schedules it’s assigned to. This alone compels schedulers to define project specific calendars. You may also clutter yours or your recipient’s global calendar list with rarely used calendars. There are also some export/import issues that may result in two global calendars of the same name, but with different date properties.

Primavera P6 Professional seems to favor global calendars as it makes it easy to convert project specific calendars into global calendars, but not vice versa. Despite this it is best practice to define calendars as project specific. 

reproduced from Tensix

S-Curves in Primavera P6 Professional

We’re frequently asked if Primavera P6 Professional is capable of displaying S-Curves. Sure, it can do that. You just have to know where to look.

This article is a ‘How To’ on S-Curves in Primavera P6 Professional, how to configure them and how to print them.

What is an S-Curve?

For those of you who are new to the topic, an S-Curve is a simple graph that plots costs, hours, units or other values (depending on the subject matter) over time. They are popular in Project Management because they give managers a quick and easy-to-understand view of cumulative budget, actual and remaining values over the project lifecycle. The term S-Curve denotes the tendency of the lines to form a shallow ‘S’ shape; flatter at the start, steeper in the middle and flattening off again towards the end. This shape is very typical of most projects as the effort ramps up in the beginning periods, stabilizes during the main execution phase and then starts to wind down again towards the Project’s completion.

Read the remainder of this post on  Ten Six

Conscientious use of constrains

Generally, constraints affect the dates, violates the network logic and one of the reasons for negative floats or irrationality on the schedule. But again this is based on your project requirements and these constraints could help you to provide a complete control of a project however no more than 10% of a project’s activity should be constrained. 

Constraints other than contractual ones are generally not used since they impose specific start and or finish dates and in some instances completely OVERRIDE the logic that is contained in the schedule. The idea is to let the logic determine the dates as opposed to using constraints to do this.

Early constraints (e.g. Must Start/Finish On or After) are a typically a shortcut to represent the outcome of related work that the scheduler is excluding from the schedule logic. This is justified only for interfacing work that - in total, including its initiation - is clearly outside the scope of the project scheduled (e.g. contractual access restrictions, customer-furnished info/eqpt/permits.) Using early constraints for in-scope work (or for external work that depends on in-scope work) removes that work from logical schedule analysis, overrides the logically-derived scheduled (early) dates of the constrained activities and their successors, and jeopardizes the validity of the entire logical model of the project including float calculations.

 Late constraints (e.g. Must Start/Finish On or Before) are typically imposed to represent external obligations or commitments – aka “deadlines.” Such commitments can be imposed by contract (e.g. completion milestones) or by some other governing document (e.g. Project Charter, Board Instruction, Executive Tantrum, etc.) Late constraints can override the logically-derived (late) dates for the constrained activities and their predecessors, thereby complicating the interpretation of Total Float and identification of the “Critical Path.” Where multiple late constraints are applied in a network of related activities, Total Float becomes unreliable as an indicator of driving logic; then other methods of logical analysis must be used.

Other constraint types (Start/Finish On, or Mandatory Start/Finish) are even more restrictive with respect to driving logic flow – they are rarely if ever justified.

It is true that ALL constraints affect total float computations but so do the calendars being used, the remaining durations, the logic, the lags, the TIMES etc. So I would re-iterate that this clause was included in the scheduling specifications because constraints impose specific start and or finish dates and in some instances completely OVERRIDE the logic that is contained in the schedule.

Tracking Labor Units on Multiple Resourced Activities In Primavera P6

If you have activities with multiple resource assignments in your schedule, it’s typical even with the best of schedules that your resources don’t always work the exact hours they were originally planned to. Do you know how to track labor units in Primavera P6 so that your progress updates on the multiple resourced activities accurately reflect the actual labor units expended?

It is important when tracking the labor units of activities, particularly, activities with multiple resource assignments, to follow the proper sequence for the procedures. If the procedures are not followed in the prescribed order, then Primavera P6 will compute erroneous labor units when recalculating the schedule.

Read the Post on TenSix

Why You Should Avoid Mandatory Activity Constraints

If you just cannot get your schedule to match an important finish milestone deadline you may be tempted to go “thermonuclear” by inserting a Mandatory Finish constraint on the milestone. You’ll definitely get your important finish date this way, but there will be collateral damage to your schedule. Let’s explore this.

If you want a child to stay away from a stove top burner you could simply tell the child ‘do not touch’. A more indirect approach is to tell them about the stove, and in doing so provide them knowledge that warns them to stay away. The later approach is our intent today in explaining mandatory constraints. We are telling you how mandatory constraints work not so you will haphazardly use them, but so that you will know enough to be cautious and even wary of their use.

Read the Post on Ten Six