Its not wrong but remember and take it for what it is - you are updating progress based upon % complete and then using this to report actual relative to planned man-hours.
In reality the actual man-hours worked may be different, say as a result of disruption that impacts achieved output or incorrect planned outputs.
Regards
Member for
17 years 5 months
Member for17 years5 months
Submitted by Chandan Kakati on Wed, 2009-05-20 05:58
I first update the dates i.e. Actuals/Forecast and than delink the remaining duration and % complete link. After that I put in the percent complete which is the physical percent complete. And than compare the Earned to spent ratio. Is not it right way of updating a Schedule?
You can present as an overall manhours S-curve and show the % deficit (that is based upon manhours) as an overall delay relative to the x-axis programme duration.
Report what the delay represents (overall progress deficit as based upon planned manhours) and report that the critical path delay is zero.
Are you recording and inputing actual manhours against the respective activities, or are you simply inputing % complete? If the former this raises issues of planned output versus actual output...
Regards,
Neil
Member for
17 years 5 months
Member for17 years5 months
Submitted by Chandan Kakati on Wed, 2009-05-20 04:46
Thats what I actually told the client. The percent delay is based on the resource loaded (Manhours) schedule , this delay cant really quantify to number of days. There might be one activity with 100 MH and another might have 50 MH. Hence delay in 1 day in the previous one will give a more % delay than the delay in the 50 MH.
Also this delay is not effecting the end date of the project, that means non of the critical path activities are delayed. Its a number of non-critical activities which is contributing to the % delay.
What is your % delay based upon? Assigned activity value, man-hours, activity days, concrete volume...?
If advising the client of % progress status you should advise as based upon what. If the client is asking for status in terms of days you should clarify with them exactly what they want - if mandays or activity days then you could easily assign these as a resource and run an earned value report based upon the respective resource. I suggest asking, discussing and agreeing with the client as you may otherwise provide a figure that is misinterpreted by them.
If providing an overall progress status in terms of ...days you must not neglect the critical path status and in this case advise that the critical path delay remains 0 and the forecast completion continues to match that planned.
Member for
24 years 9 monthsRE: Quantifying Percent delay into number of days
Chandan,
Its not wrong but remember and take it for what it is - you are updating progress based upon % complete and then using this to report actual relative to planned man-hours.
In reality the actual man-hours worked may be different, say as a result of disruption that impacts achieved output or incorrect planned outputs.
Regards
Member for
17 years 5 monthsRE: Quantifying Percent delay into number of days
I first update the dates i.e. Actuals/Forecast and than delink the remaining duration and % complete link. After that I put in the percent complete which is the physical percent complete. And than compare the Earned to spent ratio. Is not it right way of updating a Schedule?
Cheers!
Chandan
Member for
24 years 9 monthsRE: Quantifying Percent delay into number of days
Chandan,
You can present as an overall manhours S-curve and show the % deficit (that is based upon manhours) as an overall delay relative to the x-axis programme duration.
Report what the delay represents (overall progress deficit as based upon planned manhours) and report that the critical path delay is zero.
Are you recording and inputing actual manhours against the respective activities, or are you simply inputing % complete? If the former this raises issues of planned output versus actual output...
Regards,
Neil
Member for
17 years 5 monthsRE: Quantifying Percent delay into number of days
Thanks Neil,
Thats what I actually told the client. The percent delay is based on the resource loaded (Manhours) schedule , this delay cant really quantify to number of days. There might be one activity with 100 MH and another might have 50 MH. Hence delay in 1 day in the previous one will give a more % delay than the delay in the 50 MH.
Also this delay is not effecting the end date of the project, that means non of the critical path activities are delayed. Its a number of non-critical activities which is contributing to the % delay.
Just wanted to check with other if I am correct!
Cheers
Chandan
Member for
24 years 9 monthsRE: Quantifying Percent delay into number of days
Chandan,
What is your % delay based upon? Assigned activity value, man-hours, activity days, concrete volume...?
If advising the client of % progress status you should advise as based upon what. If the client is asking for status in terms of days you should clarify with them exactly what they want - if mandays or activity days then you could easily assign these as a resource and run an earned value report based upon the respective resource. I suggest asking, discussing and agreeing with the client as you may otherwise provide a figure that is misinterpreted by them.
If providing an overall progress status in terms of ...days you must not neglect the critical path status and in this case advise that the critical path delay remains 0 and the forecast completion continues to match that planned.
Hope this is of some help.