hi cindy, thanks for your comments here. yeah expected finish has it foibles like everything else. i have been burned by having activities pass their ef dates and earlier versions of p6 would choke slightly on this.
one trick i use is to put the expected finish column up so i can easily find them and manage them.
i agree somewhat that using remaining duration avoids ef issues. but of course, with rm updates you can have non-work days you’ve forgotted about and you can get the rm wrong as well. in the end, we all do our best and work the way that’s best for us.

how about this scenario. a construction activity is started and given an actual start date. instead of throwing a dart hoping to come up with some imaginary expected finish date, you find out from the source how much longer its going to take to finish something. if somebody can guesstimate a date, they can guesstimate a duration. expected finish dates are easy, sure but sometimes – most times – laziness is not the way to approach an update. also, why not move the data date before you update? then the can tell you when and just adjust the finish date and remaining duration will automatically update. if someone tells you they will finish on whatever date and you drop that lug in, everytime the data date moves the remaining duration automatically reduces and appears that work is tracking. what if it’s not? what if zero progress has been made? is it possible, do you think its possible, that activity, due to lack of progress is now actually critical? you would never be able to tell because remaining duration is depleted as time rolls on. when in actuality, they still need x days to complete it.

and for all the time you claim will be saved by updating this way, you’d end up spending way more just to track down all of those surpassed expected finish dates and the results you will be publishing are just a fabrication.

move the data date before updating, adjust the finish date or change the rd. as the data date changes and as the work continues to make no progress it will still show they need x days to complete it.

in my mind (i’ve been a scheduler for over 22 years) the only time it would possibly reasonable to us an expected finish date is on things that have a set duration. procurement, design maybe, other than that it is totally unnecessary and in the end will actually take more time to deal with than figuring out 3 weeks on a 5 day calendar is 15 days. a constraint is a constraint and there is no where i have i ever heard it said that the more constraints the better.

just do the work. that’s what they’re paying you for.

hi george,
1) expected finish and mandatory finish are very different animals. as this article explains, expected finish is helpful in recalculating remaining duration during updates. mandatory finish will not do any of that. it will pin the activity to that mandatory date with superglue. i do not recommend using mandatory constraints as they can serious mess up critical path.
2) no not at all. that is a good way to get an accurate remaining duration.

2.- is there anything against asking the person responsible for the activity about an educated guess for a remaining duration? leaving responsibility where it belongs.

i appreciate your comments.

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.

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.

hi louie,

what about resource dependent activities?

thanks.

mammad

i would agree that is the probably the first and most important rule of using expected finish

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.

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.

maurice thanks for this contribution.

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.

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.