(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.
Dear All
At present am working in one big project. my projectis already extended more than one year. the following the causes to delay the project.
1. Delay in design
2. Delay in slab casting
3. Delay in Block Work
4. Delay in Plinths and epoxy for equipment
5. Delay in material approval
can we use a Baseline program for EOT or Updated program
Please explain me how i have to work in P6. These delays how i have to shown in P6
Printer-friendly version
Send to friend
Hi,
I write an article regarding How to perform Impacted As-Planned Delay Analysis in Primavera P6.
If you're interested, kindly read it here https://doduykhuong.com/2016/09/19/how-to-perform-impacted-as-planned-delay-analysis-in-primavera-p6/
Cheer
Copy the baseline, add the impact events to the copy. Code the impacts as Owner or Contractor or Unforeseen Conditions. Add this as a baseline to the as-built. Determine what pushed out completion a year. Assess liability.
Hi Alan
Thanks for the tip.
I switch P6 to Asta PowerProject for delay analysis work and then switch it back if I have to.
Best regards
Mike Testro
Hi Mike,
That's a great workflow, appreciate that. I am currently spending hours inside P6 which despite its brilliant features, is very slow to work with. I ike that approach and it sounds allot more methodical.
That got me thinking and here's a tip back from me (which you may already know). If you change the .XER extension to .TXT, you can open up a P6 file in excel. Doing this gives you access to all the data in the P6, including late dates and total float (in hours, to avoid any calender issues). I have a file which gives an explanation of the column headings. I often do this to get quick access to the TFs and dates in a schedule.
You're right about the impact date, given that its the latest date of the delay, it does make sense to adress them in the order of effect. It makes it allot simpler than establishing fragnets too.
Very useful stuff.
Cheers
Alan
.
Hi Alan
If you think about it the Impact Date is the one that will affect your critical path - not the start date of the event.
You can cut down your workload if you have your events schedule on one worksheet with the latest impact date and the baseline programme in another with the the two linked by the UTID.
If the baseline sheet has the START column set to Latest Start then you can put in an =if( formula that shows "Yes" if the impact date is later than the start date.
This filters out all the non critical events so just filter on Impact Date and Yes columns and impact the event at the top of the column.
After Impact copy paste the new critical path dates and UTID back into the spreadsheet and a lot of the Yes column will drop out.
A 10,000 events schedule usually takes me two days to analyse.
Best regards
Mike Testro
Hi Mike,
Fortunately for us ;)
I take on board your comment on the events schedule, its a good point. I have always sorted by the date the event started, in order to keep continuity through the update cycles. I'll have a think about that...
I'm principaly using this approach as balance between a full TIA with progress update for each and every event, and an IAP. I'm currently dealing with a large power project with hundreds of ongoing events, and limited resource.
It's true that the main weakness of this method (when based on monthly cycles) is that the progress doesn't always correspond with the delay event impact dates. The worst outcome is that the Contractor had mitigated by 29 days, or delayed by 29 days in that period. But in reality this isn't going to be the case, so I'd submit that the method is robust enough.
The spec I adapted actually suggested a 3-6 month cycle, but verifying 100% of the as-built data for each snapshot. I hope I've made a slight improvement from that!
Cheers
Alan
Hi Alan
I would say "fortunately everyone has a different approach"
You are correct that you require an events schedule but it should be sorted on the date of impact - which is the earliest date that the impacted task could have started after all the lead in period of the event has been taken into account.
Not every event will delay the critical path.
When an impacted event does delay the critical path then the programme should be updated and the comparison made.
You are combining a TIA analysis with a Windows analysis - the update data date must be just before the end of the delay event impact date.
This only works if the As Built data is detailed and accessible - relying on regular (monthly) progress up dates is too broad as the the data could be 30 days out.
Best regards
Mike Testro
Hi Mike,
I don't think there is a seperate TIA methodolgy in section 4. I think Section 4 just raises some further issues for consideration, as well as alternatives such as the IAP / Collapsed as built etc.
Correct me if I am wrong
Cheers
Alan
Hi Syed,
You will need both.
In very simple terms, this is what I would normally do with such a major a delay scenario assuming I was also looking for payment:
1. Make a table of all the delay events, sorted by the date which each event occurred.
2. Impact the delay events which have occurred in the first update window into the baseline programme. Note the effects on the project milestones. (You will need to break down the delay events if they span more than one update window)
3. Then add progress / reschedule. Note the effects on the project milestones. I.e. improvements to the milesones = mitigation, further delays indicate 'concurrent delay'.
4. Taking the impacted / updated programme from [3], do exactly the same thing for the next update window.
5. Repeat until you reach the current data date / completion of the schedule.
If you remove all of the progress from your final programme, you should be left with an Impacted As Planned programme.
Of course in reality you will be dealing with change of sequence / logic / original durations. To get over that, I often use the latest update programme, and remove all of the progress.
Unfortunately everybody has a different approach.
Cheers
Alan
Hi Alan
Section 3 of the SCL deals with the impact of delays on work in progress whereas section 4 deals with forensic analysis of completed work.
The methods are different.
Best regards
Mike Testro
Mike, I'm not sure if Kevin did describe an SCL TIA?
Here is the SCL methodology, for reference:
"3.2.7.1 the Programme should be brought fully up to date (as to progress and the effect of all delays that have occurred up to that date, whether Employer Delays or Contractor Delays) to the point immediately before the occurrence of the Employer Risk Event;
3.2.7.2 the Programme should then be modified to reflect the Contractor’s realistic and achievable plans to recover any delays that have occurred, including any changes in the logic of the Programme proposed for that purpose (subject to CA review and acceptance as provided in Guidance Section 2.2.3);
3.2.7.3 the sub-network representing the Employer Risk Event should then be entered into the programme; and
3.2.7.4 the impact on the contract completion dates should be noted."
-Society of Construction Law (2002)
Kevin, did you miss the update of the programme? Otherwise it sounds like you described an IAP compared to the as-built data on a windows basis (correct me if I'm wrong). Wouldn't that approach get a bit too theoretical in later windows?
It sounds as though you have not been measuring your progress against a baseline.
If you open your progressed programme, then set your original programme as a baseline, any negative float will effectively be a measure of any critical delays.
You could also set contraints for the finish milestones on the late items / packages of work (on your baseline and on progressed programme).
Then set your bars so that they show baseline, actual and remaining.
Or you could go to Reports and set up a dump into Excel.
Cheers
Mark
Hi Kevin
You are describing a Time Impact Analysis as defined in the SCL Protocol 2002 which is the gold standard of delay analysis methods.
When skilfully done it is usually accepted by a tribunal.
For visual effect I set up the As Bult data as an underlying baseline to the As Planned so everything is on view.
Asta has the distinct advantage of different colours on the tasks in the chart - so I use Green for As Planned - Red for delay events and Blue for as built.
Another very useful feature is the Link Category - when you add a driving link from any delay event to the impacted task you can give it a name - Event 01 Design Delay for instance.
With this in place you can switch the link on or off to show both the cumulative and standalone effect of any event.
When changing logic for mittigation the same naming system should be used.
Best regards
Mike Tesro
Hi Syed,
Based on my experience in recent arbitration proceedings in the UK, I would add new activities for each delaying event into the network at the appropriate place in the logic chain. Set the duration of the activity to equal the duration of the delay and you will have the bones of an as-planned impacted programme. However, this will not be sufficient to satisfy most arbitrators let alone a court. Presumably you will have undertaken some mitigation of the delay and it is important that, by reference to the actual chronology of events, you compare your as planned impacted programme to the as-built programme. To do this, I maintain a separate as-planned programme from pre-commencement from the as-built programme showing actual activity start/finish dates. You can then look compare 'time slices' in both programmes to assess: a) the theoretical delay; and b) the actual delay suffered. Where this gets particularly difficult is in trying to show the real impact of the delay in terms of trade stacking in subsequent time periods unless you have a fully resourced logic linked baseline programme to work from. Also, remember that a court or arbitrator will look to offset periods of delay for which the contractor is responsible from any claim against the client. Good Luck!
Kevin T Laverty
Hi Syed
Welcome to Planning Planet
You should impact the delay events on the original baseline and then compare the results with the updated programmes.
Best regards
Mike Testro
Email: PPadmin@planningplanet.com
Replies