sorry i was asking how P6 calciulates these fields not what they represent
for instance start activity 1 es date is a calculated field from the project start date which is an input field or data date if you have missed it.
activity 2 es date is activity 1 + duration of activty 1 which is an input field + any input logic (with chosen calendar) between them + activity 1 calendar + any internal and external contraints input + any resource / calendar levelling input data. P6 converts duration days or hours to unit minutes (or is it 0.6 mins?) and then does the calculation in minutes based on calendar working input hours (converted to minutes) per day and displays the result in the chosen format......... and so on.
Is that it or did I miss something?
Read Ron Winter's before replying.
Member for
1 year 5 months
Member for1 year5 months
Submitted by lb*****@g***** on Sun, 2024-07-14 23:37
1. ES: The Early Start date of an activity is the earliest point in time when the activity can logically begin based on its predecessors and any constraints.
2. LS: The Late Start date of an activity is the latest point in time by which an activity must start to avoid delaying the project finish date.
3. EF: The Early Finish date of an activity is the earliest point in time when the activity can logically be completed based on its ES and duration.
4. LF: The Late Finish date of an activity is the latest point in time by which an activity must finish to avoid delaying the project finish date.
5. PS: The Planned Start date of an activity is often user-defined and represents the initially planned or baseline start date for the activity.
6. PF: The Planned Finish date of an activity is user-defined and represents the initially planned or baseline finish date for the activity.
Critical Path: Activities that have zero float (difference between LF and EF, or LS and ES) are on the critical path. The critical path determines the minimum project duration and any delay in critical path activities will directly delay the project finish date.
These date fields (ES, LS, PS, EF, LF, PF) are fundamental in project scheduling software as they provide crucial information about activity timing, dependencies, flexibility, and criticality. Understanding how these fields are calculated and their significance helps schedulers in managing and controlling project schedules effectively.
Well, Peter, given that I have been answering questions about it for 20 years, I suspect many planners using P6 have not done their homework.
There are some interesting things P6 does with Dates. I remember a forensic job I had, where an extra 100k+ manhours appeared one month, but the extra manhours had planned dates of three months previously. This demonstrated to us that the plan had been ‘forked’, and the contractor was providing their client with a plan missing those hours for three months. When someone added the extra work, it was given an Actual Start date in the past, but the planned dates were held at the Data Date when the activities were added.
Member for
20 years 5 months
Member for20 years5 months
Submitted by Peter Holroyd on Sat, 2023-10-07 11:01
David, thanks for ref paper (hadn't come across this paper only the Understanding P6 Dates one) - says everything and more. Do you thing P6 users understand any of this?
I first came across these problems in the late 90's when trying to match a subcontractor's stand alone P6 version with a company system one. They kept giving different dates even though we had agreed major default settings. We realised that to match systems you had to specify every setting that P6 had even if we were sure that the the setting had no effect on the F9 analysis.
Member for
20 years 5 monthssorry i was asking how P6
sorry i was asking how P6 calciulates these fields not what they represent
for instance start activity 1 es date is a calculated field from the project start date which is an input field or data date if you have missed it.
activity 2 es date is activity 1 + duration of activty 1 which is an input field + any input logic (with chosen calendar) between them + activity 1 calendar + any internal and external contraints input + any resource / calendar levelling input data. P6 converts duration days or hours to unit minutes (or is it 0.6 mins?) and then does the calculation in minutes based on calendar working input hours (converted to minutes) per day and displays the result in the chosen format......... and so on.
Is that it or did I miss something?
Read Ron Winter's before replying.
Member for
1 year 5 monthsHello Peter, 1. ES: The Early
Hello Peter,
1. ES: The Early Start date of an activity is the earliest point in time when the activity can logically begin based on its predecessors and any constraints.
2. LS: The Late Start date of an activity is the latest point in time by which an activity must start to avoid delaying the project finish date.
3. EF: The Early Finish date of an activity is the earliest point in time when the activity can logically be completed based on its ES and duration.
4. LF: The Late Finish date of an activity is the latest point in time by which an activity must finish to avoid delaying the project finish date.
5. PS: The Planned Start date of an activity is often user-defined and represents the initially planned or baseline start date for the activity.
6. PF: The Planned Finish date of an activity is user-defined and represents the initially planned or baseline finish date for the activity.
Critical Path: Activities that have zero float (difference between LF and EF, or LS and ES) are on the critical path. The critical path determines the minimum project duration and any delay in critical path activities will directly delay the project finish date.
These date fields (ES, LS, PS, EF, LF, PF) are fundamental in project scheduling software as they provide crucial information about activity timing, dependencies, flexibility, and criticality. Understanding how these fields are calculated and their significance helps schedulers in managing and controlling project schedules effectively.
Thanks,
Member for
9 years 9 monthsWell, Peter, given that I
Well, Peter, given that I have been answering questions about it for 20 years, I suspect many planners using P6 have not done their homework.
There are some interesting things P6 does with Dates. I remember a forensic job I had, where an extra 100k+ manhours appeared one month, but the extra manhours had planned dates of three months previously. This demonstrated to us that the plan had been ‘forked’, and the contractor was providing their client with a plan missing those hours for three months. When someone added the extra work, it was given an Actual Start date in the past, but the planned dates were held at the Data Date when the activities were added.
Member for
20 years 5 monthsDavid, thanks for ref paper
David, thanks for ref paper (hadn't come across this paper only the Understanding P6 Dates one) - says everything and more. Do you thing P6 users understand any of this?
I first came across these problems in the late 90's when trying to match a subcontractor's stand alone P6 version with a company system one. They kept giving different dates even though we had agreed major default settings. We realised that to match systems you had to specify every setting that P6 had even if we were sure that the the setting had no effect on the F9 analysis.
Member for
9 years 9 monthsTried to answer this already.
Tried to answer this already.
I can't think of anything to add to this:
https://www.ronwinterconsulting.com/Understanding_P6_Dates.pdf
Excellent.
Member for
9 years 9 monthsTried to answer this already.
Tried to answer this already.
I can't think of anything to add to this:
https://www.ronwinterconsulting.com/Understanding_P6_Dates.pdf
Excellent.