What a time impact analysis is
A time impact analysis (TIA) forecasts the effect of a single delay event on project completion. It is the method most often requested for extension of time (EOT) applications while the project is still running, because it uses the programme the parties were working to when the event happened.
In the AACE taxonomy it is a modelled, additive method on the contemporaneous update (MIP 3.6; MIP 3.7 when repeated across updates). The SCL Delay and Disruption Protocol describes the same idea for prospective assessments.
The procedure, step by step
- Select the update. Use the last update statused before the event — not a later one that already contains its effects.
- Preserve it. The analysis runs on a copy; the update is never changed.
- Model the fragnet. Use the fewest activities and ties that represent the event: hold an activity that has not started, extend or suspend one in progress.
- Insert after the data date. Tie the fragnet into the affected logic. Nothing is placed in the past of the update.
- Recalculate. One CPM run on the project calendar.
- Measure. Impact = impacted completion − unimpacted completion, in working days, with the critical path before and after.
Worked example
Illustrative values only; not a claim assessment.
An update with data date D55 forecasts completion on D107. On D53 the employer instructs a revised paving pattern, holding precast paving — not yet started — until D74. A fragnet holds paving from D69 to D74 on a copy of the D55 update. CPM moves completion from D107 to D112: an impact of five working days.
| Run | Programme | Completion |
|---|---|---|
| Unimpacted | Copy of the D55 update | D107 |
| Impacted | Copy + fragnet FR-01 (hold on paving) | D112 |
| Time impact | +5 working days | |
The contractor's own slippage up to D107 is not part of this impact; it is measured separately, for example by windows analysis.
Limitations to state in the report
- A TIA is a forecast of the event's effect, not a record of what happened.
- The result depends on how faithfully the fragnet represents the event.
- Used retrospectively, it ignores what followed the update — a hindsight limitation to declare.
- Concurrent delays and mitigation must be assessed alongside the result.
Prospective TIA vs retrospective use
A TIA is designed to be prospective: performed when the event occurs or is notified, so the parties can agree an extension of time while there is still time to act. Used after the fact, the same procedure still works, but it ignores everything that happened after the update it was run on. That is a hindsight limitation the report should state openly.
For delays that have already happened and are visible in the updates, a contemporaneous method such as windows analysis measures what actually occurred. Many submissions use both: windows analysis for the periods already passed, TIA for the new event.
Modelling the fragnet well
The fragnet is where most TIAs are won or lost. Keep it small and evidenced:
- Fewest activities that represent the event — a notice, a decision, a revised design, a hold.
- Durations from records: letters, RFIs, instructions, site diaries — each duration traceable.
- Ties to the work the event actually hits: a hold before a not-started activity; an extension or a suspension of the remaining work of an activity in progress.
- Nothing behind the data date: the fragnet starts at or after the data date of the update used.
| Activity status at the data date | Fragnet tie | Effect |
|---|---|---|
| Not started | Hold — fragnet FS to the activity | The start waits for the event |
| In progress | Extend | Remaining duration grows |
| In progress | Suspend (split) | Remaining work stops, then resumes after the event |
Calendars and float: why the impact is not simply the event length
A five-day event does not always cost five days. If the affected activity has float, part or all of the event is absorbed. If the work is on a six-day calendar and the event spans a holiday, calendar days and working days differ. Nexora measures the impact as impacted minus unimpacted completion, in working days on the project's own calendar — so float, calendars and parallel paths are taken into account rather than assumed away.
What goes into the TIA report
- The schedule basis: which update, its data date and its acceptance status
- The event facts and the records behind each fragnet activity and tie
- Before and after Gantt charts and critical paths
- Unimpacted and impacted completion, milestone movement and float movement
- Concurrency, mitigation and the limitations of the method
The report is generated as an editable document so the planner can review and finish it before submission.
Common questions
Why must the fragnet go after the data date?
Because the update represents what was known at the time: everything left of the data date is history. An event is modelled from the data date forward in the last update before it.
Should the event be on an activity that has started?
Place it on the work it actually hits. A not-started activity is held; an in-progress one is extended or suspended for its remaining work.
Does a TIA prove entitlement to an EOT?
No. It is a technical schedule measurement. Entitlement depends on the contract, notices, responsibility and concurrency.
Can I run a TIA on my P6 programme?
Yes. Import the update as an XER, model the fragnet and run the analysis on a copy.
Try it on your own programme
Bring a representative work package — a BOQ extract or an XER — and review every assumption with your team.