Time Impact Analysis

Construction projects rarely unfold exactly as planned. Design changes arrive mid-execution, material deliveries run late, approvals from governing agencies take longer than anticipated, and weather or site conditions introduce disruptions that no schedule can fully predict. For project managers and contractors, these realities are not exceptional events but recurring features of the work. What separates projects that recover cleanly from those that spiral into disputes and financial losses is largely the quality of documentation and analysis applied when delays occur.

Time Impact Analysis (TIA) is the construction industry’s most widely accepted method for measuring how a specific delay event affects the overall project completion date. It answers a precise question: given that a delay of a certain duration occurred at a certain point in the schedule, how many days was the project pushed back? The answer carries significant weight in contract disputes, time extension requests, and claims for additional compensation. Without a credible, schedule-based answer to that question, contractors often find themselves unable to defend their position before an owner, a contracting agency, or an arbitration panel.

TIA relies on the logic and float characteristics embedded in a project’s critical path method (CPM) schedule. By inserting a “fragnet,” a small fragment of the schedule representing a delay event, directly into the baseline or most recently approved schedule, the analyst can observe the precise ripple effect of that delay on all downstream activities and, ultimately, on the project’s end date. The method is respected by federal agencies including USACE and NAVFAC, and is referenced in standard contract specifications from state departments of transportation and major owners nationwide.

Microsoft Project is one of the most widely used scheduling platforms in the industry, and performing TIA within it is entirely feasible when the analyst understands both the mechanics of the tool and the underlying methodology. This article walks through the TIA process step by step, explains the conceptual foundations behind each action, and addresses the conditions under which results are defensible. It also outlines how Leopard Project Controls supports contractors, developers, and owners who need analysis-ready delay documentation aligned with agency specifications.

Whether you are preparing a time extension request, building the documentation for a delay claim, or simply trying to understand the schedule impact of a series of concurrent events, the methodology described here provides a reliable framework. When applied rigorously and supported by the right project controls expertise, TIA transforms schedule complexity into defensible, owner-ready evidence.

Overview

Project managers and construction managers around the globe always resist changes and additional work in projects. However, changes, additional work, or delays often find their way into a project. Whenever a delay occurs, the contractor has to evaluate its impact on the project timeline and cost. Here we will discuss a method to evaluate the impact from the perspective of the timeline.

The most common method used in the industry to determine the impact of delays on the timeline of a project is TIA (Time Impact Analysis). As an outcome of performing TIA on your project, you will get to know the change in the end date of your project. Once you know the number of days your project is delayed, you can start working on the additional cost evaluation to be claimed from the employer. Let’s move toward the most simplified guide to performing TIA analysis on your project.

Prerequisites to perform TIA

There are certain things you should know before moving toward performing the TIA on your project. Preparing properly before inserting fragnets into the schedule is what separates a credible analysis from one that an owner or reviewer can easily challenge.

List of all delays

There can be many delays that have impacted your project. It is advisable to make a comprehensive list of all these delays before beginning the analysis. Capturing each delay with its start date, duration, cause, and the activity or work scope affected gives the analysis structure and makes the eventual documentation far easier to review. These delays will later be represented as fragnets when added to the project schedule. If “fragnet” is a new term, commit it to memory now. It is central to understanding TIA entirely.

Each fragnet should correspond to a distinct, documentable delay event. Good source documents for building this list include RFIs with delayed responses, change order logs, weather records, inspector availability logs, and written correspondence noting late approvals or design revisions. The strength of a TIA is only as good as the documentation supporting each delay event.

Obtain the recently updated and approved schedule

TIA should be performed on the most current schedule of your project, meaning the schedule that reflects progress up to the point just before the delay events under analysis. This schedule must be duly approved by the client or the client’s representative. It is imperative that the schedule’s activities are properly linked, with successors and predecessors correctly assigned throughout. Calendar settings must also reflect what was agreed upon and approved by the client.

This starting schedule may carry some free float or buffer in certain activity chains. That float matters because it will absorb delay before affecting the project’s end date. Understanding where float exists, how much is available, and which chains are already on or near the critical path is essential groundwork before inserting any fragnets. An analysis performed on a poorly maintained or unapproved schedule is unlikely to hold up under scrutiny.

Understanding the critical path before you begin

The critical path is the sequence of activities whose combined durations determine the minimum possible project completion date. Any delay to an activity on the critical path, assuming no float absorbs it, directly delays the project. Activities off the critical path have some float and can absorb limited delays without extending the end date. Knowing which activities are critical in your approved schedule, and understanding the float distribution across the schedule, informs how you interpret TIA results and how you prioritize which delay events require the most detailed analysis.

Performing TIA step by step

The following walkthrough uses a simplified example to illustrate the TIA process clearly. The principles apply equally to complex projects with hundreds of activities.

Insert fragnets into the schedule

In our most simplified example, we will add three delays (fragnets) to the project. A fragnet is inserted next to the activity that experienced the delay. At the time of insertion, the fragnet’s duration is set to zero days. This zero-duration approach is intentional: it allows the analyst to confirm that adding the fragnet in the correct logical position does not, by itself, affect the project end date. The fragnet is linked into the schedule just like any other activity. Its predecessor is the activity immediately before it in the affected chain, and its successor is the activity that follows.

See the picture below. We have a simplified project of 11 activities. The end/completion date of the project is 09 April 2016.

Simplified Project of 11 Activities

Now we are going to add three fragnets to the schedule. These fragnets represent delays reported in the following three activities: Excavation at serial no. 3, Pad Concrete at serial no. 6, and Electrical Work at serial no. 10.

Three Fragnets to the Schedule

There is no effect on the project’s end/completion date because the fragnets’ duration is set to zero days. This confirms that the logic is correctly placed and that the analysis can proceed.

Incorporate delay duration into fragnets

With the fragnets correctly positioned and logically linked, we now assign the actual delay durations to each one. In our example, there is a delay of 4 days in Excavation, 5 days in Pad Concrete, and 7 days in Electrical Work at serial no. 10. We enter these durations into the corresponding fragnet duration fields. The brown Gantt bars representing the fragnets will now appear on the schedule.

Gantt Bars on the Right Side

The change in the project’s end/completion date is now visible: the original date of 9 April 2016 has shifted to 25 April 2016. The total delay calculates to 16 days (4 + 5 + 7). Because there is no float in this example and all 11 activities sit on the critical path, every day of delay in any fragnet translates directly into a corresponding shift in the project end date.
In real-world projects, fragnets are often inserted one at a time, with a fresh schedule calculation run after each insertion. This sequential approach allows the analyst to isolate the contribution of each individual delay event to the project completion date, rather than reporting only a combined total. This granularity is frequently required when preparing delay claim documentation or responding to owner challenges.

Evaluate the critical path

As there is no float available in this example project, all 11 activities are on the critical path. Any delay in any activity directly delays the project end/completion date. If float had been available, it would absorb delay to the extent possible before pushing out the completion date.

In projects with more complex networks, evaluating the critical path after each fragnet insertion is an important analytical step. Float consumption should be tracked throughout. When a non-critical activity’s float is fully consumed by a delay event, that activity joins the critical path, and further delay to it will directly impact the end date. This dynamic is common on large construction projects where multiple concurrent changes occur over extended durations.

MS Project calculates the critical path automatically once activity durations and logic are entered correctly. You can display the critical path using the Format menu, and it is advisable to confirm that the critical path rendering aligns with your expectations before finalizing any TIA results. Errors in predecessor/successor logic, incorrect calendar assignments, or activities with imposed dates can produce unexpected critical path results that, if undetected, will undermine the credibility of your analysis.

TIA in practice: common scenarios and considerations

While the step-by-step example above uses a small, clean schedule, real projects introduce complications that require careful judgment. Concurrent delays occur when multiple delay events overlap in time. Determining which delay is driving the critical path during a period of concurrency is one of the most contested issues in construction claim disputes. A well-structured TIA addresses this by modeling fragnets in the windows where each event actually occurred and by documenting the critical path condition during each window.

Another common complication is pacing: a situation where one party deliberately slows work in response to a delay caused by another party. If a contractor was pacing their work because of an owner-caused delay, their apparent delay may not be independently compensable. Identifying and documenting pacing conditions requires careful review of field records alongside the schedule analysis.

The quality of schedule logic also affects TIA validity significantly. Open ends, missing relationships, lags used as substitutes for missing activities, and activities that drive dates artificially due to imposed constraints all create distortions that can misrepresent delay impacts. Before performing TIA on a schedule that has not been thoroughly reviewed, a schedule audit is advisable. Leopard Project Controls routinely conducts schedule reviews prior to TIA work to ensure the underlying CPM schedule is sound enough to support defensible analysis.

How Leopard Project Controls supports TIA and delay analysis

Leopard Project Controls is a registered engineering firm and certified general contractor based in Florida, serving general contractors, developers, subcontractors, and public agencies across the United States. The firm’s core practice covers CPM scheduling, baseline schedule development, progress update support, and construction delay analysis, all performed in Primavera P6 and Microsoft Project and aligned with agency specifications from USACE, NAVFAC, VA, state DOTs, and other public clients.

When it comes to TIA specifically, Leopard’s work goes beyond generating a fragnet and reporting a number. The firm analyzes the full ripple effect of delay events, evaluates float loss and critical path shifts across the entire schedule, and produces submission-ready documentation that ties each delay to its cause, its contractual basis, and the specific time extension being requested. This documentation includes owner-facing narratives, Gantt charts and delay diagrams, as-planned versus as-built comparisons, and summaries of delay logic structured for review by agency project managers and legal teams.

The firm’s TIA support is formatted to meet the requirements of specific contracting agencies. Formatting alignment with USACE, NAVFAC, VA, and DOT specifications reduces the risk of submission rejection on procedural grounds, which is a meaningful advantage when time extension requests are time-sensitive. Leopard also offers optional add-ons including claim strategy consulting and Power BI dashboards for clients who need to present delay information visually to project owners or executive stakeholders.

Beyond TIA, Leopard’s delay analysis services cover the full range of recognized methodologies, including impacted as-planned analysis and collapsed as-built analysis, as well as comprehensive schedule review for contractors preparing to submit baseline schedules for federal or state approval. The firm’s baseline schedule development service produces CPM schedules aligned with Primavera P6 and MS Project requirements and includes unlimited revisions until the schedule receives client or agency approval.

Contractors who engage Leopard early in a project are better positioned to defend their time and cost positions when challenges emerge later. A well-maintained, regularly updated CPM schedule is the foundation of every effective TIA. Leopard’s progress update support service ensures that schedules remain current, accurately reflect actual progress, and retain the logical integrity needed for defensible delay analysis at any stage of the project.

For contractors navigating federal contracting environments, Leopard’s owner’s scheduling consultant and owner’s representative services provide an additional layer of support. These services help owners and their representatives evaluate contractor-submitted schedules, assess delay claims, and maintain independent schedule oversight throughout the project lifecycle. Whether the engagement begins at the bid phase with a free bid schedule or at the dispute stage with a full delay claim package, Leopard’s scheduling and project controls team provides the technical depth and documentation quality that complex construction projects require.

Summary

Performing TIA on a project enables the project manager to understand the impact of extra work, the number of additional resources required, and the new completion date of the project. The results of TIA should be communicated to the client as soon as possible after the analysis is completed.

Conclusion

Time Impact Analysis is one of the most consequential tools in construction project controls. When delays occur, which they will on virtually every project of meaningful scale, the ability to quantify their effect on the completion date with schedule-based precision is the difference between a time extension request that stands up to scrutiny and one that an owner or agency can dismiss. The fragnet method described in this article, applied to a properly maintained and approved CPM schedule, produces that precision.

The mechanics of TIA in MS Project are straightforward once the conceptual foundation is in place. Insert fragnets at zero duration to confirm logical placement. Assign actual delay durations. Observe the impact on the project’s critical path and end date. Run the analysis event by event when granularity is needed, and document each step thoroughly. The schedule software does the arithmetic; the analyst’s job is to ensure that every input is accurate, every link is defensible, and every result is supported by contemporaneous project records.

What separates a routine TIA from a truly defensible one is the quality of the underlying schedule, the rigor of the delay documentation, and the clarity of the narrative connecting delay events to their schedule impacts. A fragnet without supporting correspondence, field records, or change order documentation is a number without a story. Owners and agency reviewers have seen enough delay claims to identify analyses that lack evidentiary support, and those claims rarely succeed.

Contractors who invest in proper CPM scheduling practices from project inception are in a far stronger position when delay events arise. An approved baseline schedule with clean logic, a regularly updated progress schedule that reflects actual conditions, and a team or consultant capable of performing rigorous TIA are the elements of a project controls environment that can protect a contractor’s time and cost position throughout a project’s life.

The construction industry continues to move toward greater schedule transparency and more rigorous delay documentation requirements, particularly on federal and state-funded projects. Agencies that previously accepted narrative-only delay justifications now routinely require fragnet-supported TIA with critical path analysis, float evaluation, and formal time extension submissions. Contractors who are not prepared to meet that standard are at a structural disadvantage in any dispute, regardless of the merits of their underlying position.

The methodology outlined in this article gives any project manager or scheduler the tools to begin performing TIA independently. For projects involving significant delay events, complex concurrency questions, federal contract requirements, or potential litigation exposure, engaging experienced project controls consultants is a sound investment. The cost of a well-prepared TIA is almost always a fraction of what is at stake in the time extension or claim it supports.If you have questions about performing TIA, need support with construction delay analysis, or require CPM scheduling services aligned with agency specifications, contact Leopard Project Controls at consultleopard.com or call (833) 777-6276.

Questions and Answers

What is a fragnet and why is it central to TIA?

A fragnet is a schedule fragment, typically a single activity or a small group of activities, that represents a specific delay event. It is inserted into the existing approved project schedule at the logical point where the delay occurred, with its own predecessor and successor relationships. By starting the fragnet at zero duration and then adding the actual delay duration, the analyst can isolate and measure exactly how that event affected the critical path and the project completion date. The term is standard in delay analysis and appears frequently in contract specifications that govern time extension procedures.

Can TIA be performed in MS Project, or is Primavera P6 required?

TIA can be performed in both MS Project and Primavera P6. The methodology is the same regardless of the platform. Both tools support the insertion of additional activities, logical linking, and automatic recalculation of the critical path and project end date. The choice of platform is generally determined by whatever software was used to develop and maintain the project’s approved schedule. Many federal and large public contracts specify Primavera P6, but MS Project is widely accepted on commercial and private projects and is used by contractors across a broad range of project types.

What documentation do I need to support a TIA?

The schedule analysis itself is only one component of a complete TIA submission. Supporting documentation typically includes the approved baseline schedule and all subsequent progress updates, the specific records establishing that the delay event occurred and when it occurred (such as RFIs, design change notices, weather logs, or inspection reports), and correspondence that ties the delay to the responsible party. Change orders, daily reports, meeting minutes, and photographs can all serve as supporting exhibits. The stronger the contemporaneous documentation, the more credible the TIA, and the harder it is for an owner or agency to challenge the time extension request.

How does float affect TIA results?

Float is the amount of time an activity can be delayed without affecting the project’s critical path or end date. When a fragnet is inserted into a schedule that carries float, the delay will first consume the available float before pushing out the project completion date. If a fragnet with a duration of five days is inserted into an activity chain that has three days of float, only two days of compensable delay will result. This is why the condition of the schedule, and in particular its float profile, at the time each delay occurred is so important to TIA. Using an outdated or unapproved schedule as the basis for analysis can misrepresent the available float and therefore misstate the compensable delay.

When should a contractor engage a project controls firm for TIA rather than performing it in-house?

In-house TIA is entirely appropriate for straightforward delay events on projects where the schedule is well-maintained and the delay documentation is clear. The analysis in this article is a reliable starting point. However, when delays are concurrent, when the contract is with a federal or state agency that requires specific submission formats, when the delay involves potential liquidated damages exposure, or when the analysis may eventually be used in a dispute or arbitration, engaging an experienced project controls firm is advisable. Firms like Leopard Project Controls bring the methodological rigor, agency-specific formatting knowledge, and claim narrative experience to produce TIA documentation that holds up under the highest level of owner or legal scrutiny.