top of page

A Modern Approach to Time Impact Analysis in Airport and Infrastructure Construction

2 days ago
7 min read

Updated: 2 days ago

Using schedule analysis as a near real time decision tool for changes, operational constraints, recovery planning, and fair contract administration


UM Planners | Project Scheduling and Controls | September 2026

The modern view of TIA


Time Impact Analysis, or TIA, is often treated as a document prepared after a delay has already disrupted the work. That approach misses its greatest value. A well-run TIA is a prospective management process used close to the time of an event to understand its likely effect on the current critical path, evaluate options, and support a timely contract decision.

This distinction matters on airports and large infrastructure programs. Construction must often continue around active operations, restricted work windows, security requirements, passenger movements, utility interfaces, multiple contractors, and phased turnover milestones. A delayed decision can be as damaging as the original event because crews, access windows, procurement dates, and operational plans may continue to change while the parties debate responsibility.

AACE International describes prospective TIA as a forward-looking technique that inserts a modeled event into an unimpacted CPM schedule to estimate the effect on the longest path and project completion. AACE also emphasizes that the usefulness of a prospective TIA decreases as the time between the event and its resolution grows. [1] The modern goal, therefore, is not to produce the largest possible analysis. It is to produce a transparent, timely, and technically sound decision record.


Why airport and infrastructure projects require a broader lens


On a conventional building project, a delay may be evaluated primarily against the contractual completion milestone. At an operating airport or on a major infrastructure program, the same event can affect several layers of time at once: a runway or taxiway closure, a terminal opening, a utility cutover, a maintenance-of-traffic stage, an environmental window, a permit commitment, or the handoff between separate contracts.



Project condition

What the TIA must test

Why it matters

Operational windows

Calendars, access periods, possessions, shutdowns, and reopening requirements

A few hours of lost access can move work into the next available window.

Multiple contracts

Interfaces among designers, contractors, utilities, authorities, and operators

An event outside one contract may become the driving constraint for another.

Phased turnover

Intermediate milestones and beneficial-use dates, not only final completion

The operational consequence may occur before the contractual finish date.

Security and approvals

Badging, escorts, inspections, permits, testing, and commissioning logic

Administrative and operational prerequisites can control field production.

Public accountability

Clear assumptions, contemporaneous records, and reproducible calculations

Owners must support decisions that can withstand audit, negotiation, or dispute review.


Seven principles for a modern TIA


1 Start with the contract and the decision date


The contract governs notice, schedule update requirements, permitted methodology, review periods, ownership of float, and entitlement. Before modeling anything, the team should identify the event date, the schedule data date, the contractual milestones at risk, and the decision that the TIA is expected to support. The analysis should not silently substitute a preferred industry method for the method required by the contract.


2 Use the most appropriate accepted schedule


A prospective TIA normally begins with the accepted update that best represents project status immediately before the impact. That schedule must be more than a file with an approved label. It should contain reliable status, complete logic, realistic calendars, attainable durations, and a valid path to the affected milestone. USACE guidance stresses that CPM schedules must be carefully reviewed, updated regularly, and maintained to reflect actual progress and changes.


3 Validate the model before measuring the event


A TIA cannot be stronger than the schedule into which the event is inserted. Before impact modeling, the scheduler should test open ends, constraints, lags, calendars, out-of-sequence progress, actual dates, retained logic, remaining durations, and the continuity of the driving path. The GAO Schedule Assessment Guide states that a valid critical path depends on complete activities, proper sequencing, reasonable float, and accurate status updates, and that the critical and longest paths should be reevaluated after each update.


4 Model the event with a transparent fragnet


The fragnet should represent the added or changed work at the level needed to explain the event without creating unnecessary complexity. Each activity should have a clear scope, duration basis, calendar, predecessor, successor, and connection to the existing schedule. Assumptions should be stated separately. Logic ties should reflect how the work will actually be executed, not simply force a desired completion date.


5 Test more than one path


Large programs rarely have only one meaningful risk path. The analysis should examine the current longest path, near-critical paths, milestone-specific paths, and interface paths. On an airport program, a path with several days of float may still be operationally critical if it controls a scheduled closure, airline move, commissioning sequence, or seasonal work window. A static zero-float filter is not enough.


6 Separate the time calculation from cost and entitlement


AACE recommends quantifying the time effect before determining related cost consequences. [1] This separation makes the schedule analysis easier to review. It also prevents cost arguments from influencing the technical calculation of time. The TIA can identify the modeled effect on milestones; the contract and contemporaneous facts then inform excusability, compensability, concurrency, and financial entitlement.


7 Use the TIA to evaluate choices


The best modern TIAs do not stop at a single impact number. They test practical alternatives: resequencing, additional shifts, alternate access, revised procurement, partial turnover, temporary facilities, or a different shutdown plan. AACE recognizes the use of TIA as a what-if analysis for evaluating means and methods. [1] For owners and contractors, this turns the TIA into a decision tool that can reduce the eventual delay rather than merely document it.


A practical modern TIA workflow



  1. Define the event. Record notice, cause, affected scope, event dates, responsible decision-makers, and relevant contract provisions.

  2. Freeze the source data. Preserve the native schedule, PDF reports, calendars, coding dictionaries, narratives, and supporting records used for the analysis.

  3. Select the unimpacted update. Identify the accepted schedule closest to and immediately before the event, subject to the contract and known status.

  4. Run a schedule health review. Confirm status accuracy, logic, constraints, calendars, float behavior, critical and longest paths, and milestone traceability.

  5. Build and document the fragnet. Develop the event logic with input from the people responsible for design, procurement, field execution, operations, testing, and approvals.

  6. Calculate and compare. Record the before-and-after completion dates, milestone movement, path changes, float consumption, and effects on near-critical or interface paths.

  7. Test mitigation scenarios. Evaluate realistic alternatives and identify the operational, resource, cost, safety, or approval conditions required for each option.

  8. Decide and maintain the record. Approve, reject, or revise the analysis within the contractual review period, then incorporate the agreed change into the next controlled schedule update.


Digital tools improve TIA only when governance improves with them


Modern scheduling platforms, cloud collaboration, dashboards, field-progress systems, document management, and data analytics can shorten the time needed to prepare and review a TIA. They can also create more versions, more disconnected datasets, and more opportunities for undocumented changes.

A sound digital workflow should preserve native files, maintain a version register, document schedule changes, compare current and prior paths, and connect each modeled assumption to supporting evidence. Automated schedule-quality checks can help identify constraints, missing logic, or unusual float, but they do not replace professional judgment. The project team must still determine whether the logic, calendars, durations, and operational assumptions make sense.

The GAO guide treats an integrated, reliable schedule as a model of time and a fundamental management tool. It also calls for configuration control and continuous monitoring against the baseline. [3] Applied to TIA, this means the analysis should be reproducible: another qualified reviewer should be able to identify the source update, see the inserted fragnet, understand every logic change, and reproduce the calculated result.


When a prospective TIA is no longer the right method


A prospective TIA has a practical shelf life. If the event has already occurred, the work has substantially progressed, or later delays and mitigation have changed the project path, a forward-looking model may no longer provide the most reliable answer. AACE distinguishes prospective TIA from retrospective forensic schedule analysis and notes that long delays in preparing or approving a TIA reduce its usefulness. [1] AACE Recommended Practice 29R-03 addresses retrospective forensic methods. [4]

This does not mean that every late TIA should automatically be rejected. It means the analyst should be explicit about the temporal perspective and choose a method that matches the available facts, contract language, and purpose of the analysis. Mixing prospective assumptions with later actual knowledge without disclosure creates hindsight bias and weakens credibility.


Common warning signs


The TIA is submitted months after the event with no explanation for the delay.

The source schedule is not identified, preserved, or aligned with the event date.

The fragnet contains hidden constraints, unjustified lags, or logic changes outside the event.

The analysis reports only total float and does not trace the longest or driving path.

Operational calendars, shutdown windows, permits, testing, or stakeholder interfaces are omitted.

Actual progress is overwritten or adjusted to improve the modeled result.

Time, cost, responsibility, and entitlement are blended into one unsupported conclusion.

The report provides a delay number but no mitigation or decision alternatives.


The management value of getting TIA right


A technically sound TIA gives both owners and contractors a clearer basis for action. It supports timely change decisions, protects the integrity of the schedule, improves forecasting, and reduces the likelihood that unresolved events will accumulate into a larger dispute. For airport and infrastructure programs, it also helps the team protect operational commitments while deciding how changed work should be incorporated.

The modern vision is straightforward: analyze the event while the information is current, use a schedule that can withstand technical review, make assumptions visible, test operationally realistic alternatives, and record the decision. When the TIA process is built into routine project controls, it becomes part of managing the work, not just explaining what went wrong.


How UM Planners supports project teams


UM Planners provides CPM schedule development and review, schedule health assessments, monthly updates, Time Impact Analysis, delay analysis, recovery planning, risk analysis, and executive reporting for airport and public-infrastructure programs. Our role is to help project teams develop clear, defensible schedule information that supports timely decisions and effective contract administration.

Comments


bottom of page