I’d love to see some stats on the average size of a Primavera P6 schedule. I’ve never come across any stats, but based on experience and lots of consulting and web-research, it’s pretty clear that today’s project schedules are the chunky big brother to their slim and compact sibling of 10 or 15 years ago.
Schedules are becoming bloated with data. Why?
- We have computers & software that can handle it easily.
- Our clients and sponsors ask for it / demand it.
- More data = more control (to a degree)
Really, I think we as a society have become obsessed with data. In the age of Big Data, we feel we should capture as much as possible and track it. And I agree. Except our scheduling software has no automation to help us manage big project data. We’re still visiting each activity one at a time and an accurate status update. I know automation is coming. Hopefully soon.
But for now, I believe in the motto:
“Saving Clicks & Keystrokes Saves Time”
I’m not saying less clicking will help your project finish sooner. It will save YOU time, less clicking, typing in status data and constantly rescheduling in P6 will save you time to do other more important things, like monitor your Critical Path or maybe watching 8-wheeler off-road truck videos. Whatever’s most important.
One thing we can do to save clicks and keystrokes in Primavera P6 while performing status updates, is to use the Expected Finish Date.
The process of updating an activity with status in Primavera P6 typically goes like this (note: I’m leaving out updating resources & expenses – just the basics of updating dates and % complete here):
- Mark Activity “Started“.
- Update Actual Start Date.
- If Activity is not complete,
- Update Remaining Duration (often difficult to calculate)
- Update Physical % Complete
- If Activity is completed,
- Update Actual Finish Date
- Mark Activity “Completed“.
- Reschedule with a new Data Date to see the new Planned Finish Date.
The common difficulty is figuring out what value to enter for the Remaining Duration. Because the Remaining Duration is added to the future Data Date (the new Data Date you’ll enter after you’ve done your updating), we won’t know the Activity’s new Planned Finish Date until after we schedule.
On top of that, we don’t have visibility into the Activity Calendar – if you’re trying to input a Remaining Duration that equates to the Activity finishing on a particular date, you’ll need to be aware of non-work days in the calendar; another piece of information that makes using Remaining Duration difficult and cumbersome.
Sometimes it’s nicer to just input a date, rather than the Remaining Duration.
For example, let’s say for Activity B, you enter 12 days for Remaining Duration. To know what 12 day remaining translates to as a Planned Finish date, you need to add 12 days to the new Data Date – let’s say it is Feb 1st. So Feb 1st + 12 days = Feb 12th. BUT, what about Calendars? It could be easily be Feb 14th or 15th or 16th depending on whether there are non-working days in that period on the Calendar.
So many P6 users (me included) find that using Remaining Duration is really a bummer, unless you’re working with a short Remaining Durations, like 1-5 days. If the Remaining Duration is small, then the calculation is trivial and doable.
Using Expected Finish in Primavera P6
What if there was a better way than having to figure out and record how many days are remaining on an activity?
There is. The field is called Expected Finish.
What we can do with the Expected Finish date is to set a date on which we anticipate we will finish the activity. No input is required for the Remaining Duration field.
The updating process now looks like this:
- Mark Activity “Started“.
- Update Actual Start Date.
- If Activity is not complete,
- Input an Expected Finish Date.
- Update Physical % Complete.
- If Activity is completed,
- Update Actual Finish Date.
- Mark Activity “Completed“.
- Reschedule with a new Data Date to see the new Planned Finish Date.
The net effect here is that Remaining Duration is CALCULATED for us when we reschedule the project, taking into account the Calendar as well.
Rather than input a duration value to aim at my new Planned Finish date, I can now, just input the finish date itself in the Expected Finish field. Below is the result after scheduling.
Here you can see that the Expected Finish in Primavera P6 is set as the Planned Finish date. The Remaining Duration field is calculated for you based on the Data Date after scheduling.
To me, this simplifies updating significantly, saving me time from doing the date math and rescheduling in P6 to see if I got the right Finish Date from what I entered for Remaining Duration.
The Setup
What’s required to make the Expected Finish date work in Primavera P6 Professional or even Primavera P6 EPPM? There is just one setting in the Scheduler options. Tap F9, then click the Options button.
You’ll need to make sure you have the option “Use Expected Finish Dates” checked on in the P6 scheduler options. That’s it! And in my experience, this setting is checked by default. But please check your install.
How do I remove an Expected Finish Date?
In case you decide to remove an Expected Finish Date and want to revert back to using Remaining Duration, just highlight the date in the Expected Finish Date field, and tap Delete or Backspace to blank out the field. You’ll be able revert back to using the Remaining Duration field.
Can I update Remaining Duration when an Expected Finish Date is set?
The short answer is no. You’ll be able to update the Remaining Duration field, but once you reschedule, the Remaining Duration will be recalculated for your activity based on the value of Expected Finish. Having a value in Expected Finish overrides the use of Remaining Duration.
What problems exist with using the Expected Finish Date in Primavera P6?
There is one situation using Expected Finish that I’ve discovered thanks to comments below from Kent Vaughn and Derek Cairns (thanks guys!) that can cause some nastiness in your schedule.
In this case, we are:
1) Adding an Expected Finish date on an activity that has NOT started.
2) Rescheduling the project and setting the Data Date beyond the Expected Finish Date – to 30-Apr-15.
Here’s the result:
As you can see, this is NOT a good result…..it’s a terrible result! After scheduling and moving the Data Date past the Expected Finish date, P6 has set the Original Duration to 0d and completely messed up this activity. You’ll have to move the Data Date back and reset the Original Duration to it’s prior value to recover from this incident.
ASIDE: If your activity is has a resource assigned you might get this result. The Original Duration won’t be overwritten as it was here, IF your activity’s resource assignment had the “Drive Activity Dates” option checked, as in the image here.
Lessons Learned on Using Expected Finish dates in Primavera P6
Setting an Expected Finish date when an Activity is NOT Started, is NOT recommended – and I’ve confirmed this with Oracle Support who have a brief write-up about this issue.
To avoid this issue you MUST
1) Mark the Activity Started BEFORE applying an Expected Finish Date ….OR
2) Have a resource assigned to the activity, set to drive activity dates.
I think in the end, you’ll want to only use Expected Finish on activities that you are progressing – this is clearly what the feature was designed for. If you want to change an Activity’s Planned Start date prior to that activity starting, then amend the activity’s Original Duration instead.
Conclusion
As with all things Primavera P6, you’ll need to be detail-oriented and precise to get proper results. Expected Finish saves time by avoiding by-hand calculations of Remaining Duration that can be cumbersome and annoying.
With managing huge projects and huge project data, any time saving or simplification technique is going to have exponential time savings for us. I think planners & schedulers have a tough job already. But hopefully using Primavera P6’s Expected Finish field will save you time and maybe put a smile on your face. Here’s hoping! 🙂
Never knew this trick until now. This is why I always tell people that you should never stop learning.
Thank you for sharing this.
Just simple and effective. Thanks
Very helpful tip. Thanks for sharing Michael.
I have been using expected finishes for many years now and they have saved me a great deal of time. They present an excellent way to hold end dates without fear of P6 recalculating and changing dates on you. Once I have completed my updates I use a global change as follows to give me expected finishes across the project:
Where: Activity Status = In Progress
And: Activity Type = Task Dependent
Then: Expected Finish = Finish
We use “In progress” because you don’t want to add an expected finish to activities that are not in progress; and we use task dependent because you cannot add an expected finish to a milestone activity or a Level of Effort Activity.
Hi Louie,
What about Resource Dependent activities?
Thanks.
Mammad
Totally agree with activity should always be started before applying expected finish otherwise when you keep moving data date forward you will eventually turn all your original and remaining durations to zero on activities not started. This is the real danger of expected finish dates being applied.
I would agree that is the probably the first and most important rule of using Expected Finish
We use Expected Finish dates on I/P task dependent activities. The only issue we’ve had is when the data date goes beyond the Expected Finish date. The task does not complete (of course) but the duration goes to zero. End users should not allow this to occur, but at times they input an Expected Finish Date and fail to keep it current. To remedy this, we run globals adding 1 hour to the duration in these situations. Anyone else had this issue? Any better resolution?
I run into this all the time, but it has actually become a preference for me as it is an indicator of an activity that needs to have an expected finish. When an expected finish is not updated I find that its usually because it is done at or near the expected and not that no progress was made which would be the assumption by P6 had it not reset the remaining duration to zero. The lesser of two evils I guess.
Kent highlights the only issue that I have encountered with this. Don’t let the data date outrun an expected finish date. I’m not sure I agree with Kent’s remedy – seems to me it’s treating the symptom. I would say check for expected finish date earlier than data date (before hitting F9) and go back for specific updates on the relevant activities. If the job owner doesn’t co-operate then I normally remove the expected finish date and run with the remaining duration from the last update and let the job owner explain the overrun to the PM.
Thanks to both you and Kent – this was something that I completely forgot about. I’ll see if I can incorporate some tips on this into the article.
During the execution phase when updating an Integrated Master Schedule composed of several interrelated projects through logic with tens of thousands of activities (ship building), it is imperative to utilize simple functions for progressing activities to retain accurate metrics. For in-progress activities, the expected finish field must be populated, thereby allowing the advancement of the data date to automatically decrement remaining durations. Updating or altering the expected finish field for a thousand + activities only requires an import from day excel in a supported format of Estimated Finish Date (calendar based UDF), then running a global change to alter expected finish to equal the estimated finish. The construction owner is simply required to notify the scheduler of when the task has started and then alter the Estimated Finish Date in a spreadsheet if appropriate. Scheduler handles the rest. Running a report for in-progress activities with RDU=zero calls out the neglected activities that construction owes a new Estimated Finish Date or Actual Finish Date to the scheduler.
Your exactly right, I usually schedule off of Actual Dates and so by the time I run a new data date my expectation is that nothing moves. That is how I now that I have accounted for everthing before hand in the way of making sure all Started Activities have expected finish dates. Another thing to keep in mind is that logic ties will overide the Expected finish in the way of calculating the finish dates but will still show a remaining duration of zero in any case. Usually this is spotted pretty easily on the GANTT and can work to your advantage if you can figure out the behaviors. The disadvantages are that it can look funny on the chart and mess with earned value calculations if resource loaded, however can be remedied fairly easy with a quick scan and fix or a global change.
Thanks a lot. Usually I also calculate the remaining days to get the finish date exactly. Some times due to calendar it comes wrong. Now I know How to deal. Thanks Michael
I have run into other limitation of expected finish dates when I am using different calendars to model different project scenarios. On engineering projects subject to inclement weather I typically run both wet and dry weather scenarios by replacing the standard production calendar with a calendar which includes non working days for potential weather events. Under this scenario, WIP activities constrained with an expected finish date don’t react to the calendar change with an extension of the finish date but rather reverse engineer the remaining duration against the alternate calendar and hold the same finish date. In saying this I am still a big user of expected finish dates and just accept this limitation for the immediate WIP activities.
Maurice thanks for this contribution.
Why not update the data date before taking status? For an in progress task, if the data date is already correct, then inputting a new finish date (not “Expected Finish”) will automatically adjust the remaining duration based on the number of work days (from the applied calendar) for the task from the first business date following the data date to the selected finish date. This remaining duration will be applied to the next data date move, resulting in a finish date that is one week later than the previously entered finish date…until status is again entered.
Steve,
Very valid points. However, I would say that its easier to progress a schedule prior to moving the data date because once you move the data date and don’t update status all activities that have not been progressed will be pushed after the data date and it will be very challenging to determine what activities need to be actualized.
You have pretty much hit this spot on. I have been using and instructing the use of Finish Dates in lieu of Remaining Duration and % Complete for years now. Generally speaking it is much more useful than the latter, this is particularly so when having none typical schedulers yet owners of activities updating a master directly.
Great article, thank you!
btw before any update i usualy check the “not started activities with exp.finish” (using filters)
also i do check activities as late as posible activities WITH expected finish as they also can cause a scheduling problem !
Thanks Michael for this. I tried adding expected finish date to all my In-Progress activities now, and I noticed, something. As soon as I hit F9, it changed free floats of all the activities to 0.