Time Impact Analysis
Last reviewed 9 September 20262,276 words10 min read
How it's built and where it gets attacked
🟩 In one line — A TIA inserts a small network representing the delay event into the last accepted update before the event, reschedules, and measures how far completion moves; it is the method FIDIC, NEC and the SCL Protocol all point to for contemporaneous assessment, and it gets attacked in exactly four places — the programme it starts from, the fragnet, the data date, and whether it matches what actually happened.
👤 Who this is for — Mid-level planners building their first impacted programme and seniors defending one. Read extension-of-time-basics and fragnets first. You should be comfortable with copying a P6 project, rescheduling, and comparing two schedules.
First, let's be honest about why this page exists
TIA has a reputation as the "proper" method, and so people do it badly with confidence. The most common version: take the original baseline, add a fragnet of whatever length is needed, run it, and announce the result. That isn't a TIA. It's an impacted as-planned with a better name, and it fails for the same reason — the baseline stopped describing the project months ago.
A real TIA is bounded by the current update on one side and by the as-built on the other. It answers "given where the project actually was when this happened, and what the Contractor actually intended to do next, how much did this event push completion?" Get the starting programme right and the TIA mostly defends itself. Get it wrong and nothing downstream can be trusted.
🟨 The standard — what "good" looks like
| Reference | Position |
|---|---|
| SCL Protocol 2nd ed., Core Principle 4 and Part B §4 | Contemporaneous assessment of delay events is preferred; TIA is the method described for it. The 2nd edition stepped back from recommending TIA for after-the-fact disputes — for those, method choice depends on records, time available and proportionality (Part B §11). |
| SCL Protocol Part B §11 method table | TIA classified as prospective, cause-and-effect; requires a validated baseline and updates. |
| AACE RP 52R-06 | Dedicated TIA practice: use the most recent update, validate it, model the event as a fragnet, insert, reschedule, compare. Recommends the analysis be done and accepted before the impact is realised where possible. |
| AACE RP 29R-03, MIP 3.6/3.7 | TIA family: modelled, additive, single base (3.6) or multiple base (3.7). The recommended-practice caveats: fragnet must reflect the event only; the base programme must be validated; results are hypothetical unless checked against actuals. |
| NEC3 Cl 62.2 / 63.3; NEC4 Cl 62.2 / 63.5 | The quotation includes a revised programme showing the effect of the event on the Accepted Programme; delay is measured against planned Completion. This is a TIA by another name, and the Accepted Programme is the mandatory starting point. |
| FIDIC 1999 Cl 8.3 / 2017 Cl 8.3 | Revised programme whenever the previous one is inconsistent with actual progress — which is what keeps a valid starting point available. |
🟢 Rule to remember: the TIA starts from the last accepted update before the event, not from the baseline — and the fragnet contains the event and nothing else.
How it actually works
Step 1 — Choose the base programme. The last update with a data date before the event started, ideally accepted by the Engineer or Project Manager. If the event started on 12 June and the updates are monthly, the 31 May update. If the last update is three months stale, you have a records problem before you have an analysis — status it to the day before the event from daily reports, and declare that you've done so.
Step 2 — Validate it. Before impacting, check: data date correct; actual dates match daily reports; no out-of-sequence chaos (see out-of-sequence-progress); no constraints doing the work of logic; the critical path makes sense. Run the DCMA checks. An unvalidated base is attack point number one, and the other side will run those checks for you.
Step 3 — Build the fragnet. In a separate WBS node so it can be identified and removed:
| Element | Example |
|---|---|
| Event milestone | "Revised structural drawings issued — Rev C" with the actual issue date |
| Consequence activities | "Review Rev C and re-detail rebar — 5d", "Re-fabricate beam cages — 8d", "Re-mobilise fixers — 2d" |
| Links in | Predecessor: the point in the existing network where the event bites (e.g. FS from event milestone into the re-detailing) |
| Links out | Successor: the existing activity that couldn't proceed (e.g. FS into "Rebar L6 Zone A") |
Durations from records where the event is over, from the duration formula where it isn't. Each duration gets a basis line. No Contractor-risk items inside the fragnet.
Step 4 — Impact and reschedule. In P6: copy the base project (or create a Reflection — right-click the project → Create Reflection — which lets you merge back or discard). Insert the fragnet, keep the data date where it was, reschedule (F9). Read the completion milestone: base finish versus impacted finish. That difference, in working days on the completion milestone's calendar, is the prospective delay.
Step 5 — Compare and record. Tools → Schedule Comparison (Claim Digger in older versions): base against impacted. The report shows every changed date and relationship — proof that only the fragnet changed. Attach it.
Step 6 — Check against reality if you can. If the event is over, compare the impacted forecast with what the as-built shows. If they diverge badly, say why. A TIA that predicted 20 days where the as-built shows 6 needs an explanation — mitigation, concurrent Contractor delay, or a fragnet that was too generous. Better you find it than the Engineer.
Step 7 — Multiple events: chronological, cumulative. Event 1 impacted into the update before it. Event 2 impacted into the update before it, which already reflects event 1's actual effect. Never impact five events into one base in one go — the interactions are lost and the result overstates.
The four attack points
| Attack | What they say | Your defence |
|---|---|---|
| The base | "Your update was wrong / stale / not accepted" | Acceptance correspondence; validation checks attached; if unaccepted, show the Engineer's comments were minor and unrelated to the affected path |
| The fragnet | "Your durations are inflated / it includes your own delays" | Basis line per activity; records for actual durations; fragnet reviewed against daily reports; Contractor-risk items shown separately |
| The data date | "You impacted an event that started in June into an April programme" | Use the right update; if statusing was needed, show the source records |
| Reality | "It didn't actually delay you that much" | Prospective is what the contract asks for; but reconcile with as-built and explain the difference. Under NEC the prospective figure stands (Cl 65.2 / 66.3 — verify); under FIDIC expect the Engineer to look at both |
📜 Prospective result and the contract
Under NEC, the quotation's revised programme is the assessment, and once implemented it isn't revisited if the forecast proves wrong — which cuts both ways. Under FIDIC, the Engineer determines "fairly" and will weigh what actually happened; a prospective TIA submitted promptly (Cl 20.1 / 20.2 interim claims) followed by a final figure when the event closes out is the pattern the Engineer is most likely to accept. In either case, a TIA done six months after the fact and dressed up as "contemporaneous" is easy to expose from the file's own timestamps.
🟥 Where people go wrong
- Starting from the baseline. The baseline is month 1. The event is month 11. Ten months of re-sequencing, slippage and recovery are ignored, and the fragnet lands on logic that no longer exists on site.
- Impacting an unstatused programme. The base update says the slab was 60% done; it was actually poured a week before the event. The fragnet now delays work that had already finished.
- The all-purpose fragnet. One fragnet, 30 activities, covering the late drawings, the late access, the design change and — quietly — the subcontractor's absence. Reviewers pull the subcontractor's days out and then discount the rest for good measure.
- Batch-impacting. Eight events, one base, one run: 84 days. Done chronologically, each into its own update: 51 days. The 33-day gap is what the Engineer's consultant will find, and your credibility goes with it.
- Ignoring mitigation already in the update. The site had re-sequenced to soften the blow before the update was cut. Impacting a pre-mitigation programme claims delay that was already absorbed — and the Employer will point out you're claiming for time you didn't lose.
- Not keeping the impacted file. The result was in a PowerPoint; the P6 file was overwritten by the next update. Two years later, no one can reproduce the number. Keep base, impacted and comparison report together, named with the event ID.
⚖️ When you're challenged
"Your 'contemporaneous' TIA has a file creation date eight months after the event." "The file you've been sent is the clean copy assembled for the claim. The original impacted reflection was created within the update cycle — here's the schedule log dated that month, and the interim notice under Cl 20.1 that quoted the same result. The numbers haven't changed; the folder has."
"You've added fourteen days for re-fabrication. The subcontractor's own programme said eight." "Their eight assumed the original cages could be modified. Rev C changed bar diameters, so they were scrapped — the delivery notes and the re-order are attached. Fourteen is the actual, from the fabrication shop's dispatch dates. If you'd rather use eight, the prospective figure drops to nine days and I'll show that run as well."
"The as-built shows completion only moved six days, not twelve." "Correct, and the reconciliation is in section 5. The twelve was the prospective impact at the time; we then accelerated the finishes with a second crew, which is why the as-built is six. The contract entitles us to the twelve — the acceleration is a separate cost matter — but I've shown both so nobody has to guess."
📄 Related pages
- Extension of Time Basics — the four legs the TIA sits inside
- Fragnets — building the event network properly
- Choosing a Delay Method — when TIA isn't the method; windows and collapsed as-built
- Concurrent Delay — the check in every TIA
- P6 Reflections and What-If — the safe way to run the impact
- P6 Schedule Comparison — proving only the fragnet changed
- Statusing a schedule — getting the base right before you impact it
- Aace 29r 03 summary — where TIA sits in the method taxonomy
✏️ Worked example
Six-storey commercial building, Dubai, FIDIC 2017. On 12 June the Engineer issues revised structural drawings (Rev C) changing rebar in the transfer beams at Level 3. Contractor notice given 19 June.
Base programme: update at DD 31 May, accepted by the Engineer on 8 June. Validated: 0 open ends, 2 constraints (both contractual), 1.4% out-of-sequence, critical path through structure → façade → MEP T&C.
| Base programme | Value |
|---|---|
| Rebar L3 Zone A (ST-3A-020) | Planned start 14 June, 6 days, TF 0 |
| Completion milestone | 18 March following year |
Fragnet (WBS node "DE-04 Rev C transfer beams")
| ID | Activity | Duration | Basis |
|---|---|---|---|
| DE-04-M | Rev C issued | milestone, 12 June | Transmittal 0193 |
| DE-04-010 | Review Rev C, re-detail shop drawings | 4 d | Detailer's actual, 13–17 June |
| DE-04-020 | Shop drawing approval | 5 d | Cl 4.1 / spec review period, used actual 3 days |
| DE-04-030 | Re-fabricate beam cages | 8 d | Fabricator dispatch notes |
| Link out | FS → ST-3A-020 | Original cages unusable |
Result after reschedule (DD held at 31 May):
| Base | Impacted | Movement | |
|---|---|---|---|
| ST-3A-020 start | 14 June | 3 July | +15 working days |
| Completion milestone | 18 March | 4 April | +14 working days |
One day of the fifteen was absorbed by a short overlap downstream (SS lag between column and slab rebar); the comparison report showed 4 added activities, 2 added relationships, 0 other changes.
Concurrency check: At DD 31 May the façade sample approval (FC-005) was 3 days late on the Contractor's side, float 9 days. Not critical before or after. Stated.
Submission: interim claim under Cl 20.2 with the prospective 14 days on 25 June. Detailed claim on 2 September (within 84 days) with actuals: re-detailing took 4 days as forecast, fabrication 9. Final figure 15 days, agreed under Cl 3.7 at 14 with the extra fabrication day treated as Contractor's fabricator performance. Reflection file, base XER, impacted XER and comparison report archived under DE-04.
📖 References
- Society of Construction Law, Delay and Disruption Protocol, 2nd ed. (2017), Core Principle 4; Part B §4 and §11
- AACE International RP 52R-06, Time Impact Analysis — As Applied in Construction
- AACE International RP 29R-03, Forensic Schedule Analysis, MIP 3.6 and 3.7
- FIDIC 1999 Cl 8.3, 8.4, 20.1; FIDIC 2017 Cl 3.7, 8.3, 8.5, 20.2 (check the edition in your contract)
- NEC3 ECC Cl 62.2, 63.3, 65.2; NEC4 ECC Cl 62.2, 63.5, 66.3 (check the edition in your contract)
- Oracle Primavera P6 Professional User Guide — Reflections, Schedule Comparison, Schedule Log
General guidance, not legal advice. Contract wording, editions and amendments differ on every project. Read your own contract and take professional advice before relying on anything here in a claim or a dispute.
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about time impact analysis. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience