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.