For any forensic delay analysis you need two programmes.
As Planned Baseline
As Built Actual
They have different uses depending on which analysis method you are adopting.
If your planned baseline programme has dubious logic then you have two choices.
1. Adjust the logic to FS and use the Time Impact analysis where you will be challenged that you have rigged the programme.
2. Use the As Built But For method which requires fully detailed as built reords so that you can create an accurate critical path within the as built programme where you will be challenged that you have rigged the programme.
If you can do neither of these then abandon the excercise and try a simple As Planned v As Built global approach which may help in a negotiated settlement but will be useless in a tribunal.
If the job is still running then you just impact the events to the affected programme tasks and then try to establish a realistic effect driven by the flawed logic - which will be entirely theoretical and unrealistic.
Yes setting actual dates equal to planned would be a poor method -You'd potentially be building in delay which never actually occurred and as such any EOT claim arising would (or at least should) be ripped apart.
If there are lots of lags and non-FS relationships, I'm afriad you just have to go through each activity and apply a bit of intelligence in ammending the logic to link around the removed scope in a realistic fashion -there isn't really a one size fits all approach here.
Once you've linked around the offending task, make it a milestone, remove all links to it and either leave it floating on the data date or give it an actual if you prefer. Be sure to note the assumptions you used when ammending the logic
Unfortunatley It looks like when the programme was created they went out of thier way to use poor logic FS(0) is all to rare, there are many SS & FF relationships with long lags.
I am using Primavera and did consider disolving the activities.
From what i have read so far leaving the activities as they stand and marking the planned dates as actuals seems the worst option?
Thanks
John
Member for
16 years 7 months
Member for16 years7 months
Submitted by Gary Whitehead on Wed, 2011-06-22 08:57
The purpose of making them milestones is so they have zero duration/impact but retain the original planned logical path through the project. Yes you would still have to give them actual dates so they occur immediatelty after all predecessors are satisfied.
NB: This approach works well for programmes using FS(0) logic. It can get a bit more fiddly if lags or other relationship types are involved.
If you are using Primavera, you could instead use the "dissolve" function, which deletes the activity and automatically links all predecessors to all successors using FS(0) (Other software may have similar functionality).
For your purpose, I would tend to go with the milestone approach though, as this allows you to retain the original ActivityID and enter comments explaining what you've done and why.
What would be the purpose of turning them into milestones? They would still at some point need to be marked as complete and still be driving later activities, allbeit with a shorter duration.
Member for
19 years 10 monthsHi John For any forensic
Hi John
For any forensic delay analysis you need two programmes.
As Planned Baseline
As Built Actual
They have different uses depending on which analysis method you are adopting.
If your planned baseline programme has dubious logic then you have two choices.
1. Adjust the logic to FS and use the Time Impact analysis where you will be challenged that you have rigged the programme.
2. Use the As Built But For method which requires fully detailed as built reords so that you can create an accurate critical path within the as built programme where you will be challenged that you have rigged the programme.
If you can do neither of these then abandon the excercise and try a simple As Planned v As Built global approach which may help in a negotiated settlement but will be useless in a tribunal.
If the job is still running then you just impact the events to the affected programme tasks and then try to establish a realistic effect driven by the flawed logic - which will be entirely theoretical and unrealistic.
Good luck and Best regards
Mike Testro
Member for
15 years 7 monthsGary, Great they were my
Gary,
Great they were my initial thoughts.
Thanks very much.
Member for
16 years 7 monthsYes setting actual dates
Yes setting actual dates equal to planned would be a poor method -You'd potentially be building in delay which never actually occurred and as such any EOT claim arising would (or at least should) be ripped apart.
If there are lots of lags and non-FS relationships, I'm afriad you just have to go through each activity and apply a bit of intelligence in ammending the logic to link around the removed scope in a realistic fashion -there isn't really a one size fits all approach here.
Once you've linked around the offending task, make it a milestone, remove all links to it and either leave it floating on the data date or give it an actual if you prefer. Be sure to note the assumptions you used when ammending the logic
Member for
15 years 7 monthsGary/Mike Thanks, that does
Gary/Mike
Thanks, that does make sense.
Unfortunatley It looks like when the programme was created they went out of thier way to use poor logic FS(0) is all to rare, there are many SS & FF relationships with long lags.
I am using Primavera and did consider disolving the activities.
From what i have read so far leaving the activities as they stand and marking the planned dates as actuals seems the worst option?
Thanks
John
Member for
16 years 7 monthsJohn, The purpose of making
John,
The purpose of making them milestones is so they have zero duration/impact but retain the original planned logical path through the project. Yes you would still have to give them actual dates so they occur immediatelty after all predecessors are satisfied.
NB: This approach works well for programmes using FS(0) logic. It can get a bit more fiddly if lags or other relationship types are involved.
If you are using Primavera, you could instead use the "dissolve" function, which deletes the activity and automatically links all predecessors to all successors using FS(0) (Other software may have similar functionality).
For your purpose, I would tend to go with the milestone approach though, as this allows you to retain the original ActivityID and enter comments explaining what you've done and why.
Cheers,
G
Member for
15 years 7 monthsThanks for your response
Thanks for your response again Mike.
What would be the purpose of turning them into milestones? They would still at some point need to be marked as complete and still be driving later activities, allbeit with a shorter duration.
Member for
19 years 10 monthsHi John Turn them into
Hi John
Turn them into milestones.
Best regards
Mike T.