Delay Events

Hi Khawaja

When impacting more than one event you need to set up an events schedule.

This will list:
the event number
the document source reference
the document date
brief description
lead time and delivery of any change
leading to the "Imopact Date" which is the earlisest date that the affected activity could have started.
the activity reference form the programme
the latest start adte taking into account available float - note that float from the chart will be in working days so these have to be converted to calendar days.

Then:
If the impact date is earlier than the earliest start date then it will have no affect on the critical path.
If the impact date is later than the earliest start date then it has the potential to delay the critical path.
Then:
Sort the events into earliest date that may affect the critical path.
Then:
Impact that event onto the affected activity and save the file as Event 01.
Then:
Make new comparison of earliest dates against impact dates - some will have dropped out because the float has increased.
Continue with this until no more events have the potential to delay the critical path.
You will now have created an Impacted as Planned Programme and your problems are just starting because you now have to deal with concurrency and comparison with any as built data.
Impacted As Planned analysis only works when work is in progress.

Best regards

Mike Testro

hi Mike
thanks a ton
for ur detailed reply and as u said
"Impacted As Planned analysis only works when work is in progress"can any regulation or clause can be referred to substantaite for use of this technique.

Also do you mean to say that Time window analysis cant be used while work is in progress and can be done once project is completed ......
hope to hear ur valuable advise on the issue
Thnx n Rgds

Hi khawaja

There are no standard contract clauses that I konw of that relate to delay analysis methods. You can of course try to write them in but the possible permutations are too vast.

Regarding Time Window anlsysis this is the early system developed by the American Corps of Engineers before computers were handling programmes.

It was the only accepted method up until about 6 years ago but has now been overtaken by the established 4.

Any American "Scheduler" will of course give a good argument to the contrary but they need to come into the real world.

Best regards

Mike Testro

thanks Mike ,
in your earlier post you had mentioned 4 technique used for delay analysis ,,,,,,,and Time Imapct Analysis was one of’em
but you have suggested that Time window method is no more applicable .......do the time impact analysis and time window tech are 2 different things ..???
rgds

Hi Khowaja

The 4 recognised techniques are:

1. Impacted as Planned
2. As Built v As Planned
3. Time Impacted
4. Collapsed As Built

Window analysis is different from any of the above and is not used in delay analysis in the Uk.

Go to the thread on Windows analysis that I started to keep up to date.

Best regards

Mike Testro.

Mike

To my mind Windows is not a method of analysis, merely a timeframe in which the analysis is carried out. As I see it your 4 methods are correct, and then the various timeframes in which analysis can be carried out are:

1.Snapshot - whole project

2. Windows - Progress updated at monthly or regular intervals

3. Watershed - Progress updated at less frequent "significant" event intervals

4. Time Impact - Progress updated at event by event intervals

Regards

Toby

Hi Toby

Once again we are falling into the terminology trap that Andrew was talking about in the "Windows Snapshot" thread.

I have no idea what you mean when you say "Progress Updated" - particularly in the Time Impact reference.

Surely in a Time Impact Analysis you will have established the As Built Programme for the whole project before embarking on impacting any events.

Perhaps we just have different ways of doing things.

Best regards

Mike Testro

Mike

TIA needs a CPM based as-planned programme that will react dynamically to change. This is then updated to a date shortly before the event. The fragnet of the event is then added to the updated programme, linked logically with the programme and its effect calculated in the same way as in an as-planned impacted analysis.

The impacted programme is then updated again with as-built records to determine whether there is concurrency.

Regards

Toby

Hi Toby

As I thought - you have a completely different approach to a time impact analysis to mine.

I very rarely have the benfit of an original contract programme that is fit for delay analysis and when I do it will not have regular progress updates in percentage terms.

Even when I do get a regular progress update I cannot rely upon its accuracy - particularly when 95% complete appears in the last 5 reports before it switches to 98%.

Also it very rare that the same baseline programme is used throughout the project - about 2 thirds of the way through they start reporting on a completely different "catch up" programme.

I have to go to all the record to establish an As Built programme and what I get is mostly an approximate start date and a probable finish date for each activity.

At least this establishes a period of time that I call an "As Built Envelope" which gives some reference point for the impacted event.

Anyway it is good to keep in touch with different approaches.

Best regards

Mike Testro

I wouldn’t say those methods are independent from each other... I would think that developing the as-built critical path (and near-critical paths to seek out concurrency) is going to happen either way.