Common Time Impact Analysis Submission Errors – Part I

A Time Impact Analysis (TIA) is a schedule delay analysis methodology that is used to estimate the project delay that was or will be caused by an event. Generally, the event is modeled as an activity or group of activities, known as a fragmentary network or “fragnet,” which is then inserted into a critical path method schedule to quantify the resulting delay.

Typically, to substantiate a time extension request, public owners specify that a TIA be prepared and submitted by its contractors to quantify the project delay that would result from added or changed work prior to the performance of that work. This type of TIA which is submitted before the added work is performed, is called a Prospective TIA.

While a contractor may attempt to comply with the contract requirement of a TIA to demonstrate its alleged delay, contractors’ TIA submissions often contain errors that make the analysis results ineffective or unreliable. The following are five mistakes that are commonly made in the preparation or submission of a TIA.

1. Late Submission: When a TIA is a contract requirement, the timing of the submission is critical. Often contracts will specify the time frame in which the contractor must submit a TIA. This is to provide notice and allow the owner the opportunity to evaluate the potential time impact and attempt to mitigate the potential delay before it is realized. It is not uncommon for a TIA to be submitted well after a potential delay event has occurred. When this happens, the owner may be prevented from investigating, documenting, and mitigating the alleged delay. Also, when the TIA is submitted late, the owner then has the added burden of evaluating the performance of all the work in the impact period and not just the alleged impact.
2. Incorrect TIA Baseline Schedule: A TIA requires that the delay event fragnet be inserted into the most recent owner-reviewed project schedule prior to the start of the delay event. This schedule becomes the analysis baseline or unimpacted schedule. This reliance on the schedule update that is in effect before the impact began as the basis of the analysis is one of the cornerstone concepts upon which the TIA method is founded. There are two primary reasons it is important to use the schedule update that is in effect immediately before the impact began. First, this schedule update includes all of the completed project work scope and all previous impacts and events up to the schedule’s data date and, therefore, that schedule depicts the project’s status immediately before the impact started. Second, and perhaps more important, is that as the project progresses, the performance of the work and impacts occur chronologically. This chronological occurrence of work and impacts affect the project’s completion date. By using the schedule update in effect before the impact started, the TIA’s baseline schedule captures the most current and accurate forecasted project completion date just before the start of the delay event. Therefore, it can be concluded that the delay resulting from the insertion of the TIA’s fragnet is directly attributable to the impact described in the TIA. Sometimes, contractors opt to use the project’s Baseline Schedule or another early project schedule update despite those schedules not being the schedule update immediately prior to the start of the impact. This is inappropriate because, as described above, the project’s plan often evolves over time in response to many factors. As such, relevant project information, including previous project delays, is ignored when the most recently reviewed schedule update before the impact is not used to estimate the delay of a new impact. If the incorrect schedule is used as the basis of the TIA, delay caused by another known or unknown impact is often presented as delay attributable to the alleged impact’s fragnet, which is a misrepresentation that renders the TIA inaccurate.
3. Using One Long Single-Activity Fragnet: A fragnet is composed of one or more activities that describe the scope of the delay event. Another error that contractors often make is depicting an impact that is composed of many events over multiple months as one long single-activity fragnet. There are several issues with this approach. First, a long single-activity fragnet, which spans several months, does not provide enough detail for the owner to verify the events that are causing the alleged delay. Second, each of the fragnet activities should also be logically tied to the relevant original work scope activities in the unimpacted schedule. This is difficult or even impossible to accomplish with one long, single activity that represents multiple events and actions. And third, the use of a long, one-activity fragnet can give the illusion that the fragnet, and, thus, the impact, is responsible for more delay than forecasted in the contemporaneous schedule updates. For example, let’s assume we have a project with monthly schedule updates. If a contractor inserts a 6-month-long fragnet activity into Update 1, then the delay forecasted in the impacted schedule assumes all of the other project work made expected progress during the 6-month duration of the fragnet. While this could be the case, it is also possible that other work that is not related to the fragnet was actually responsible for delaying the project during the fragnet’s six-month duration, and this actual cause of delay would be masked by the inappropriately modeled fragnet.
4. The Fragnet Does Not Accurately Reflect the Contemporaneous Events: This error occurs with TIAs that are created after the delay or impact has occurred, a methodology commonly known as a Retrospective TIA. When creating a Retrospective TIA, the contractor has the benefit of being able to look back at delay events with information well after the impact occurred. In a Retrospective TIA, the contractor will insert a fragnet into the unimpacted schedule with information that was not known contemporaneously. This can be a problem because the fragnet may not consider what was known and what was critical on the data date of the unimpacted schedule or the contemporaneous schedule updates during the fragnet’s duration. In these situations, the contractor has a responsibility to explain why the delay shown in the contemporaneous schedules is not a reflection of the true delay to the project. This is a step that is important but is often missed in a TIA submission, and a necessary aspect of any Retrospective TIA performed.
5. Combining Multiple Impacts and Their Fragnets into One TIA: Another common error occurs when contractors submit a TIA with multiple fragnets to represent multiple proposed delay events. This is incorrect because when construction contracts require the contractor to prepare and submit a TIA for a time extension the contract usually specifies that a TIA should only be used to quantify the delay of one event at a time. This is also an issue because often, contractors add together the resultant delay from each event to calculate the total delay instead of reconciling the concurrency between delay events or identifying the project’s critical path, and, therefore, forecasting more delay than the project actually experienced. Given the common occurrence of this error, and the significant erroneous results that it often generates, a full discussion with examples will be the subject of a future posting.

To avoid these errors and to produce a more accurate depiction of the delay caused by an event, the contractor should do the following:

• Submit timely notice of the potential delay.
• Then, within the time allotted by contact, prepare and submit a TIA for the alleged delay event.
• In the preparation of the TIA, create a simple fragnet that models each element of the changed work scope. Tie the fragnet activities to existing original work scope activities in the appropriate unimpacted schedule. If the delay event spans several schedule updates, consider using several unimpacted schedules in an analysis and insert relevant portions of the fragnet into each unimpacted schedule.
• If the cause of delay calculated in the TIA is different from what is shown in the contemporaneous schedules, explain why the contemporaneous schedules do not correctly represent the actual project delays.

For more on this or any other topic, please call me at 215-814-6400 or email me at brittany.salmon@traunerconsulting.com.

Did you enjoy this article?

Don't leave empty handed. Grab this free ebook!