Step by step
1. Identify the event and its date. Establish from the records exactly when the event started to affect the works, not when a notice was issued.
2. Select the update immediately before the event. This is the network that represents the parties' shared view of the programme at that moment. Verify it: no open ends, no invalid dates, no unexplained negative float, and a critical path that behaves correctly when tested.
3. Build the fragnet. Model the event as one or more activities with realistic durations and logic tying them into the affected work. A single arbitrary activity dropped onto the project finish is not a fragnet — it is an assertion.
4. Insert and recalculate. The difference between the forecast completion before and after insertion is the impact of that event.
5. Repeat sequentially for further events, carrying the impacted network forward so each event is assessed against the position that existed when it happened.
Concurrency and pacing
TIA measures one event at a time, which is exactly why concurrency has to be handled explicitly. If a second, unrelated delay was driving or near-driving completion in the same window, the entitlement conclusion cannot simply follow the TIA arithmetic.
Check near-critical paths as well as the critical path. A fragnet that consumes float on a path with three days of remaining float will start driving completion shortly afterwards, and that interaction is usually the most contested part of the analysis.
Common reasons a TIA gets rejected
Using a re-baselined programme instead of the contemporaneous update. Impacting a schedule that fails basic quality checks. Building the fragnet with hard constraints or unexplained lags. Ignoring progress that had already occurred at the data date. Presenting a single end-of-project TIA covering a dozen events at once.
The defence against all of these is documentation: state the update used, its data date, the quality checks it passed, the fragnet logic and duration basis, and the resulting completion movement — for each event, separately.
Running a TIA in TideLine
Load the contemporaneous .xer update and run the Quality module first, against DCMA 14-Point or whichever profile your project uses — GAO, AACE RP-90R-19, NDIA PASEG or USACE/NAVFAC — with your own metric weights and warn/fail limits. Impacting a network that fails its own quality checks is the fastest way to lose the analysis.
Capture that update as a snapshot. TideLine's Delay module keeps a snapshot library, sorts delay events chronologically, finds the snapshot immediately preceding each event, inserts the event as a fragnet, recalculates CPM and reports the slip that event caused — event by event, against the position that existed at the time.
Alongside TIA the same workspace runs impacted as-planned, collapsed as-built and windows analysis, so you can test one event set under more than one method and see where the answers diverge before you commit to a position.
Traceability and reporting
Every impacted event is held in the delay and EOT register with its date, impact days, cause code, affected activity, responsibility and claim type, and near-critical paths are tracked alongside the critical one so float consumption that later becomes driving is visible.
You can push the Delay workspace into the Schedule module to refine logic or model an alternative fragnet, then capture it back as a snapshot for the next event — source .xer files are never modified. The register, the before/after completion dates and the window findings flow into the report, with each causal statement cited to the activity ID or dated record behind it, which is what an expert witness needs when the analysis is tested.