Delay Analysis & Extension of Time
Whose delay drove completion — and does the record prove it?
I analyse delay on major railway projects and turn it into extension-of-time claims under FIDIC 1999 and 2017: the notice, the programme of record, the critical-path analysis in Primavera P6, and the consultation with the Engineer that follows. The method is chosen to fit the records — because the other side's planner will test it against them.
- days of extension of time ultimately granted, across four railway contracts
- 3,000+days of extension of time ultimately granted, across four railway contracts
- extension-of-time submissions prepared or led
- 10extension-of-time submissions prepared or led
- delay events modelled in Primavera P6
- ~40delay events modelled in Primavera P6
- analysis methods used — each chosen to fit the records
- 5analysis methods used — each chosen to fit the records
Illustrated · one delay, three questions
How an extension of time is carried
01
Notice, inside the time bar
Within 28 days of becoming aware of the event — Sub-Clause 20.1 (1999) or 20.2.1 (2017) — with contemporaneous records kept from that day.
02
The programme of record
Fix the programme the delay is measured against: the accepted baseline, or the last statused update before the event — in its native P6 file, not a PDF.
03
A method that fits
Chosen against the contract, the events, the records, the quality of the programme and the forum it may end up in — the factors the SCL Protocol lists.
04
Cause and effect
Each event modelled as a fragnet and its effect measured on completion, with float and concurrency dealt with openly rather than left for the other side to find.
05
Fully detailed claim
Within 42 days (1999) or 84 days (2017), with interim updates while the effect continues — narrative, programme files and exhibits that agree with each other.
06
Consultation & determination
Walking the Engineer through the analysis in consultation, answering the determination, and keeping the route to the DAB open if it does not follow.
Methods, and when each fits
The method has to match the records
The SCL Delay and Disruption Protocol (2nd edition, 2017) names six common methods and no preferred one. Each asks a different question and needs different records. Here is when I reach for each — plus the one every railway needs.
Impacted as-planned
Cause → effect · prospective
Needs: A sound baseline programme.
When I use it: A quick, transparent first look. Weak once the job has moved far from its plan, so I model each event alone and then all together, where each can be tested.
Time impact analysis
Cause → effect · on the last update
Needs: Statused updates around each event.
When I use it: My default on a live project, and the approach the SCL Protocol favours for assessing extensions while the work is still going on.
Time slice windows
Effect → cause · window by window
Needs: A reliable update for every window.
When I use it: When the contemporaneous updates exist and the question is what actually drove completion in each period.
As-planned v as-built windows
Effect → cause · plan against record
Needs: A good as-built record, even if the updates are weak.
When I use it: When the programme updates are poor but the site records are good.
Retrospective longest path
Effect → cause · traced back from completion
Needs: As-built dates and logic.
When I use it: To test a concurrency finding: whose work was actually on the critical path, update by update.
Collapsed as-built
Cause → effect · subtractive
Needs: A detailed as-built with logic.
When I use it: As a but-for check — take one event out and see what moves.
Time-chainage
Linear works · progress against location
Needs: Progress by chainage and date.
When I use it: On every railway. A stoppage shows as a gap on the line — the picture that makes a delay obvious to someone who is not a planner.
From the files
Extensions of time, analysed and defended
Railway contracts under FIDIC, from a single event to six submissions on one job. Anonymised, with rounded figures.
Six submissions, one contract
~1,000 days
Impacted as-planned → windows → TIA
Six successive extension-of-time submissions on an electrified railway of about 200 km, each built in Primavera P6. The method moved as the records improved — impacted as-planned first, then ten monthly windows, then time impact analysis with event fragnets. Across four consecutive submissions about 1,000 days were claimed and about 1,000 granted: each early shortfall was taken up again in the next submission.
Which record?
~800 days claimed, more granted
Hybrid · observational + modelled
On a railway section of about 130 km the Engineer rejected an extension of about 800 days as “unsubstantiated”, without saying what was missing. The reply asked one question — which record? — and rested on a fragnet-by-fragnet critical path with zero float from earthworks to commissioning. The completion date ultimately granted was later than the one claimed.
Land that could not lawfully be worked
~900 days
Hybrid · observational + modelled
The Engineer's view was that the slowdown was the Contractor's own finance problem. The analysis showed the land had been “handed over” before the lender's resettlement standards were met, so no contractor could lawfully have worked it. A 20,000-activity programme was rebuilt with time-distance logic so it could carry the analysis. Rejected at first; about 900 days ultimately granted.
One at a time, then together
~91% granted
Impacted as-planned
Six delay events on a long electrified railway section, each modelled on its own in P6 and then all together, so the Engineer could test them one at a time. About 91% of the time claimed was granted. The answer to the determination then showed three independent paths to completion — and the mitigation already secured with a specialist supplier.
Concurrency, month by month
Longest path across updates
The Engineer granted the time but refused the cost, citing concurrency. The critical path was read in every contemporaneous programme update, and each month's driving activities were sorted by who carried their risk. Concurrency stopped being a label and became a question the records could answer.
Behind an international arbitration
~430 km
Time-distance analysis
Two years as the scheduling specialist supporting an international arbitration on a railway of about 430 km. Work stoppages were mapped along the line on time-distance charts and the timeline rebuilt event by event for the delay and disruption experts. The lesson that stuck: a claim is only as good as the records kept before anyone thought of a dispute.
A rebuild for another contractor
Combined network · but-for runs
Asked by another contractor to rebuild an interim extension-of-time claim. Overlapping event fragnets were merged into one network and each event tested with but-for runs — taken out one at a time to see what moved — instead of adding standalone impacts side by side, which only invites a double-counting attack.
Examples are anonymised and figures are rounded. Client, project, contract and correspondence details are withheld for confidentiality.
Positions I hold
Six things every extension of time should get right
Don't wait and see.
Assess a delay while it is happening, on the programme as it then stood. Waiting for the as-built only invites an argument about method later.
Time impact analysisAn extension is reviewed up, never down.
Under Sub-Clause 8.4 of the 1999 forms the Engineer may increase the total extension at each determination, but shall not decrease it. A shortfall can be taken up again in the next submission.
How an EOT claim is builtConcurrency is a fact to prove, not a label.
Both delays must be effective causes of delay to completion over the same period. Until that is shown from the programme, there is nothing to apportion.
Concurrent delayTime and money are separate questions.
An extension granted “at no additional cost” answers the time question. The cost question is decided under the Sub-Clause that carries it — and the no-cost wording should be contested in writing, not accepted in silence.
Prolongation costPrevention has a price.
If the Employer prevents completion and the contract cannot extend time for it, the completion date falls away — and the delay damages with it.
Time at largeRecords before argument.
The best analysis fails on a missing record. Progress reports, site diaries and correspondence are kept as contemporaneous records from the first day of an event.
Right of accessIllustrated notes
The mechanics, drawn step by step
Questions people ask
Delay and extension of time
Which delay analysis method is best?
None, in the abstract. The SCL Delay and Disruption Protocol (2nd edition, 2017) lists the factors that decide it: the contract, the nature of the events, the project, the value at stake, the time available, the records, the quality of the programme and the forum. In practice the records decide most of it — the method has to work with what actually exists.
How long do I have to notify a claim for extension of time under FIDIC?
28 days from when the Contractor became aware, or should have become aware, of the event — Sub-Clause 20.1 in the 1999 forms, 20.2.1 in the 2017 forms. The fully detailed claim follows within 42 days (1999) or 84 days (2017), unless a longer period is agreed with the Engineer. Check the Particular Conditions first: they often change these periods.
Does an extension of time mean I get paid?
Not by itself. Sub-Clause 8.4 (1999) or 8.5 (2017) gives time; Cost, and sometimes profit, depends on the Sub-Clause under which the event falls — access, variations, the Employer's delay and so on. Prolongation cost is then valued for the period when the delay was actually felt.
What is concurrent delay, and does it cost me the extension?
Two delays — one the Employer's risk, one the Contractor's — each an effective cause of delay to completion over the same period. Under the SCL Protocol the Contractor still gets the time, but not the prolongation cost for that period. The 2017 forms send the question to the Special Provisions of the contract; the 1999 forms are silent, so the governing law decides.
Can an extension be granted before the delay has ended?
Yes, and it should be. The SCL Protocol advises against “wait and see”: assess the likely effect when the event happens and adjust as the actual effect becomes known. For events with a continuing effect, FIDIC expects interim claims — monthly under the 1999 forms — until the effect ends.
Do you need the native programme files?
Yes. The analysis is done in the native Primavera P6 file (XER), not on PDF prints — the logic, calendars and float only exist in the file. The baseline, the updates either side of the event and any as-built record are the starting point.
An extension of time heading for determination?
Send the notice, the Engineer's latest letter and the programme file. You will get a straight view of where the analysis is strong and where the other side's planner will push.
Starting earlier, with the programme itself? Programmes →