Time delay analysis query

IMHO, if you originally planned a certain project to be completed in one (1) year and you actually completed it in two (2) years, then you are delayed by one year (simple analysis). You might also doubled the cost as a result.



For me, Baseline (original) against Actual (current).



You can always assume the sky is red (anyway that’s your plan), when you found out later that the actual color is black, then your assumption is wrong.



A Plan is just an assumption, it’s up to you if how often you’ll change it until you’ll get near the reality. That is, if your pocket is deep, otherwise change your Plan!

Hello Wasi,



Which type of Contract is the project?



In case of nec3, the baseline is revised on regular basis (usually monthly); reflecting updates, variations, realistic assumptions, etc. and supersedes the previous one (you literally throw away the previous one).



Hence; in case of activity starting earlier than planned, it will be reflected in the revised one. The vital point is to foresee all the requirements for the earlier start, and include them in the revised baseline, with enough notification period to the Client, prior to physically starting the activity.



FIDIC Contracts are different. Usually you abide with the original baseline; unless it is officially revised as per the Engineer instruction.



Regards,



Sherif Fam

I don’t think this exercise to verify the impact to the original baseline is incorrect. Remember you are maintaining your current schedule which reflect the true picture.



This is just an assumption if in case your work were progress as per plan, then suddenly there is some circumstances...so what would be the effect...

Hi Trevor



We are talking about impacting events while work is in progress and following an approved plan.



Of course you don’t know what is going to happen in the future - you are predicting the likely effect of an event on future progress.



If something occurs to change the programme then that is an event in iteslef and has to be impacted accordingly.



Best regards



Mike Testro

The wek point of this "method" seems to me to be the totally incorrect assumption at the start.

Why would you make the assumption that the project progressed as planned when this assumption defies the reality of what actually has occurred?



You may as well assume that the sun is blue and the sky is yellow

Hello Guys,



I wish to share the delay analysis approach I always use every time there is a delay in my project and or thereis a claim (due to change order, delay approval, variation, etc)



1. Agree with Mike, you must have set the Baseline programme have it review, finalize and approve before the project progress.

2. Of course during the onset of the project you will have the current programme which is being updated regularly base on the progress/physical accomplishment, etc....and always compare it to the approved baseline.



3. Now in the event that there is/are delay/s due to above, you may start the impacted analysis, this time using your baseline (you have to copy the baseline and save it in another file - please don’t use the original baseline, have it save in another folder if you wish.)



4. The first approach is to assume that the works progress as per plan (that is the reason why we have to use the baseline), set which activity affected by the delay (say delay on the approval) imposed the date of actual approval by using constraint date and run the programme...it will give you the effect of the imposed date as against the overall completion date.



5. Continue the second event (if there is any) using the same programme and see the effect until you have considered them all.



6. You can also do separate analysis (individual/per delay event) and see which event really have an impact to the overall completion date....



Hope this will help...keep on planning



Ronald

Hello Guys,



I wish to share the delay analysis approach I always use every time there is a delay in my project and or thereis a claim (due to change order, delay approval, variation, etc)



1. Agree with Mike, you must have set the Baseline programme have it review, finalize and approve before the project progress.

2. Of course during the onset of the project you will have the current programme which is being updated regularly base on the progress/physical accomplishment, etc....and always compare it to the approved baseline.



3. Now in the event that there is/are delay/s due to above, you may start the impacted analysis, this time using your baseline (you have to copy the baseline and save it in another file - please don’t use the original baseline, have it save in another folder if you wish.)



4. The first approach is to assume that the works progress as per plan (that is the reason why we have to use the baseline), set which activity affected by the delay (say delay on the approval) imposed the date of actual approval by using constraint date and run the programme...it will give you the effect of the imposed date as against the overall completion date.



5. Continue the second event (if there is any) using the same programme and see the effect until you have considered them all.



6. You can also do separate analysis (individual/per delay event) and see which event really have an impact to the overall completion date....



Hope this will help...keep on planning



Ronald

Hi Wasi



This is one of the problems with the Impacted as Planned method of analysis when used in a forensic situation.



The method ignores any As Built information - indeed it works on the basis that there isn’t any AB data at all.



The method works when the project is in progress and the delay analyst is projecting the likely effect of delay events.



If you have detailed As Built Information then adopt a Time Impact method of analysis.



If an activity has started earlier than planned then it is likely that there is a change in the original programme logic - this implies that the original programme was wrong or circumstances have changed.



Your first task is to set up a Baseline programme following the changed logic or circumstances - this could be Event 01.



Then start to impact events as and when they occurred and adjust logic or resources as may be reasonable to bring the activities back into line with the As Built situation.



keep doing this for 5 or 6 years and you can start charging out at Delay Analyst rates.



Best regards



Mike Testro

Wasi,



I am not a Forensic analysis expert, just a mere planner; however this would be my view. I would have thought that neither an ’impacted as planned’ or a ’collapsed as built’ in their own rights prove any true concurrency of delays and, as you state, the impacted as planned does not reflect actual progress acheived and therefore possibly the actual delay incurred to the works.



Have you considered the approach of a time impact anaylsis? Whilst it is prefereable this would be done as the project progresses; if you have record of actual progress acheived on a regular basis (or on the occurence of an event)you can reschedule the programme progressivley as you sequentially work through each of the delay events. This may provide a more accurate impression of the actual impact of an event and provide a clearer picture of any true concurrency in delays.