What is Time Impact Analysis?
Time Impact Analysis (TIA) is a prospective delay analysis method that measures the impact of a specific delay event on the project's critical path and contractual completion date. Unlike retrospective methods such as the collapsed as-built or as-planned vs as-built techniques, TIA is performed at the time of each impacting event using the programme that was current at that moment.
The SCL Delay and Disruption Protocol (2nd Edition, 2017) — the authoritative guidance document used by courts and arbitrators across the common law world — recommends TIA as the preferred method for prospective delay analysis. It is the methodology that gives your extension of time claim the best chance of succeeding.
SCL Protocol, Core Principle 10: "Where it is not possible to undertake a contemporaneous assessment, the preferred method is to attempt to reconstruct what the position would have been had the assessment been made at the time of the Employer Risk Event."
When to use TIA
TIA is appropriate in most construction delay disputes, but it is particularly valuable in the following situations:
- Employer risk events — when the delay is caused by the employer (late instructions, design changes, access restrictions), TIA demonstrates the prospective impact on completion.
- Concurrent delay — TIA can isolate the dominant cause of delay when both parties have contributed to the overrun.
- Extension of time applications — as a real-time or near-real-time assessment to support an EoT claim under the contract.
- Adjudication and arbitration — where a methodologically sound, court-ready analysis is required at speed.
The TIA methodology
The process follows a logical sequence of eight steps. Each step builds on the last, and the rigour of the analysis depends on the quality of data at each stage.
Step 1: Establish the baseline programme
The starting point is the baseline programme — the contractor's original plan as accepted by the employer. This must be a properly resource-loaded, logic-linked programme, not a simple bar chart. In Primavera P6, this is the target programme. In Asta Powerproject, it is the baseline.
The baseline must be demonstrably reasonable. If the baseline programme contained float or was impractical from the outset, the entire analysis will be challenged. Courts have rejected TIA analyses where the baseline could not be shown to be a realistic prediction of performance.
Step 2: Update the programme to the point of impact
Before inserting the delay event, update the programme to reflect actual progress immediately before the event occurred. This "snapshot" programme shows what the critical path looked like just before the impact. It is sometimes called the "impacted programme" or the "contemporaneous programme".
This step is critical. If you simply insert a delay event into the original baseline without accounting for prior progress, your analysis will overstate or understate the impact.
Step 3: Identify and characterise the delay event
Every delay event must be precisely defined: its start date, end date, duration, and causal link to an Employer Risk Event under the contract. Avoid vague characterisations like "employer delays" — each event must be traceable to a specific instruction, drawing, RFI response or site access restriction.
Practical tip: Build your delay event register from contemporaneous records — site diaries, RFI logs, instruction registers and meeting minutes. A delay that cannot be corroborated by contemporaneous documents will not survive cross-examination.
Step 4: Insert the delay event into the programme
Add a new activity or constraint representing the delay event to the updated programme. This is the "impact". Run the programme calculation to determine the new critical path and the new completion date.
Step 5: Calculate the impact on the critical path
The difference between the completion date before and after inserting the delay event is the prospective delay caused by that event. This is the extension of time to which the contractor is entitled for that event.
Step 6: Identify concurrent delay
If the contractor's own activities were also on the critical path and causing delay at the same time, you must address concurrency. The SCL Protocol distinguishes between true concurrency (both delays occur in the same period and are both on the critical path) and apparent concurrency. The treatment of concurrency depends on the contract and the applicable law.
Step 7: Repeat for each impacting event
TIA is performed sequentially — each event is assessed at the point in time when it occurred, against the programme as it then stood. A project with fifteen significant delay events requires fifteen separate impact assessments.
Step 8: Compile the forensic report
The final report must present each step of the analysis in a format that can be understood by a non-technical decision-maker (an adjudicator, arbitrator or judge) while being rigorous enough to withstand expert cross-examination. It should include the programme files, the event register, the methodology narrative, and the calculated extensions.
Understanding the critical path
The critical path is the sequence of activities that determines the project's completion date. Any delay to a critical activity delays completion by the same amount. Understanding the critical path is the foundation of all delay analysis.
In practice, there are several complicating factors:
- Near-critical activities — activities with very little float that can become critical with a small delay.
- Multiple critical paths — complex projects often have several concurrent critical paths, making analysis significantly more difficult.
- Dynamic criticality — the critical path changes over the life of the project as activities are completed early or late. An activity that was non-critical in month one may become critical by month six.
This is why a contemporaneous TIA — performed at the time of each event — is more defensible than a retrospective analysis. It captures the critical path as it actually was, rather than reconstructing it after the fact.
Identifying and quantifying impacting events
An impacting event is any event that is an Employer Risk Event under the contract and that has or may have an effect on the completion date. Under JCT contracts, these are Relevant Events. Under NEC, they are Compensation Events. Under FIDIC, they are events entitling the contractor to an extension of time under Clause 8.5.
Common categories include:
- Late employer instructions or design information
- Variations (change orders) issued by the employer
- Exceptionally adverse weather conditions
- Force majeure events
- Employer-caused access restrictions
- Suspension instructions
- Discovery of ground conditions different from those anticipated
Worked example
Consider a residential tower project with a 24-month programme and a contractual completion date of 31 December 2025. The contractor's baseline programme shows structural steel installation on the critical path from Month 8 to Month 14.
In Month 9, the employer issues a variation requiring redesign of the connection details. The contractor suspends steel erection for three weeks pending revised drawings. The TIA proceeds as follows:
- The programme is updated to show actual progress as at the date of the variation.
- A new "variation instruction" activity is inserted, consuming 21 calendar days.
- Steel erection is constrained to start after the variation activity is complete.
- The programme is recalculated. The new critical path runs through the delayed steel erection sequence.
- The new calculated completion date is 21 January 2026 — 21 days after the original completion date.
- No concurrent contractor delay is identified on the critical path during this period.
The contractor is therefore entitled to a 21-day extension of time for this event, shifting the contractual completion date to 21 January 2026. The same process is then repeated for each subsequent impacting event.
Run a TIA in 2 minutes
Upload your Primavera P6, Asta or Excel programme and PlanLens produces a court-ready TIA report automatically.
The most common mistakes in TIA
1. Using an unacceptable baseline
The single most common reason TIA analyses fail is that the baseline programme is found to be unreasonable. If the programme was accelerated beyond what was achievable, or contained unexplained float, the analysis built on it is undermined from the start.
2. Failing to update the programme before inserting the impact
Inserting a delay event into the original baseline, without first updating the programme to reflect contemporaneous progress, produces an incorrect result. The analysis must use the programme as it stood at the point of impact.
3. Imprecise event characterisation
Vague delay events — "employer delays to information" — cannot be assessed. Each event must have a defined start date, end date, and contractual basis. Without precision, the analysis cannot be tested or challenged by the other side.
4. Ignoring concurrency
If the contractor was itself causing critical delay at the same time as the employer, failing to address concurrency will undermine the entire analysis. Concurrency must be identified and addressed, even if the conclusion is that it does not affect the entitlement.
5. Using a retrospective method when TIA is required
Some contracts and some adjudicators specifically require a prospective analysis method. Using a collapsed as-built when TIA is mandated can result in the analysis being rejected entirely.
TIA with PlanLens
Traditional TIA requires a delay expert with access to specialist software, weeks of programme analysis, and fees that routinely reach £50,000–£150,000. For smaller claims, this is disproportionate. For urgent adjudications, it may simply be impossible.
PlanLens automates the mechanical steps of TIA — programme comparison, critical path identification, delay quantification and report generation — in minutes. Upload your Primavera P6 .xer file, your Asta XML or your Excel programme, and the platform produces a forensic delay analysis structured in accordance with the SCL Protocol.
The result is the same rigorous analysis that a delay expert would produce, delivered in a fraction of the time and at a fraction of the cost. For straightforward delay events, this is often sufficient for adjudication without further expert involvement. For complex multi-event disputes, it provides the foundation on which an expert can build.