{"id":73494,"date":"2026-08-31T15:07:45","date_gmt":"2026-08-31T18:07:45","guid":{"rendered":"https:\/\/a3aengenharia.com\/?post_type=articles&p=73494"},"modified":"2026-08-31T15:07:45","modified_gmt":"2026-08-31T18:07:45","slug":"delay-analysis-time-impact-analysis-engineering-projects-contracts","status":"publish","type":"articles","link":"https:\/\/a3aengenharia.com\/en-us\/content\/technical-articles\/delay-analysis-time-impact-analysis-engineering-projects-contracts\/","title":{"rendered":"Delay Analysis and Time Impact Analysis in Engineering: How to Assess Delays in Projects and Contracts"},"content":{"rendered":"\n

Delay Analysis is the technical analysis used to determine how events affected or may affect a project schedule, especially its completion date and contractual milestones. In engineering and construction, the analysis must go beyond stating that \u201cthere was a delay\u201d: it should identify the baseline, the applicable critical path, the affected sequence, the timing of the event, contractual responsibility, and the demonstrable time effect.<\/p>\n\n\n\n

Time Impact Analysis (TIA) is one of the possible delay-analysis methods. It typically evaluates, prospectively or contemporaneously, the insertion of an event or fragnet into an updated schedule to observe its influence on the critical path and contractual dates. TIA is not synonymous with all Delay Analysis, and its suitability depends on schedule quality, when the analysis is performed, and the question that needs to be answered.<\/p>\n\n\n\n

In schedule claims, robustness lies in the relationship between the schedule and reality. A sophisticated method applied to a weak baseline, incomplete logic, or updates that do not reflect field conditions may create an appearance of precision without representing what actually occurred.<\/p>\n\n\n\n

Delay, disruption, and prolongation are different effects<\/h2>\n\n\n\n

The Society of Construction Law Delay and Disruption Protocol distinguishes delay from disruption because, although both may arise from the same event, they do not represent the same effect. Delay is associated with time and completion; disruption is associated with loss of productivity or changes in work efficiency. An event may produce both, only one, or effects during different periods.<\/p>\n\n\n\n

Effect<\/td>Primary question<\/td>Main evidence<\/td><\/tr>
delay<\/td>was completion or a milestone shifted?<\/td>schedule, logic, critical path, updates<\/td><\/tr>
disruption<\/td>did the work become less productive?<\/td>production, resources, work fronts, sequence, hours<\/td><\/tr>
prolongation<\/td>did the project remain mobilized for longer?<\/td>duration-dependent costs and actual period<\/td><\/tr>
acceleration<\/td>were resources or sequence changed to recover schedule?<\/td>instructions, recovery plan, resources, and performance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

This distinction matters because a claim may request an extension of time without disruption costs, or demonstrate lost productivity without shifting the final completion date.<\/p>\n\n\n\n

The starting point is a reliable baseline<\/h2>\n\n\n\n

The baseline should represent the contractual or technically accepted plan against which the event will be analyzed. This requires coherent dates, logic, durations, calendars, milestones, constraints, and assumptions.<\/p>\n\n\n\n

The analysis should not begin with the difference between the planned date and the actual date. First, it is necessary to verify whether the reference schedule was executable, whether it contained all relevant activities, and whether its logic represented the implementation strategy.<\/p>\n\n\n\n

In contracts structured by Work Packages<\/a>, decomposition helps connect deliverables, responsibilities, and interfaces to schedule activities. The more unclear this relationship is, the more difficult it becomes to demonstrate time causation.<\/p>\n\n\n\n

The critical path is not a fixed line throughout the project<\/h2>\n\n\n\n

The critical path can migrate. An activity that was critical in the baseline may cease to control completion after changes, progress, concurrent delays, or replanning. Therefore, delay analyses need to consider the state of the project at the time of the event.<\/p>\n\n\n\n

The simple statement \u201cthe activity was on the original critical path\u201d may be insufficient months later. The analysis should examine the contemporaneous logic network, available float, and actual execution conditions.<\/p>\n\n\n\n

This explains why high-quality periodic updates are so important. They record the evolution of the plan and reduce the need to reconstruct the critical path retrospectively.<\/p>\n\n\n\n

Prospective vs. retrospective<\/h2>\n\n\n\n

The choice of method depends, among other factors, on when the analysis is performed.<\/p>\n\n\n\n

Approach<\/td>Timing<\/td>Typical use<\/td><\/tr>
prospective<\/td>before the full impact has materialized<\/td>estimate the likely effect and support a contemporaneous decision<\/td><\/tr>
contemporaneous<\/td>while the event is occurring<\/td>assess extension of time, mitigation, and change<\/td><\/tr>
retrospective<\/td>after the period or completion<\/td>reconstruct and explain the effects that actually occurred<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

A prospective approach should not be judged as though it had access to later facts. Likewise, a retrospective analysis should not ignore what actually occurred in favor of a simulation that never materialized.<\/p>\n\n\n\n

What is Time Impact Analysis<\/h2>\n\n\n\n

TIA inserts a logical representation of the event \u2014 often called a fragnet \u2014 into an updated reference schedule and calculates its influence on the network. The objective is to observe how the event changes dates, critical path, float, or milestones.<\/p>\n\n\n\n

Simplified Time Impact Analysis logic applied to a project event<\/title><\/path><\/marker><\/path><\/marker><\/circle><\/marker><\/circle><\/marker><\/path><\/marker><\/path><\/marker><\/g><\/path><\/path><\/path><\/path><\/path><\/path><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g>
<\/span><\/div><\/foreignObject><\/g><\/g><\/g><\/rect>

Update before the event<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Validate logic and status date<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Model event fragnet<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Insert into schedule<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Recalculate network<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Compare milestones and critical path<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/rect>

Assess mitigation and responsibility<\/p><\/span><\/div><\/foreignObject><\/g><\/g><\/g><\/g><\/g><\/svg>

Simplified Time Impact Analysis logic applied to a project event<\/figcaption><\/figure>\n\n\n\n

TIA quality depends on the credibility of the selected update and the modeling of the event. If the fragnet exaggerates duration, creates artificial dependencies, or ignores parallel activities, the result may overstate the impact.<\/p>\n\n\n\n

When TIA makes the most sense<\/h2>\n\n\n\n

TIA tends to be most useful while the project is still underway, when a reliable updated schedule exists and the event can be represented through verifiable activities and logical relationships.<\/p>\n\n\n\n

It is especially valuable when a decision must be made before closeout, for example to assess an extension of time, change order, late access, delayed information, design change, or an instruction that alters sequence.<\/p>\n\n\n\n

It loses strength when reliable updates do not exist, when the analysis is performed long after the event, or when schedule logic does not represent actual execution. In such cases, other retrospective methods may be more appropriate.<\/p>\n\n\n\n

TIA should not be a simulation disconnected from execution<\/h2>\n\n\n\n

A well-structured TIA needs to confront the model with contemporaneous facts: actual dates, available work fronts, constraints, resources, progress, decisions, and access conditions.<\/p>\n\n\n\n

It should also consider mitigation. If the team was able to resequence activities, open another work front, or bring part of the work forward, the final effect may be smaller than the gross impact initially projected.<\/p>\n\n\n\n

The technical analysis should document assumptions and limit conclusions to what the data can support. In projects with poor planning quality, methodological uncertainty needs to be stated in the opinion.<\/p>\n\n\n\n

\n

When a significant delay needs to support negotiation, an extension of time, or a response to a claim, the methodology should be defined based on schedule quality and evidence \u2014 not on the result one party wants to obtain.<\/p>\n\n\n\n

Structure a technical schedule analysis integrated with the contractual claim<\/a><\/p>\n<\/div>\n\n\n\n

Window analyses<\/h2>\n\n\n\n

Window Analysis divides the project into periods and examines the evolution of the critical path and delays in each window. The logic is useful for long projects in which criticality, sequence, and events change significantly over time.<\/p>\n\n\n\n

Window size may follow monthly updates, milestones, or periods with similar characteristics. Short windows increase detail but require consistent data; broad windows may conceal relevant changes.<\/p>\n\n\n\n

The analysis should explain why a particular division was selected and how events were allocated to each period.<\/p>\n\n\n\n

As-planned vs. as-built<\/h2>\n\n\n\n

Comparing the original plan with actual execution is intuitive and may provide an overall view, but by itself it does not demonstrate causation. The difference between two dates does not identify which event produced the variance or whether the delay was critical when it occurred.<\/p>\n\n\n\n

This type of comparison may support an initial diagnosis, but complex claims normally require analysis of logic and time evolution.<\/p>\n\n\n\n

Collapsed as-built and retrospective approaches<\/h2>\n\n\n\n

Retrospective methods may remove selected events from the as-built to estimate what completion would have been \u201cbut for\u201d those impacts. This logic is frequently associated with collapsed as-built analysis.<\/p>\n\n\n\n

The challenge is reconstructing a reliable logic network from actual execution. If relationships between activities are not demonstrated, removing events may create a hypothetical condition far from what would have been technically possible.<\/p>\n\n\n\n

No method should be selected merely because it produces a favorable number. The method must answer the question with the available data.<\/p>\n\n\n\n

How to choose a Delay Analysis method<\/h2>\n\n\n\n

Selection should consider baseline quality, update quality, project stage, number of events, availability of contemporaneous records, logic complexity, and the purpose of the analysis.<\/p>\n\n\n\n

The SCL Protocol recommends that methodology selection consider the nature of the project, available documentation, and proportionality. In engineering terms, this means the method should be defensible before it is convenient.<\/p>\n\n\n\n

An analysis may even combine techniques, provided that limitations are made explicit and incompatible assumptions are not mixed.<\/p>\n\n\n\n

Delay events and Claim Management<\/h2>\n\n\n\n

Delay Analysis works best when events have already been controlled during execution. Claim Management<\/a> creates the trail of notices, evidence, decisions, and records that schedule analysis will later use.<\/p>\n\n\n\n

When the project reaches completion without an event register, start and finish dates of impacts must be reconstructed from minutes, emails, site logs, and system records. This increases cost and uncertainty.<\/p>\n\n\n\n

Delay Analysis within a contractual claim<\/h2>\n\n\n\n

The contractual claim<\/a> needs to integrate the schedule conclusion with the contractual basis. Demonstrating 20 days of impact in a network does not automatically mean entitlement to a 20-day extension.<\/p>\n\n\n\n

The event must be assessed against clauses, the risk matrix, notices, responsibility, concurrent delays, mitigation, and contract-specific conditions.<\/p>\n\n\n\n

Schedule analysis identifies the technical effect. Entitlement determines how that effect is treated contractually.<\/p>\n\n\n\n

Concurrency: simultaneous delays require careful analysis<\/h2>\n\n\n\n

Concurrency should not be treated merely as the presence of two problems in the same month. The question is whether events under different responsibilities simultaneously affected the critical path or the relevant completion date.<\/p>\n\n\n\n

The definition and legal effect of concurrency vary according to the contract and applicable law. Engineering analysis should limit itself to demonstrating chronology, criticality, and technical overlap, leaving the legal consequence to the competent interpretation.<\/p>\n\n\n\n

Poorly updated schedules make this assessment difficult because they hide migration of criticality between work fronts.<\/p>\n\n\n\n

Float and responsibility for available time<\/h2>\n\n\n\n

Float represents flexibility in the network, but its contractual treatment may be controversial. An event may consume float without changing the final date; another may turn a previously noncritical activity into a critical one.<\/p>\n\n\n\n

The analysis should show the float available at the time of the event and how it evolved. It is not appropriate to assume that every consumption of float equals an extension of time.<\/p>\n\n\n\n

It is also important to check artificial constraints, excessive lags, and calendars that may distort the calculation.<\/p>\n\n\n\n

Data date, update, and actual status<\/h2>\n\n\n\n

Each update needs a clear status date and must separate completed, in-progress, and future work. Incorrect progress data changes the network and may create artificial criticality.<\/p>\n\n\n\n

Before using an update in Delay Analysis, it is worth checking actual dates, percentages, remaining duration, open relationships, out-of-sequence activities, constraints, and milestones.<\/p>\n\n\n\n

A schedule audit is not bureaucracy: it is a precondition for trusting the model.<\/p>\n\n\n\n

\n

The earlier schedule, scope, interfaces, and contractual events are governed together, the lower the need for forensic reconstruction at closeout and the greater the ability to decide while mitigation options still exist.<\/p>\n\n\n\n

Integrate schedule, scope, and evidence in Contracts, Scope, and Deliverables Management<\/a><\/p>\n<\/div>\n\n\n\n

Audit the schedule before drawing any conclusion<\/h2>\n\n\n\n

Before applying TIA, Window Analysis, or any retrospective method, the schedule must be audited as a technical model. Delay analysis assumes that relationships, dates, and progress reasonably represent execution; if this premise fails, the mathematical result may amplify source errors.<\/p>\n\n\n\n

The audit should examine open logic, activities without predecessors or successors where unjustified, hard constraints, excessive lags, inconsistent calendars, remaining durations incompatible with progress, out-of-sequence activities, and logic changes between updates. It is also necessary to verify whether contractual milestones were modeled correctly and whether the status date was applied consistently.<\/p>\n\n\n\n

Control<\/td>Risk to Delay Analysis<\/td>Verification<\/td><\/tr>
incomplete logic<\/td>creates an artificial critical path<\/td>predecessors, successors, and relationships<\/td><\/tr>
hard constraints<\/td>prevent the network from responding to the event<\/td>constraint type, date, and rationale<\/td><\/tr>
inconsistent progress<\/td>distorts remaining duration and criticality<\/td>actual dates, percentages, and field records<\/td><\/tr>
logic change<\/td>may retrospectively rewrite the plan<\/td>comparison between successive updates<\/td><\/tr>
calendars<\/td>change duration and float without an apparent change<\/td>workdays, holidays, shifts, and exceptions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

An inconsistency does not automatically make the schedule unusable. The analyst needs to assess materiality, document adjustments when necessary, and explain how each limitation affects the confidence level of the conclusion. In some cases, certain periods can be analyzed more reliably than others.<\/p>\n\n\n\n

How to build a technically defensible fragnet<\/h2>\n\n\n\n

In TIA, the fragnet represents the additional logic created by the event. Building it requires more than inserting an activity with a duration equal to the claimed period. The actual impact mechanism must be modeled: which activities were blocked, which new steps emerged, which approvals became necessary, and where the event connects to the existing network.<\/p>\n\n\n\n

The fragnet duration should be supported by contemporaneous records or by a demonstrable technical estimate. If a design revision took ten days, for example, it is necessary to distinguish preparation time, review, approval, mobilization, and the actual effect on the critical work front. Adding all these periods without checking overlap may overstate the impact.<\/p>\n\n\n\n

Logical relationships also need to be justified. Connecting the event directly to a final milestone may produce a mathematical effect without representing the execution process. The fragnet should enter the network where the consequence actually occurred, preserving parallel activities and available alternatives.<\/p>\n\n\n\n

After insertion, the comparison should show not only the difference in the final date, but also changes in the critical path, float consumption, activities that began to control the milestone, and any effects absorbed by the existing logic.<\/p>\n\n\n\n

Excusable, compensable, and non-excusable delay: separate effect from consequence<\/h2>\n\n\n\n

The contractual classification of a delay should not be confused with its technical measurement. Delay Analysis may demonstrate that a particular event shifted a milestone; even so, the contract may assign different consequences depending on responsibility, the risk matrix, and applicable clauses.<\/p>\n\n\n\n

In terminology widely used in construction contracts, an excusable delay may justify an extension of time, while a compensable delay may, in addition to time, support certain additional costs. A non-excusable delay remains the responsibility of the party that assumed the risk or caused the event. The specific definition depends on the contract and applicable law, so engineering analysis should avoid turning these categories into automatic legal conclusions.<\/p>\n\n\n\n

This separation improves the technical opinion. First, the time effect is demonstrated: event, period, activity, criticality, and net impact. Then, the contractual interpretation is applied to determine whether that effect is recognized as an extension, compensation, assumed risk, or another treatment.<\/p>\n\n\n\n

In projects with multiple events, the classification also helps avoid poorly justified cross-offsetting. Two delays may occur during the same period and have different contractual consequences, even if both appear in the evolution of the network.<\/p>\n\n\n\n

Extension of time and prolongation costs are not the same demonstration<\/h2>\n\n\n\n

Demonstrating technical entitlement to an extension of time does not automatically determine the amount of prolongation costs. The first analysis answers how many days specific events affected completion or relevant milestones. The second must demonstrate which additional costs resulted from the actual increase in duration.<\/p>\n\n\n\n

Prolongation costs may involve management staff, temporary facilities, security, equipment, rentals, insurance, field administration, and other time-dependent items. However, each component needs to be compared with the actual period, the mobilized structure, and mechanisms already compensated by the contract.<\/p>\n\n\n\n

It is also inappropriate to automatically multiply an average daily cost by the number of days identified by Delay Analysis. The cost structure may vary throughout the project, some resources may have been demobilized, and certain costs may exist independently of the delay.<\/p>\n\n\n\n

Therefore, robust claims treat schedule and quantum as connected but distinct analyses. The schedule establishes the causal time window; cost records demonstrate what actually occurred within it. Convergence of these two tracks produces a more defensible conclusion than a simple financial extrapolation from the calculated days.<\/p>\n\n\n\n

Evidence supporting a delay analysis<\/h2>\n\n\n\n

The schedule alone is rarely sufficient. The analysis should cross-check the network against execution documents.<\/p>\n\n\n\n

Minutes, RFIs, site logs, reports, photographic records, design deliverables, access releases, mobilization, procurement, equipment logs, tests, and correspondence help define the start, end, and mechanism of each event.<\/p>\n\n\n\n

This triangulation reduces the risk of modeling dates solely from the parties\u2019 later narratives.<\/p>\n\n\n\n

Supplier delay and interfaces between contracts<\/h2>\n\n\n\n

In projects with multiple packages, one supplier may delay another without a direct contractual relationship between them. The analysis needs to trace the interface: which delivery was the predecessor, when it was required, when it became available, and what alternative existed.<\/p>\n\n\n\n

Contracts, Scope, and Deliverables Management<\/a> helps formalize these boundaries before responsibility becomes diffuse.<\/p>\n\n\n\n

Mitigation, resequencing, and recovery plan<\/h2>\n\n\n\n

When an event threatens a milestone, the team may resequence work, increase resources, change shifts, release partial work fronts, or alter the execution method. These actions need to be reflected in the analysis.<\/p>\n\n\n\n

Reasonable mitigation does not mean eliminating every impact at any cost. The technical opinion should distinguish ordinary measures from extraordinary acceleration actions and record their effects.<\/p>\n\n\n\n

A recovery plan also does not automatically erase a delay that has already occurred; it shows how the organization intends to control the remainder of execution.<\/p>\n\n\n\n

How to present the conclusion of a Delay Analysis<\/h2>\n\n\n\n

A useful conclusion should not state only \u201cX days of delay.\u201d It needs to explain the event, period, reference schedule, method, critical path, assumptions, result, concurrency, mitigation, and limitations.<\/p>\n\n\n\n

A table by event is usually more useful than a single narrative:<\/p>\n\n\n\n

Event<\/td>Period<\/td>Affected activity<\/td>Criticality<\/td>Net impact<\/td>Evidence<\/td>Note<\/td><\/tr>
change A<\/td>verified dates<\/td>package\/system<\/td>critical or not<\/td>days<\/td>documents<\/td>assumptions<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Methodological transparency allows another team to reproduce the reasoning and challenge specific assumptions without rejecting the entire analysis.<\/p>\n\n\n\n

Common errors in delay analyses<\/h2>\n\n\n\n

One error is to start from the final date and allocate responsibility retrospectively. Another is to use the original baseline for every event without considering how the critical path evolved. Fragnets without a factual basis, unaudited updates, absence of a status date, and mixing delay with loss of productivity are also problematic.<\/p>\n\n\n\n

Another common mistake is presenting a mathematical result as a contractual conclusion. Delay Analysis demonstrates time impact; entitlement, risks, and clauses determine the consequence of that impact.<\/p>\n\n\n\n

Final considerations<\/h2>\n\n\n\n

Delay Analysis is a discipline of time causation. Its objective is to explain, using schedules and evidence, how events changed project sequence and milestones. Time Impact Analysis is an important tool within this field, especially for contemporaneous or prospective analysis, but it is not suitable for every case.<\/p>\n\n\n\n

The quality of the conclusion depends less on the software used and more on the quality of the baseline, updates, event modeling, and contemporaneous records. Method and data need to be compatible.<\/p>\n\n\n\n

When the analysis is integrated with Claim Management and contract governance, the schedule stops being merely a monitoring tool and begins to support decisions on changes, extensions of time, mitigation, and negotiation.<\/p>\n\n\n\n

Technical references<\/summary>\n

[1] SOCIETY OF CONSTRUCTION LAW. Delay and Disruption Protocol. 2. ed. London: SCL, 2017. Available at: https:\/\/www.scl.org.uk\/sites\/default\/files\/documents\/SCL_Delay_Protocol_2nd_Edition_Final.pdf<\/a><\/p>\n\n\n\n

[2] AACE INTERNATIONAL. Recommended Practices. Technical reference library, including forensic schedule analysis practices. Available at: https:\/\/web.aacei.org\/resources\/recommended-practices<\/a><\/p>\n\n\n\n

[3] AACE INTERNATIONAL. A Primer for Claims and Disputes (Claims 101). Source Extra, Aug. 24, 2022. Available at: https:\/\/source.aacei.org\/2022\/08\/24\/a-primer-for-claims-and-disputes-claims-101\/<\/a><\/p>\n<\/details>\n\n\n\n

Frequently asked questions<\/summary>\n
What is Delay Analysis in engineering?<\/strong>

It is the technical analysis that uses schedules and evidence to determine how events affected or may affect the critical path, milestones, and project completion date.<\/p><\/div>

What is Time Impact Analysis?<\/strong>

It is a method that models an event or fragnet in an updated schedule to assess its likely effect on the network, critical path, and milestones.<\/p><\/div>

Is TIA the only delay-analysis method?<\/strong>

No. There are prospective and retrospective approaches, including window analyses, as-planned vs. as-built comparisons, and methods based on the as-built. Selection depends on the data and purpose.<\/p><\/div>

What is the difference between delay and disruption?<\/strong>

Delay is associated with time and completion; disruption is associated with lost productivity and efficiency. The same event may produce both effects.<\/p><\/div>

Is a baseline schedule sufficient to prove a delay?<\/strong>

No. The analysis should consider updates, the contemporaneous critical path, events, field evidence, mitigation, and contractual conditions.<\/p><\/div>

Does Delay Analysis automatically establish entitlement to an extension of time?<\/strong>

No. The analysis demonstrates the time effect. Entitlement depends on the contract, risk matrix, notices, responsibility, and applicable rules.<\/p><\/div><\/div>\n<\/details>\n\n\n\n

Complementary technical materials<\/summary>\n

Main content on the topic<\/h4>\n\n