An extension of time (EOT) claim has to prove three things: that the contract gives entitlement, that notice was given on time, and that the event delayed the critical path. Forensic schedule analysis is how the third point is proved. If the method does not suit the contract, the records or the question being asked, the claim can be reduced or rejected even where the employer plainly caused the delay.
Below we set out the main delay analysis methods recognised by AACE International and the Society of Construction Law (SCL), and when each is the right choice for projects in the UK, the UAE and Saudi Arabia.
What is forensic schedule analysis?
Forensic schedule analysis is the use of critical path method (CPM) scheduling to work out what delayed a project, by how much, and who bears the risk for each delay. It turns programmes, progress records and correspondence into a reasoned account of cause and effect for an EOT submission, adjudication, arbitration or litigation.
Two documents guide most of this work:
- AACE International Recommended Practice 29R-03, Forensic Schedule Analysis. It classifies methods by whether they are retrospective or prospective, observational or modelled, static or dynamic, and additive or subtractive, and sets out nine method implementation protocols (MIPs).
- The SCL Delay and Disruption Protocol, 2nd edition (February 2017). Widely used in the UK and the Middle East, it describes six common methods of delay analysis and does not prefer any one method in every case.
Neither is binding unless the contract adopts it, but tribunals and experts refer to both.
The main delay analysis methods
1. As-planned vs as-built
How it works. The baseline programme is compared with what actually happened. Differences in dates and durations on the critical path are identified and explained from the project records. The SCL Protocol also describes a windowed version, where the comparison is made period by period.
Records needed. A reasonable baseline programme, reliable as-built dates for key activities, and documents explaining why activities slipped.
Strengths. Simple, cheap and easy to follow. It rests on what actually happened.
Weaknesses. In its basic form it does not deal well with a critical path that changes during the project, and it can attribute delay to the wrong event where several delays overlap.
When tribunals accept it. On simpler projects with a stable critical path, or where updates are poor but as-built facts are well recorded.
2. Impacted as-planned
How it works. Delay events are modelled as fragnets (small networks of activities) and inserted into the baseline programme. The programme is then rescheduled and the movement in the completion date is taken as the delay caused by those events.
Records needed. A reliable baseline programme with sound logic, and evidence supporting each modelled delay event. Actual progress is not used, which is the method’s main weakness.
Strengths. Quick and low cost; useful very early in a project.
Weaknesses. It ignores actual progress and contractor delay. The answer is theoretical and depends entirely on the baseline.
When tribunals accept it. Rarely on its own after completion, and least of all where there is clear contractor delay or poor baseline logic.
3. Collapsed as-built (but-for)
How it works. An as-built programme is built with logic linking the activities. Delay events attributed to the employer are then removed, and the programme is “collapsed” to show when the works would have finished but for those events. The difference is the delay attributed to the employer. AACE treats this as a modelled, subtractive method.
Records needed. Detailed as-built records: actual start and finish dates, sequences and resource information. Planned programmes are less important.
Strengths. Useful where no reliable baseline or updates exist but the as-built record is good. It answers a question tribunals understand: when would we have finished but for this event?
Weaknesses. The as-built logic is reconstructed, results are sensitive to which events are removed and in what order, and the but-for completion date is hypothetical, so concurrency and each removal need to be validated against the records.
When tribunals accept it. Where the as-built logic is well evidenced and each assumption is explained.
4. Time impact analysis (TIA)
How it works. A fragnet for each delay event is inserted into the most recent accepted programme update before that event, and the programme is rescheduled to measure its effect on completion. Because each event is tested against the programme current at the time, the method reflects actual progress up to that point.
Prospective TIA is carried out during the project to forecast the effect of an event and support a timely EOT. Retrospective TIA applies the same steps after the event, using the updates that existed at the time. It recreates the assessment that should have been made then; it does not necessarily show the delay that actually occurred.
Records needed. A sound baseline, regular and reliable programme updates, and clear records of each delay event.
Strengths. It suits contemporaneous assessment where the contract and the programme records support it, and gives a clear, event by event audit trail.
Weaknesses. It measures likely delay, not actual delay. Used retrospectively, it can conflict with the as-built facts. It is only as good as the updates it uses.
When tribunals accept it. Strongly for EOT assessments made during the project, especially where the contract requires a prospective assessment. After completion, tribunals tend to check retrospective TIA results against the as-built record.
5. Windows / time slice analysis
How it works. The project duration is divided into windows, usually aligned with programme updates or key milestones. Within each window the critical path is identified from the contemporaneous update, and the delay that occurred during that window is measured and attributed to its causes. The SCL Protocol calls this time slice windows analysis.
Records needed. A series of reliable, contemporaneous programme updates, ideally monthly, together with progress reports and correspondence. Where updates are missing or flawed, they may need to be corrected or rebuilt, which must be done openly.
Strengths. It follows the critical path as it actually developed, captures employer and contractor delay, and deals with concurrency in a structured way.
Weaknesses. It needs good updates and significant effort. Any revision to updates will be closely examined.
When tribunals accept it. Frequently, on large or complex projects where good updates exist.
6. Longest path analysis
How it works. Working backwards from the actual completion date, the analyst traces the as-built longest path through the project to identify which activities actually governed completion. Delay along that path is then attributed to its causes. The SCL Protocol describes this as retrospective longest path analysis.
Records needed. A detailed as-built programme with reliable dates and logic.
Strengths. It is grounded in what actually happened and identifies the real as-built critical path.
Weaknesses. It relies on reconstructed as-built logic and shows less clearly how the critical path shifted over time.
When tribunals accept it. On completed projects with good as-built records, often as a check on, or in combination with, a windows analysis.
Check the programme before choosing a method
Whichever method is used, the programmes behind it must be tested first. In Primavera P6 that means checking open ends and logic, data dates, hard constraints, calendars, the critical and longest paths, actual dates against progress records, and any revisions between updates. Problems found at this stage decide which methods are still open, and an unvalidated programme is the first thing an opposing expert will attack.
Comparison table
| Method | Prospective / retrospective | Records needed | Effort | Best used when |
|---|---|---|---|---|
| As-planned vs as-built | Retrospective | Baseline, as-built dates | Low to medium | Simple project, stable critical path, few updates |
| Impacted as-planned | Usually prospective | Baseline with sound logic | Low | Early in the project, little progress yet, contract requires it |
| Collapsed as-built | Retrospective | Detailed as-built records | Medium to high | No reliable baseline or updates, good as-built data |
| Time impact analysis | Prospective or retrospective | Baseline, regular updates, event records | Medium to high | EOT during the project; contracts requiring prospective assessment |
| Windows / time slice | Retrospective | Series of reliable updates | High | Complex projects, disputes, concurrency issues |
| Longest path | Retrospective | Detailed as-built programme | Medium to high | Completed projects, to identify the actual critical path |
Choosing a method under FIDIC, NEC4, JCT and Gulf contracts
The SCL Protocol says the choice of method should take account of the contract terms, the nature of the delay events, the value of the dispute, the time available and, above all, the records and programmes that exist. Contract wording often narrows the choice.
FIDIC 2017. Sub-Clause 8.5 sets out the grounds for an extension of time and refers to concurrent delay, which is to be assessed under any rules in the Special Provisions or, if there are none, with due regard to all relevant circumstances. Entitlement sits in Sub-Clause 8.5, but the procedure sits in Sub-Clause 20.2: a Notice of Claim within 28 days of becoming aware of the event (20.2.1) and a fully detailed claim within 84 days (20.2.4). A late Notice of Claim can lose the entitlement, subject to the late-notice provisions in Sub-Clause 20.2.5 and any amendments in the Particular Conditions. In practice this favours a prospective, TIA-style analysis on the current programme, submitted promptly, supported later by a retrospective method if the matter goes to a dispute.
NEC4. Compensation events are notified under Clause 61, quoted for under Clause 62 and assessed under Clause 63. Delay to the Completion Date is assessed by reference to the Accepted Programme current at the dividing date, which is a prospective, TIA-style approach. The Contractor generally has eight weeks to notify a compensation event or risk losing entitlement, although the time bar does not apply where the Project Manager should have notified the event. Keeping the Accepted Programme up to date is essential.
JCT. JCT contracts require notice of delay and allow the Architect/Contract Administrator to fix a later Completion Date where a Relevant Event is likely to delay or has delayed completion. Relevant Events are listed in the contract, and the wording differs between the 2016 and 2024 editions and between contract forms, so check the edition in use. JCT does not prescribe an analysis method. TIA is common for interim assessments, while retrospective methods such as windows analysis are often used in adjudication or litigation after completion.
Gulf practice. Many projects in the UAE and Saudi Arabia use amended FIDIC forms, and tribunals there are familiar with the SCL Protocol. Local law can affect how claims are decided. In the UAE, the Civil Code imposes a general duty of good faith and allows courts to adjust agreed damages in some circumstances, and onshore courts often appoint their own experts. In Saudi Arabia, government contracts are subject to the public procurement regime, which has its own rules on time extensions, and private contracts are now read alongside the Civil Transactions Law. Contract amendments, notice requirements and local law should be checked before a method is chosen.
A short example
Take an illustrative case. A contractor on a Riyadh building project receives revised structural drawings eight weeks late. The monthly P6 updates are reliable. A prospective TIA, using the update immediately before the late drawings, shows a 34-day effect on the completion date and supports a timely EOT request under Sub-Clause 20.2. If the matter later goes to arbitration, a windows analysis of the same updates tests whether the 34 days actually occurred, and whether contractor delays to MEP procurement in the same window were concurrent. For more on that question, see our guide to concurrent delay in construction, and for a shorter overview of the options, delay analysis methods compared.
Common mistakes
- No contemporaneous updates. Without regular, accepted programme updates, the strongest methods become unavailable or must rely on reconstructed programmes that are easy to attack.
- Retrospective TIA on a bad baseline. Inserting fragnets into a programme with missing logic, constraints or unrealistic durations produces precise looking but unreliable answers. The baseline should be checked before any analysis.
- Ignoring concurrent delay. The SCL Protocol says true concurrency is relatively rare, but tribunals expect the analysis to identify and deal with contractor delays honestly. An analysis that only finds employer delay is unlikely to be believed.
- Mixing methods without explanation. Using one method for some periods and another for others, without a clear reason, invites the argument that the results were chosen to suit the claim.
- Choosing the method before reviewing the records. The available records should drive the method, not the other way round.
Frequently asked questions
Which delay analysis method is best?
None is best in every case, as the SCL Protocol makes clear. It depends on the contract, the records, the size of the claim and whether the work is done during or after the project.
What is the difference between prospective and retrospective analysis?
A prospective analysis forecasts the likely effect of an event at the time it happens. A retrospective analysis looks back at what actually happened once the delay has occurred, often after completion.
Is time impact analysis accepted after a project is complete?
It can be, but tribunals usually check retrospective TIA results against the as-built record. Where the two conflict, an observational method such as windows analysis is often preferred.
Which method does an expert witness usually prefer in arbitration?
Experts often use an observational, contemporaneous method such as windows analysis where the updates allow it, and check it against the as-built record. The choice is explained and justified in the expert report, because tribunals look closely at why a method was selected.
Can we still claim an EOT if programme updates were not kept?
Often yes, but the options narrow. Methods such as as-planned vs as-built or collapsed as-built may still be possible if the as-built records are good, though the analysis will face closer scrutiny.
Talk to us
If you are preparing or responding to an EOT claim, we can review your programmes and records and advise on the forensic schedule analysis method most likely to hold up.
Book a free 30-minute call with our team, or read more about our forensic schedule analysis, time impact analysis (TIA) and construction delay analysis services.
