Website Upgrade Incoming - we're working on a new look (and speed!) standby while we deliver the project

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Time delay analysis query

9 replies [Last post]
Fri, 2008-07-11 05:30
Wasi Raza
User offline. Last seen 7 years 24 weeks ago. Offline
Joined: 29 Apr 2005
Posts: 55
Groups: None
This query is directed towards Forensic analysis experts for guidance.
Using the method ’Impact on planned’ to portray delays to a contract programme due to multiple compensation events. A single programme is being used to show all the events and their impact (also inorder to check the concurrency). One of the events actually occurred days before the planned date so in theory it will not delay the planned activity, but in reality the activity was being carried out earlier than the planned date and did get delayed due to the event. On its own this delay can be portrayed best using collapsed as-built approach but not in the subject single programme of events.
Any suggestions?

Top

Replies

Sat, 2008-07-19 22:20
#1
Anoon Iimos
User offline. Last seen 3 years 19 weeks ago. Offline
Joined: 22 Sep 2006
Posts: 1422
Groups: Pinoy Planning Planet Community
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!
Top
Sat, 2008-07-19 09:46
#2
Sherif Fam
User offline. Last seen 14 years 4 days ago. Offline
Joined: 18 Apr 2005
Posts: 28
Groups: None
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
Top
Fri, 2008-07-18 06:46
#3
Ronaldo Quilao
User offline. Last seen 10 years 13 weeks ago. Offline
Joined: 11 Aug 2003
Posts: 34
Groups: GPC Qatar
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...
Top
Fri, 2008-07-18 06:42
#4
Mike Testro
User offline. Last seen 25 weeks 6 days ago. Offline
Joined: 14 Dec 2005
Posts: 4420
Groups: Building Information Modelling, Content Moderators, GPCCAR Editors
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
Top
Thu, 2008-07-17 21:34
#5
Trevor Rabey
User offline. Last seen 2 years 26 weeks ago. Offline
Joined: 29 Nov 2005
Posts: 530
Groups: None
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
Top
Thu, 2008-07-17 09:46
#6
Ronaldo Quilao
User offline. Last seen 10 years 13 weeks ago. Offline
Joined: 11 Aug 2003
Posts: 34
Groups: GPC Qatar
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
Top
Thu, 2008-07-17 09:46
#7
Ronaldo Quilao
User offline. Last seen 10 years 13 weeks ago. Offline
Joined: 11 Aug 2003
Posts: 34
Groups: GPC Qatar
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
Top
Fri, 2008-07-11 17:54
#8
Mike Testro
User offline. Last seen 25 weeks 6 days ago. Offline
Joined: 14 Dec 2005
Posts: 4420
Groups: Building Information Modelling, Content Moderators, GPCCAR Editors
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

Top
Fri, 2008-07-11 08:29
#9
BEN MAYLE
User offline. Last seen 10 years 27 weeks ago. Offline
Joined: 4 Jun 2004
Posts: 9
Groups: None
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.
Top