Time Impact Analysis: How to Prepare One for a FIDIC EOT Claim
The Engineer's reply to most extension of time claims is the same question: how do you know it is 21 days, not 10, or 40? A round number backed by a paragraph of argument does not survive that question. A Time Impact Analysis does. This guide shows what a TIA is, the method behind it, a worked example, and the mistakes that get one rejected.
What a Time Impact Analysis Is
A Time Impact Analysis, usually shortened to TIA, is a delay analysis method that measures the effect of a single delay event on the Time for Completion. It works by taking the current accepted construction programme, inserting the delay event into it as a small sub-network — a "fragnet" — at the point the event actually occurred, and recalculating the critical path.
Whatever shift appears in the completion date after that recalculation is the extension of time the event caused — not an estimate, not a proportion of the overall overrun, but a number produced by the same critical path logic the programme was built on.
The Society of Construction Law Delay and Disruption Protocol names Time Impact Analysis as one of the recognised methods for assessing extension of time entitlement, and it is the method most FIDIC Engineers are comfortable receiving, since it uses the programme both parties already accepted rather than a reconstruction built after the fact.
Key Takeaway: A Time Impact Analysis inserts a delay event into the current accepted programme and recalculates the critical path. The shift in the completion date that results is the extension of time — a calculated number, not an estimate.
When to Use a TIA — and When Another Method Fits Better
TIA is a prospective method: it is prepared at, or shortly after, the moment the delay event happens, using the programme as it stood then. That makes it the natural fit for a single, dateable event — a late instruction, a variation, a delayed approval — assessed close to real time, which is exactly the situation a FIDIC notice and particulars are built around.
Other methods suit other situations. As-Planned vs As-Built compares the original plan against what actually happened, reconstructed at the end of the project — useful when nobody analysed the delays as they occurred. Windows analysis studies the critical path period by period — useful for multiple overlapping causes across a long project. Retrospective methods answer "what happened, after the fact." A TIA answers "what will this event do, right now." For a single, clearly dated cause with an up-to-date accepted programme behind it, TIA is usually the strongest and simplest choice.
Key Takeaway: TIA suits a single, dateable event analysed near real time using the live programme. As-Planned vs As-Built and Windows analysis are retrospective tools for reconstructing delay after the fact or across many overlapping causes.
The Method, Step by Step
Stripped of the scheduling software, a Time Impact Analysis is five steps:
- Take the current accepted programme. The last update accepted before the delay event — not the tender baseline, and not a later update that already absorbs the event's effect.
- Identify the critical path. Confirm which activities have zero float and drive the completion date at that moment.
- Build the fragnet. Model the event as a small logic-linked sub-network, tied into the existing programme at the correct point.
- Insert it and recalculate. Add the fragnet at the event date and let the software recalculate the critical path.
- Read off the impact. The difference between the new and old completion dates is the extension of time attributable to that event.
Every step depends on the one before it. A fragnet built on logic nobody would recognise, or inserted into the wrong programme version, produces a number that looks precise and is not defensible.
Key Takeaway: Five steps: take the last accepted programme, confirm the critical path, build the fragnet, insert it and recalculate, then read off the shift in the completion date. Each step depends on the one before it being sound.
Worked Example: A Variation Instruction Delay
A retaining wall redesign is instructed by the Engineer under Sub-Clause 13 on 10 March 2026. The revised design requires an additional geotechnical review and a foundation-detail change before construction can resume — activities the original programme never contained.
The Contractor's programmer takes the programme update accepted on 3 March 2026, the last one before the instruction, in which the retaining wall sits on the critical path feeding into the backfill and access road activities behind it. A fragnet is built: 6 days for the geotechnical review, 4 days for the foundation redesign approval, and 3 days to mobilise the revised rebar — 13 days of new, logic-linked activity, tied in at 10 March. Because Sub-Clause 13 variations run their clock from the instruction date rather than from awareness, 10 March is also the date that matters for the Contractor's notice.
Recalculating the whole programme with the fragnet inserted pushes the retaining wall completion back by 13 days, and because that activity is critical, the same 13 days appear at the overall Time for Completion — not a round estimate, but the output of the same critical path logic the Engineer already accepted in the 3 March programme.
Once the analysis gives a defensible day count, the covering notice and particulars still have to go out on time. Tools such as ChatNotice draft that covering letter once the entitlement and day count are known, for delay types including Variations, Unforeseen Physical Conditions, and Delayed Drawings — the TIA supplies the number; the notice still has to carry it on time.
Key Takeaway: In the worked example, a 13-day fragnet for an instructed variation is inserted at the instruction date and pushes the critical completion date back by 13 days — the same number the particulars then carry, tied to the same clause and the same date.
Records That Make a TIA Defensible
A Time Impact Analysis is only as strong as the programme and records behind it. The Engineer's first move, almost always, is to test whether the inputs are real.
- The accepted programme itself — formally accepted, or regularly submitted and not objected to, immediately before the event.
- Evidence the fragnet durations are realistic — quotations, lead times, or comparable durations elsewhere in the programme.
- The date of the event — the instruction, the condition, or the denied access date, matching the fragnet.
- Contemporaneous progress records — daily reports and photographs of the works when the fragnet is inserted.
- The programme software file itself — so the calculation can be checked, not just the printed answer.
A one-page summary with no underlying programme file invites the Engineer to ask for the working — and a claim that cannot show its working looks like a guess dressed up as a calculation.
Key Takeaway: An accepted programme, realistic fragnet durations backed by evidence, the correct event date, contemporaneous progress records, and the underlying software file — without these, a TIA is a number nobody can check.
Common Mistakes That Get a TIA Rejected
Most Time Impact Analyses fail for a small set of recurring reasons, not for anything exotic:
- Wrong programme version. Fragnet inserted into the tender baseline instead of the last accepted update.
- Unsupported fragnet durations. Round numbers instead of durations tied to quotations, lead times, or comparable actual activities.
- Ignoring concurrent delay. Claiming the full fragnet impact when a second, unrelated delay was also live on the same activities.
- Logic that does not match reality. Fragnet links a competent programmer looking at the actual sequence of work would not recognise.
- No underlying file. A chart or summary table with no way for the Engineer to open the programme and check the calculation.
- Done too late. Left until the particulars deadline is close, forcing a rushed reconstruction instead of a contemporaneous analysis.
Each of these is a credibility problem before it is a technical one — a TIA the Engineer can open and check earns different scrutiny than one it must take on faith.
Key Takeaway: TIAs get rejected for the wrong programme version, unsupported fragnet durations, ignored concurrency, unrealistic logic, a missing underlying file, or being done too late. Each one turns a calculation into something that looks like a guess.
How a TIA Fits the Notice and Particulars Timeline
A Time Impact Analysis is evidence, not the notice itself. Under FIDIC 1999, the Contractor must still give notice within 28 days of becoming aware of the delay event — or, for a Variation, within 28 days of the instruction, since that is what starts the clock for that clause. The TIA does not pause that deadline, and it is rarely finished that fast.
Where the TIA belongs is the detailed particulars that follow — due within 42 days under FIDIC 1999, or 84 days under the 2017 Second Edition, with the methodology, the fragnet, and the day count set out in full. Sending the notice late while a perfect TIA is finished protects nothing; a plain, on-time notice followed by a properly worked TIA in the particulars protects everything.
Key Takeaway: The notice is still due within 28 days regardless of whether the TIA is ready. The TIA belongs in the particulars — 42 days under FIDIC 1999, 84 days under the 2017 edition — as the evidence behind the day count, not as a reason to delay the notice.
Frequently Asked Questions
What is a Time Impact Analysis in a FIDIC extension of time claim?
A Time Impact Analysis (TIA) is a prospective delay analysis method. It takes the current accepted programme, inserts the delay event as a fragnet at the point it occurred, and recalculates the critical path to show the impact on the Time for Completion. It answers the question an Engineer always asks: how many days, and why exactly that many.
Do I need software like Primavera P6 to prepare a Time Impact Analysis?
In practice, yes, for anything beyond a trivial delay. A TIA depends on recalculating the critical path through a logic-linked network, and scheduling software such as Primavera P6 or Microsoft Project does that automatically. The software runs the calculation — the analysis itself is the fragnet, the logic links, and the judgment about what a competent programmer would have done.
What is the difference between a Time Impact Analysis and an As-Planned vs As-Built analysis?
A Time Impact Analysis is prospective — done at, or shortly after, the moment the delay event happens, using the programme as it stood then. As-Planned vs As-Built is retrospective — done at the end of the project, comparing the original plan against what actually happened. TIA suits discrete, dateable events assessed in real time; As-Planned vs As-Built suits analysis reconstructed after the fact from as-built records.
What programme do I insert the delay event into — the baseline or the latest update?
The current accepted programme immediately before the delay event, not the original tender baseline. The baseline ignores every change and prior delay that already moved the critical path. The last accepted update captures where the project genuinely stood the moment the new delay hit — that is what makes a TIA prospective rather than theoretical.
Does a Time Impact Analysis replace the notice under Sub-Clause 20.1?
No. The notice is still due within 28 days of becoming aware of the delay event under FIDIC 1999, regardless of whether the TIA is finished. The TIA is programme evidence supporting the detailed particulars, due within 42 days under FIDIC 1999 (84 days under the 2017 Second Edition) — it does not extend or replace the notice deadline.
Authoritative Sources
This guide reflects the FIDIC Conditions of Contract and established delay-analysis authority. For the primary materials, see:
- FIDIC Conditions of Contract — the official contract suite published by the International Federation of Consulting Engineers, which sets out the extension of time and claims provisions a TIA is prepared to support.
- SCL Delay and Disruption Protocol — the Society of Construction Law's protocol, which sets out Time Impact Analysis alongside the other recognised delay analysis methods and when each is appropriate.
About the Author
Muhammad M. Jiwani is a Project Director with 15 years' experience on major infrastructure and energy projects administered under FIDIC contracts. He writes from first-hand experience serving notices and managing contractual claims on live projects.