Time Impact Analysis (TIA) in Construction Delay Claims

<div class="ge-article-wrapper"><nav class="ge-toc" aria-label="Table of contents"><p class="ge-toc-label">In this article</p><ul class="ge-toc-list"><li><a href="#how-tia-works">How TIA Works</a></li><li><a href="#the-diagram">The Diagram</a></li><li><a href="#why-tia-matters">Why TIA Matters</a></li><li><a href="#worked-example-design-change-on-a-22m-office-development">Worked Example: Design Change on a £22M Office Development</a></li><li><a href="#tia-vs-other-delay-methods">TIA vs Other Delay Methods</a></li><li><a href="#common-mistakes">Common Mistakes</a></li><li><a href="#frequently-asked-questions">Frequently Asked Questions</a></li></ul></nav><article class="ge-article-body"><p>Time Impact Analysis (TIA) is a delay analysis method that models the impact of a specific event on the critical path of a construction programme. You take the as-planned schedule, insert the delay event as a new activity with its duration and logic links, and measure how much the critical path extends. If the completion date moves by 3.5 weeks, that's the delay attributable to that event. No more guessing. No more arguing about whether the delay was critical.</p><p>TIA is part of the <a href="/en/earned-value/definitions">earned value definitions glossary</a>. For how earned value schedule metrics corroborate delay analysis findings, see the <a href="/en/earned-value/cpi-spi">CPI and SPI formula page</a>.</p><h2 id="how-tia-works">How TIA Works</h2><p>The method follows a structured sequence:</p><ol><li><strong>Establish the baseline</strong>: Use the as-planned programme (or the last agreed update) as at the date just before the delay event</li><li><strong>Model the delay event</strong>: Add a new activity representing the delay, with its actual duration, linked to the affected activities</li><li><strong>Run the schedule</strong>: Forward pass the network with the delay activity inserted</li><li><strong>Measure the impact</strong>: Compare the completion date before and after inserting the delay. The difference is the critical delay caused by that event</li><li><strong>Check the critical path</strong>: Confirm the delay falls on the critical path. If it doesn't affect the critical path, it consumed float but didn't cause project delay</li></ol><p>That's the theory. In practice, TIA requires a reliable baseline programme. No baseline, no TIA. This is why the <a href="/en/earned-value/definitions/accepted-programme">Accepted Programme</a> on NEC4 contracts is so important.</p><h2 id="the-diagram">The Diagram</h2><pre class="ge-ascii-diagram ge-anim">BEFORE: As-Planned Network (simplified) ========================================= [Foundations]──→[Structural Steel]──→[Cladding]──→[M&amp;E Install]──→[Commission] 8 wks 12 wks 6 wks 8 wks 4 wks = 38 wks Critical Path: Foundations → Steel → Cladding → M&amp;E → Commission AFTER: With Design Change Delay Inserted ========================================== [Foundations]──→[Structural Steel]──→[DESIGN CHANGE]──→[Cladding]──→[M&amp;E]──→[Commission] 8 wks 12 wks ▓▓ 3.5 wks ▓▓ 6 wks 8 wks 4 wks (inserted delay) = 41.5 wks Critical Path Extension: 41.5 - 38 = 3.5 weeks Attributable to: Client design change (CE under clause 60.1(1)) ┌─────────────────────────────────────────────────┐ │ Original Completion: Week 38 │ │ Revised Completion: Week 41.5 │ │ Critical Delay: 3.5 weeks │ │ Float Consumed: 0 days (was on CP) │ └─────────────────────────────────────────────────┘</pre><p>The delay sits on the critical path, so the full 3.5 weeks pushes completion. If the design change had affected a non-critical activity with 5 weeks of float, TIA would show zero critical delay.</p><h2 id="why-tia-matters">Why TIA Matters</h2><p>Delay disputes on construction projects usually come down to one question: "Was that event critical?" The contractor says yes. The client says no. Everyone has an opinion but nobody has evidence.</p><p>TIA provides the evidence. It's prospective (forward-looking), which makes it particularly suitable for NEC4 contracts where compensation events are assessed prospectively from the <a href="/en/nec4/dividing-date">dividing date</a>. The SCL Protocol (Society of Construction Law Delay and Disruption Protocol, 2nd edition, 2017) recognises TIA as one of the accepted delay analysis methods.</p><p>I've used TIA on probably 15 projects over the years. It works brilliantly when you have a well-maintained programme with proper logic links. It falls apart when the programme is a bar chart someone drew in Excel. That's not a criticism of the method. It's a criticism of programme management.</p><h2 id="worked-example-design-change-on-a-22m-office-development">Worked Example: Design Change on a £22M Office Development</h2><span class="ge-worked-label">Worked Example</span><div class="ge-callout ge-anim"><p><strong>Scenario:</strong> A £22M NEC4 Option A office development in Birmingham. The Accepted Programme shows a planned completion at week 52. At week 20, the Project Manager instructs a change to the structural steel design for floors 3-5 (a compensation event under clause 60.1(1)).</p><p><strong>The delay event:</strong></p><ul><li>Steel fabrication drawings need revision: 2 weeks</li><li>Revised steel delivered to site: 1.5 weeks lead time (overlaps with drawing revision)</li><li>Net critical delay to steel erection: 3.5 weeks</li></ul><p><strong>TIA process:</strong></p><ul><li>Take the Accepted Programme as at week 20</li><li>Insert a 3.5-week delay activity between "Steel Fabrication Complete" and "Steel Erection Floors 3-5"</li><li>Run the forward pass</li><li>Original completion: week 52. Revised completion: week 55.5.</li><li><strong>Critical path extension: 3.5 weeks</strong></li></ul><p><strong>The EVM corroboration:</strong> Before the design change, <a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> was tracking at 0.98. After the event, SPI dropped to 0.91 over the following three periods. The SPI decline aligns with the TIA finding. This isn't proof, but it's strong corroborating evidence.</p><p>The compensation event quotation includes:</p><ul><li>Additional Defined Cost: £185,000 (revised fabrication, additional cranage, prelims for 3.5 weeks)</li><li>Time: 3.5 weeks extension to the Completion Date</li><li>Assessment basis: clause 63.1, assessed prospectively from the dividing date</li></ul></div><p>TIA gave the commercial team a defensible number for the time claim. The SPI data told the same story from a different angle.</p><h2 id="tia-vs-other-delay-methods">TIA vs Other Delay Methods</h2><div class="ge-table-wrap ge-anim"><table class="ge-table"><thead><tr><th>Method</th><th>Approach</th><th>Best For</th></tr></thead><tbody><tr><td><strong>Time Impact Analysis</strong></td><td>Insert delay into programme, measure CP extension</td><td>Prospective analysis, NEC4 CEs</td></tr><tr><td><strong>As-Planned vs As-Built</strong></td><td>Compare original and actual programmes</td><td>Simple disputes, low complexity</td></tr><tr><td><strong>Collapsed As-Built</strong></td><td>Remove delay from as-built, see what completion would have been</td><td>Retrospective analysis</td></tr><tr><td><strong>Windows Analysis</strong></td><td>Analyse delay in time periods (windows)</td><td>Complex, multi-delay disputes</td></tr></tbody></table></div><p>TIA is the most natural fit for NEC4 because the contract requires prospective assessment. You're asking "what will this event do to the programme?" not "what did it do?" The other methods have their place, but for live CE assessment, TIA is the tool.</p><h2 id="common-mistakes">Common Mistakes</h2><ol><li><strong>No baseline programme.</strong> TIA requires a properly logic-linked programme. If you don't have one, you can't do TIA. On NEC4, push for an Accepted Programme early. Without it, you're guessing at delay impact and the PM can challenge every assessment.</li><li><strong>Ignoring concurrent delay.</strong> TIA measures the impact of one event in isolation. If two delays happen simultaneously and both affect the critical path, you need to model them separately and assess concurrency. Inserting both at once and splitting the result 50/50 is methodologically wrong.</li><li><strong>Using a corrupted baseline.</strong> If the programme hasn't been properly updated before the delay event, the critical path might be wrong. TIA based on a wrong critical path produces a wrong answer that looks very precise. That's dangerous.</li><li><strong>Forgetting float.</strong> If the affected activity had 2 weeks of total float, a 3.5-week delay only causes 1.5 weeks of critical delay. TIA handles this automatically if the programme logic is correct, but check the float report before and after to confirm.</li></ol><div class="ge-product-note ge-anim"><p><strong>How Gather helps.</strong> Gather's AI reads your site diaries daily and maps progress against your cost-loaded programme, giving you accurate earned value data without manual spreadsheet updates. <a href="https://gatherinsights.com/contact">Book a demo</a> to see it working on a live NEC4 project.</p></div><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3>Is TIA accepted in adjudication and arbitration?</h3><p>Yes. TIA is one of the methods recognised by the SCL Protocol and routinely accepted in UK adjudications and arbitrations. However, the quality of the analysis matters enormously. A well-executed TIA on a properly maintained programme carries significant weight. A TIA on a programme that was last updated six months ago will be challenged.</p><h3>How does TIA relate to earned value?</h3><p>TIA tells you the delay impact of a specific event. <a href="/en/earned-value/definitions/schedule-performance-index">SPI</a> and <a href="/en/earned-value/definitions/time-estimate-at-completion">TEAC</a> tell you the overall schedule efficiency and forecast completion. They're complementary. TIA is event-specific; EVM is project-wide. When SPI drops and a TIA supports a delay event of the same magnitude, you've got two independent data sources telling the same story.</p><h3>Can TIA show that a delay wasn't critical?</h3><p>Absolutely. That's one of its strengths. If you insert a 4-week delay into a non-critical activity with 6 weeks of float, TIA shows zero impact on completion. The delay was real but not critical. This distinction matters because on NEC4, the Completion Date only moves if the delay is on the critical path.</p><h3>How long does a proper TIA take to prepare?</h3><p>For a single delay event on a well-maintained programme, a competent planner can produce a TIA in one to two days. For complex events affecting multiple activities, or where the programme needs cleaning up first, allow a week. The programme quality is the bottleneck, not the analysis itself.</p></article></div>