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.
