Time Impact Analysis (TIA): The Complete Step-by-Step Guide for Construction Delay Claims

You’ve just received a contractor’s extension of time (EOT) claim. The submission includes a revised programme showing a six-week delay to completion, a cover letter referencing a design change instruction, and a spreadsheet of impacted activities. The contractor says the delay is unavoidable. You need to know: is it real, or is the programme telling them what they want to hear?

That question is what Time Impact Analysis (TIA) was designed to answer. TIA is the most widely recommended method for assessing delay claims on construction projects, and for good reason. It isolates the impact of a specific delay event, inserts it into the programme as it stood before the event occurred, and measures the result. Done properly, it’s transparent, repeatable, and defensible. Done poorly, it’s a tool for manufacturing delay.

This guide covers how TIA works, when to use it (and when not to), how to perform it step by step including in Oracle Primavera P6, and how to evaluate a TIA submission when you’re on the receiving end.

Why TIA Matters

Ninety-one point five per cent of major projects in Flyvbjerg’s database of 16,000 projects across 136 countries are delivered over budget, over schedule, or both (Flyvbjerg and Gardner, How Big Things Get Done). The California High-Speed Rail project was approved in 2008 with a $33B budget and a 2020 completion target. By 2024, the estimate exceeded $100B, and the state was building a 171-mile segment that may never connect to its originally intended cities. When delays of that magnitude occur, the question of who bears responsibility, and for how long, becomes a commercial dispute worth millions. The method you use to analyse the delay determines the answer.

TIA matters because it’s the method the Society of Construction Law’s Delay and Disruption Protocol, 2nd Edition (SCL Protocol) recommends for contemporaneous assessment of EOT applications. Paragraph 11.4(a) states that “the time impact analysis method is recommended for a contemporaneous analysis of delay.” That recommendation carries weight in dispute resolution forums internationally.

But TIA’s reliability depends entirely on two things: the quality of the base programme, and the rigour of the fragnet construction. A TIA built on a programme riddled with hard constraints and missing logic, the kind that fails multiple DCMA 14-Point checks, will give you a precise-sounding answer that’s wrong. A TIA with a fragnet that stretches existing activity durations instead of adding new ones will inflate the delay.

What we found: TIA is the industry’s preferred method for assessing delay claims contemporaneously, endorsed by the SCL Protocol and classified under AACE International RP 29R-03 as a modelled, additive, multiple-base technique (MIP 3.7). Most contractually specified analysis methods reference TIA directly.

What it means: If you’re reviewing a contractor’s EOT claim, you need to understand TIA well enough to evaluate whether the analysis is sound, not just accept the headline result.

What Is Time Impact Analysis (TIA)?

TIA is a forward-looking delay analysis method. You take the programme as it existed before the delay event, insert a sub-network (called a “fragnet”) representing the delay, recalculate the schedule, and compare the predicted completion date before and after insertion.

The SCL Protocol, paragraph 4.12, defines TIA as requiring “a logic linked baseline programme (which ordinarily would be the Accepted Programme), updated programmes (which ordinarily would be the Updated Programmes) or progress information with which to update the baseline programme and the selection of delay events to be modelled.”

TIA answers one question: if this delay event had not occurred, when would the project have finished? The difference between the unimpacted and impacted completion dates is the quantified delay attributable to that specific event.

Prospective vs retrospective TIA

TIA was designed as a prospective method: assess the impact while the project is still underway, forecasting what will happen. The SCL Protocol’s preference for TIA in paragraph 11.4(a) specifically relates to this contemporaneous application.

Retrospective TIA applies the same technique after the project is complete. This is controversial: using hindsight to build fragnets based on what actually happened, then inserting them into a historical programme to model an impact you already know. The contemporaneous, prospective application is the one the SCL Protocol recommends in §11.4(a); when TIA drifts into retrospective territory, the burden of proof shifts.

When to Use TIA (and When Not To)

TIA is most appropriate when four conditions are met: you have a reliable, logic-linked programme; the project is still underway; the delay event is discrete and identifiable; and you need to assess the impact before the full consequences are known.

The SCL Protocol, paragraph 4.7, recommends that “the most recent Updated Programme (or, if there is none, the Accepted Programme) should be the primary tool used to guide the CA in assessing an EOT application.” This means the programme needs to exist, be current, and be of sufficient quality to support analysis. If you’re running a DCMA 14-Point Assessment and the programme fails five of the 14 checks (per the Defence Contract Management Agency), that programme isn’t a reliable base for TIA.

TIA is appropriate when

• You have an accepted, logic-linked programme with current progress data
• The delay event is discrete (a variation instruction, a design change, a site access delay)
• You need to quantify the impact before the full consequences are known
• The programme has been validated through a baseline schedule review or quality assessment

TIA is less appropriate when

• No reliable, logic-linked programme exists
• The project is complete (consider as-built but-for analysis instead)
• Multiple overlapping delays over extended periods (consider windows analysis)
• The programme is heavily constrained or manipulated

Comparison: TIA vs other delay analysis methods

The SCL Protocol’s paragraph 11.5 method comparison table provides a structured way to evaluate which method fits your situation:

Source: SCL Protocol 2nd Edition, paragraph 11.5

The key differentiator for TIA: the critical path is determined contemporaneously (using the schedule as it was at the time), but the delay impact is determined prospectively (forecasting forward from the point of the delay event). This makes TIA particularly suitable for assessing individual delay events during the project, as described in our guide to a complete construction schedule analysis.

The 5-Step Time Impact Analysis Process

Step 1: Select the base schedule

The base schedule is the programme into which the fragnet will be inserted. Get this wrong, and the entire analysis fails.

The SCL Protocol, paragraph 4.8(a), specifies that the programme should be “brought fully up to date (as to progress and the effect of all delays that have occurred up to that date, whether Employer Delays or Contractor Delays) to the point immediately before the occurrence of the Employer Risk Event.”

In practice, you have three options:

Before using any programme as a TIA base, validate it. Run a quality check using the DCMA 14-Point Assessment criteria. Check for missing logic (should be below 5% of activities), negative float (PAM 200.1 §4.7’s canonical target is zero), and excessive constraints. If the programme fails these basic checks, the TIA result will be unreliable, and you should flag this in your report.

Step 2: Build the fragnet

A fragnet (fragmentary network) is a small network of activities representing the delay event and its consequences. The SCL Protocol, paragraph 4.10, requires that “the sub-network should be prepared by the Contractor in the same manner and using the same software as the Accepted Programme. It should comprise the activities and durations resulting from the Employer Risk Event.”

There are three main types of fragnets:

Fragnet construction best practices:

1. Keep fragnets simple and logic-driven. Each activity should represent a distinct, identifiable piece of work.
2. Use realistic durations based on the specific circumstances, not worst-case assumptions.
3. Tie fragnet activities to existing programme activities with appropriate logic (Finish-to-Start, Start-to-Start, etc.).
4. Avoid hard constraints within fragnets. The fragnet’s impact should be driven by logic and durations, not fixed dates.
5. Document every assumption: why each duration was chosen, why each logic tie was made, and what contemporaneous records support them.

Common fragnet mistakes:

• Stretching existing activity durations instead of adding new activities. This is the most common error. If the delay event adds work, add new activities. If it slows progress, explain why the rate changed with evidence.
• Overly complex fragnets with dozens of activities that obscure more than they clarify.
• Missing logic ties between fragnet activities and the existing programme.
• Using constraints instead of logic to force the fragnet to produce a specific result.

Step 3: Insert the fragnet into the schedule

This is the mechanical step: place the fragnet into the base schedule, set the data date, link the fragnet to existing activities, and recalculate.

The data date matters critically. The SCL Protocol’s approach, set out in paragraph 4.8, requires inserting the fragnet at the point in the programme that existed immediately before the delay event occurred. If you set the data date too early or too late, you distort the remaining float, the critical path, and the resulting delay calculation.

After inserting the fragnet and linking it to the existing logic, schedule the project (press F9 in P6). The software will recalculate all early and late dates, float values, and the critical path.

Step 4: Compare impacted vs unimpacted schedules

The core output of TIA is the comparison between the unimpacted completion date (the programme without the fragnet) and the impacted completion date (the programme with the fragnet inserted).

Three things to check:

1. Did the critical path shift? The delay event might push a non-critical path onto the critical path, creating delay that wasn’t apparent before.
2. How much float was consumed? Even if the delay doesn’t extend the completion date, it may consume float that protects other activities. A delay that reduces total float from 25 days to 3 days on a near-critical path changes the project’s risk profile.
3. Is the delay to completion, or just to intermediate milestones? An EOT is granted for delay to the contract completion date, not for delays to individual activities (unless the contract says otherwise).

Step 5: Document and report the TIA

Both the SCL Protocol and AACE RP 29R-03 have specific requirements for TIA documentation. AACE MIP 3.7 requires implementation of Source Validation Protocols 2.1 (baseline validation), 2.3 (update validation), and 2.4 (delay identification and quantification) at minimum.

A proper TIA report should include:

How to Perform TIA in Primavera P6

Most schedule analyses in construction use Oracle Primavera P6. Here is a practical walkthrough:

1. Open and validate the base schedule. Run a schedule log; check for missing predecessors/successors, excessive constraints, and out-of-sequence progress.
2. Create a copy for the impacted analysis. Never modify the original programme. Copy the project and rename it clearly (for example, “Project Name - TIA Event 1 - Impacted”).
3. Set the data date to immediately before the delay event occurred (Project Details, Data Date field).
4. Create fragnet activities with an activity ID prefix (such as “TIA-”) to tag them for filtering.
5. Link fragnet activities to existing schedule logic using the Predecessors and Successors tab. Use the same relationship types (FS, SS, FF, SF) as the existing programme logic. Avoid constraints.
6. Schedule the project (F9). P6 will compute new early/late dates, float, and critical path.
7. Compare completion dates side by side. The difference between the unimpacted and impacted early finish dates is the quantified delay.
8. Document and export results. Use activity notebooks to record assumptions; export as PDF; save both .xer files.

Keep the original schedule unmodified. If performing multiple TIA analyses for different events, use separate copies for each.

Common TIA Mistakes and How to Avoid Them

A small set of errors recur in TIA submissions. These are not theoretical risks; they are recurring features that the SCL Protocol’s programme expectations and the DCMA 14-Point’s structural checks consistently surface.

The Retrospective TIA Debate

The most contentious issue in TIA practice is whether the method should be applied retrospectively. A 2010 article in IBA Construction Law International titled “Junk science: the fallacy of retrospective time impact analysis” argued that applying TIA after project completion is fundamentally flawed because the analyst already knows the outcome and can (consciously or not) build the fragnet to produce the desired result.

Boston’s Big Dig illustrates the problem: against a 1998 completion plan it finished nine years late, its budget running from $2.8B to $14.6B at completion (more than $22B once interest on borrowed funds is counted, per the Massachusetts Inspector General), with hundreds of overlapping delay events. A retrospective TIA on that project would require reconstructing programme conditions from years of fragmented records, then claiming the result represents what would have happened at the time. The potential for confirmation bias is obvious.

The criticism has three pillars:

1. Hindsight bias. When you know the actual outcome, you’re more likely to build fragnets that confirm what happened rather than model what could have happened.
2. Data date manipulation. In retrospective TIA, the analyst chooses which data date to use for each fragnet insertion. Different data dates produce different results, and the analyst can select the one most favourable to their client.
3. Cherry-picking base schedules. If multiple programme updates exist, the analyst can choose the one that produces the largest delay, rather than the one that best represents the project conditions at the time of the event.

The SCL Protocol addresses this indirectly. Paragraph 11.1 notes that “where an EOT application is assessed after completion of the works, or considerably after the occurrence of the delay event or its impact,” the prospective analysis method may no longer be appropriate. In those cases, the Protocol recommends effect-and-cause methods that consider all potential causes of delay.

This doesn’t mean retrospective TIA is never admissible. AACE RP 29R-03 classifies it as MIP 3.7 regardless of timing, and the method’s mathematical structure doesn’t change. But retrospective TIA carries a heavier evidentiary burden. The analyst must:

• Demonstrate that fragnet durations and logic are based on information available at the time of the event, not hindsight
• Use contemporaneous records (site diaries, daily logs, progress photos, correspondence) to justify every assumption
• Explain why a forward-looking method was applied to a backward-looking question
• Disclose alternative analyses that produce different results

If you’re reviewing a retrospective TIA, apply heightened scrutiny. Check whether the fragnet durations match what was known at the time versus what was learned later. Cross-reference the claimed delays against the contemporaneous progress data. And ask the question the SCL Protocol implies: if the analysis was done at the time, would the same result have been produced?

How to Review a TIA Submission

Most guides explain how to prepare a TIA. Few explain how to evaluate one. If you’re a client-side PM, an employer’s representative, or a contractor reviewing a subcontractor’s EOT claim analysis, you’re on the receiving end of someone else’s analysis. Here’s what to check.

TIA review checklist

Red flags in TIA submissions

Watch for these specific indicators that a TIA may be manipulated:

• The result equals the claim exactly. A genuine TIA rarely produces a round number. If the contractor claims 42 days and the analysis produces exactly 42 days, it may have been reverse-engineered.
• The base schedule was rejected or unapproved. A programme never accepted by the CA undermines the analysis.
• The fragnet uses stretched durations. Instead of adding verifiable new activities, the analyst inflates existing durations that can’t be separated from the original estimate.
• There’s no discussion of concurrent delay. An analysis that attributes all delay to a single employer risk event, ignoring simultaneous contractor delays, is incomplete.

TIA and EOT Claims

TIA doesn’t grant an extension of time. It quantifies delay. The EOT itself is a contractual entitlement, assessed by the contract administrator (CA) against the contract provisions. TIA provides the evidence to support or challenge that assessment.

The SCL Protocol, paragraph 4.7, states that the EOT “should be granted to the extent that the Employer Risk Event is predicted to prevent the works being completed by the then prevailing contract completion date.” TIA models that prediction. It shows whether the event extends the critical path, and by how much.

Three things to remember when connecting TIA results to EOT claims:

1. Contract notice requirements come first. Even a perfectly executed TIA won’t support an EOT if the contractor didn’t give notice within the contractually required timeframe. Check the contract conditions (typically clauses on delay notices and EOT procedures) before evaluating the analysis.

2. TIA quantifies the critical path impact, not the total disruption. A delay event may cause disruption to multiple activities but only delay the project if it affects the critical path. TIA measures the critical path impact; disruption costs require separate analysis.

3. The CA’s assessment is a contract administration decision, not a scheduling exercise. The CA considers the TIA result alongside contemporaneous records, contract provisions, and practical judgement. The SCL Protocol, paragraph 4.14, reminds us that the Updated Programme should be used “in conjunction with the contemporary evidence, to ensure that any resulting EOT is both reasonable and consistent with the factual circumstances.”

For a full walkthrough of the EOT claim process, see our guide to extension of time claim processes.

Key Takeaways

• TIA is the SCL Protocol’s recommended method for contemporaneous delay analysis. If you’re assessing an EOT claim during the project, TIA is the starting point.
• The method depends on two pillars: a reliable base programme and a rigorously constructed fragnet. If either is weak, the result is unreliable.
• Prospective TIA (assessing impact during the project) is defensible. Retrospective TIA (modelling impact after the fact) carries higher risk and requires additional justification.
• AACE RP 29R-03 classifies TIA as MIP 3.7: a modelled, additive, multiple-base method requiring baseline validation, update validation, and delay identification at minimum.
• The most common TIA mistakes are using unreliable base programmes, stretching existing durations instead of adding activities, and ignoring concurrent delay.
• When reviewing a TIA, check the base programme, data date, fragnet construction, concurrent delay analysis, and whether assumptions are supported by contemporaneous records.
• TIA quantifies delay. It doesn’t grant the EOT. Contract notice requirements, entitlement, and the CA’s assessment are separate steps.

Every TIA tells a story about what would have happened. Your job, whether preparing or reviewing, is to make sure that story is backed by evidence, not assumption.