In infrastructure and construction projects, schedule slippage is the rule rather than the exception. Bad weather, delayed access, design changes, supply chain pressure or underestimated interfaces: all are factors that, once they build up, stretch out programmes and feed claims. One question therefore arises: how do you make the analysis of these delays objective in order to build, defend or challenge a claim convincingly? Among the recognised approaches, we can cite: Impacted As-Planned, As-Planned vs As-Built, Time-Slice Windows, Collapsed As-Built and Time Impact Analysis (TIA). This method measures, in a structured way, the effect of specific events on the critical path and on the completion date.
Before presenting TIA, let us set the scene. First, delays almost always have multiple causes. Second, whether a claim is acceptable depends less on its length than on the consistency between the facts, the programme and the contractual rules. In other words, delay analysis serves to clarify uncertainty and inform the decision, whether that means granting additional time, redeploying resources or adjusting a mitigation strategy.
Multiple sources of delay
In practice, delays often arise where the project is most vulnerable: incomplete initial planning, over-optimistic geotechnical assumptions, late delivery of design studies, disrupted site access, material shortages, occasional underperformance by subcontractors or late decisions by the client. However, understanding the origin of a delay is not enough. Each triggering fact must be dated, documented and linked to its effect on the activity network. Consequently, a credible baseline programme, periodic updates and a contemporaneous body of evidence (progress reports, site instructions, site reports) form the foundation of any robust analysis.
The aim, then, is not to draw up an inventory of grievances, but to demonstrate a causal link: this event, occurring on this date, altered this sequence, which shifted the critical path and, ultimately, the completion date. From there, TIA comes into its own.
What is TIA?
Time Impact Analysis is a cause-and-effect method that consists in inserting the event causing the delay into the appropriate version of the programme (the approved baseline or, better still, the last update accepted before the event occurred), then recalculating the network to measure the drift on the critical path. In practice, the contingency is modelled by means of a short sequence dedicated to the event (a fragnet), which sets out the activities and logic links representing the work added, blocked or re-sequenced by that event.
Two modes coexist. Prospectively, TIA anticipates the effect of an ongoing or forthcoming event, in order to support a notification and steer mitigation. Retrospectively, it reconstructs the actual impact from progress data and the updates that have been retained, which proves valuable in a formal claim or a dispute. In both cases, the method demands discipline and transparency: assumptions are made explicit, the audit trail is preserved, and there is no “manufacturing”, after the fact, of a sequence that never existed.
When should you use TIA?
As soon as a significant contingency occurs (administrative closure of an area, design change, prolonged weather stoppage, critical shortage, strike affecting an interface), TIA is a relevant choice. Upstream, it assesses the potential impact, helps size the mitigation measures and frames communication with client-side project ownership. Downstream, it makes the extension of time request objective by quantifying the lengthening of the critical path. Moreover, during a substantial revision of the programme, TIA makes it possible to test “what-if” scenarios and to arbitrate between acceleration, re-sequencing and acceptance of residual slippage.
The prerequisites that make the difference
To be probative, a TIA rests on four pillars:
- First, a structured baseline version of the programme (explicit logic links, calendars, controlled constraints).
- Next, dated updates that faithfully reflect progress (actual dates, remaining durations, justified re-sequencing).
- Third, a solid factual file (site instructions, correspondence, minutes, photographs, weather records, weekly reports, etc.). Finally, a contractual understanding of how delay is treated: notification periods and forms, the mitigation requirement, ownership of float (shared or not) and the rules applicable to concurrent delays.
Without these elements, the analysis loses credibility and evidential weight.
How do you implement TIA, step by step?
- First of all, you need to start by selecting the right version of the programme: the last update accepted before the event. This choice avoids introducing later information that would bias the analysis.
- Next, particular care must go into describing the event in detail: date of occurrence, cause, area affected, work packages concerned, durations observed or estimated, specific constraints.
- On that basis, the fragnet can be built: new or modified activities and links to the existing tasks, as they stood at the data date.
- This fragnet must then be inserted into a copy of the unimpacted programme, which will allow the sequence to be recalculated.
- Now comes the time to compare the completion date “before/after” and to observe the changes to the critical path. The net impact (in days) can be quantified and the causal chain documented.
- It is then important to test mitigation scenarios (partial overlap, re-sequencing, additional resources, extended working windows) in order to measure the possible gain and the associated costs.
- Finally, to close the exercise, a clear report must be written: context, source data, assumptions, results, sensitivity, a visual extract of the critical path and recommendations, in order to make decision-making easier.
Advantages, limitations… and remedies
TIA’s major strength lies in its traceability. Every event has a model, visible assumptions and a measure of its effect. What is more, the method is widely recognised for supporting EOTs (extension of time), which makes contractual dialogue easier. It also informs management trade-offs: should we accelerate, re-sequence or accept residual slippage?
That said, certain limitations call for vigilance. TIA depends on the quality of the programme; if the logic is weak or unstable, the conclusions become fragile. Prospectively, it can look hypothetical; the assumptions must then be anchored in contemporaneous data, the sensitivity must be tested and the analysis updated as things progress.
Finally, handling concurrent delays and allocating float require an explicit contractual framework. In response, establishing update routines, co-building the fragnets with the package leads and keeping a rigorous audit trail are effective remedies.
Results-driven collaboration between the CM and the project manager
Properly run, TIA brings contract management and project management closer together. The former brings evidential discipline and a critical eye, in particular through the prism of its knowledge of the project. The project manager, for their part, guarantees the technical accuracy of the fragnet and the feasibility of the scenarios. Together, they analyse the tools in place or put tools in place in order to gather as much information as possible (event register, notification register, etc.), align the method with the contract, then translate the results into action plans: redeploying teams, fine sequencing of interfaces, extended working windows, or a well-argued EOT request.
TIA should be seen as a tool that feeds proactive management rather than reactive crisis handling.
Conclusion
Time Impact Analysis is not a black box reserved for disputes; it is first and foremost a management tool that turns uncertainty into actionable decisions. By inserting precisely described events into a reliable baseline programme, then recalculating the sequences to measure the effect on the critical path, TIA makes exchanges objective, secures well-founded EOTs and directs mitigation efforts to where they produce the most value. Better still, by bringing contract managers and project managers together around a common language (facts, logic, time), it fosters proactive management and continuous adaptation of the strategy on the ground.
Ultimately, building TIA into the schedule management routine means choosing to prevent rather than endure: you explain the causes, you measure the effects, you decide quickly and you maintain, as far as possible, the project’s trajectory despite the contingencies.