Monitoring Deadline Dates in Primavera P6 EPPM | Ten Six Consulting

It’s very common for schedules that have a contract deadline that does not match the project’s projected completion date. In these cases, one thing folks want to do is monitor both in relation to each other.

Projects have deadlines; it’s a fact of project management. One main value of scheduling software is that you can monitor your project’s projected completion date versus the deadline, i.e. contract completion date. Primavera P6 EPPM R16.1 does not have a deadline feature. But with a little ingenuity we can highlight a deadline date in relation to the project’s current projected completion date.

Read the full post on Ten Six
Monitoring Deadline Dates in Primavera P6 EPPM | Ten Six Consulting:


'via Blog this'

Monitoring Forecasted and Contract Completion Dates in Primavera P6 | Ten Six Consulting

Your Primavera P6 schedule has a binding outside contract constraint date that doesn’t coincide with your schedule’s forecasted project completion date. Because of this, you need to monitor both the project’s estimated completion date and the binding contract completion date on your schedule. Come along as we demonstrate the best way to describe both in one schedule.

Monitoring Forecasted and Contract Completion Dates in Primavera P6 | Ten Six Consulting:

'via Blog this'

Reasons Why Construction Schedules Fail

CPM Schedules invariably become erroneous, despite best practices, when the rest of the team isn’t pulling their own weight. The integrity of the schedule may have nothing to do with why it became useless or meaningless, or as I like to say, a recorder more than a predictor of the critical path and progress. If the project is large and has multiple prime contractors, its schedule is all the more susceptible to deprecation.

First apear on RepOne Blog

From Plan Academy

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