Time Impact Analysis Template

Why Your TIA Keeps Getting Rejected by Claims Teams

I've spent the last twelve years doing this work on construction projects, and the number of Time Impact Analysis Template submissions I've seen fail because they don't actually match the CPM logic is high enough that it's not funny. Most people build these templates around what they want the schedule to show, not what the schedule actually contains. It's a structural problem. A Time Impact Analysis Template is a structured worksheet or spreadsheet framework used to quantify the effect of a specific change event on a project schedule. It's not a document you fill out once and archive. It's a living artifact tied directly to your critical path logic, and if that connection is broken anywhere in the template, the whole analysis falls apart. People treat it like a form. It's not a form. It's a methodology wrapped in a repeatable format.

Building a Time Impact Analysis Template That Survives Review

Here's how it actually works, starting from the point where most people go wrong. You begin by baselining. Not updating, not re-sequencing, not "cleaning up." You take the approved baseline schedule as of the date of the change event and freeze it as T0. If your baseline has more than 15% of activities with total float greater than 90 days, you have a float problem before you even start the TIA, and no template will fix that. I've seen analysts try to use a Time Impact Analysis Template to paper over a bad baseline, and the claims team saw right through it immediately. The workaround is to build a "cleaned" version of the baseline as a separate baseline version, noting exactly what logic corrections were made and why. Put that in the template appendix. That transparency usually stops the arguments. Next you identify the change event and log it. The date of the event matters more than people realize. If the event is a design change issued on a Tuesday, but the impact actually begins when the contractor receives and reviews the drawing, your event date should be the receipt date, not the issuance date. I learned this the hard way on a hospital project in Texas where the architect issued an MEP revision on a Friday and the contractor didn't open it until the following Wednesday. My first TIA used the issuance date and the defending consultant tore the analysis apart during the dispute review. The corrected version used the receipt date and showed a different critical path shift entirely. It cost me about three days of rework and a significant credibility hit. The lesson was simple enough that I now include a formal event date rationale field in every Time Impact Analysis Template I produce.

Then you slice the schedule. You create two windows: the period before the change event and the period after. Between those two windows you insert the change. The inserted change needs duration, resources, and logic ties to existing activities. This is where the template structure matters. A well-built Time Impact Analysis Template will have a section that maps each inserted activity to its predecessor and successor relationships with explicit constraint types. Free float, start-no-earlier-than, finish-no-later-than — these aren't details you skip. They're the difference between an analysis that holds up and one that collapses under scrutiny. The comparison step is straightforward in theory and tedious in practice. You run the schedule before the change and after the change. You extract the completion date from both runs. The difference is your delay impact. But here's what the surface-level tutorials don't tell you: the schedule run before the change and the schedule run after the change must use the exact same calculation settings. Same slow-down factor, same reset-to-zero logic flags, same resource leveling options. I've seen a TIA fail because someone ran the "before" window with level-by-level scheduling and the "after" window with the default algorithm. The resulting float values were incomparable. The template should lock these settings and flag any deviation as an error before you generate the report. One thing I want to emphasize because it comes up constantly. A Time Impact Analysis Template is most effective when the inserted change activities are detailed enough to reflect actual construction sequencing, not just high-level placeholders. "Pour foundation" with a 10-day duration tells the reviewer nothing. "Strip forms day 3, re-set reinforcement day 4, pour day 5–6, cure days 7–10" gives the reviewer something to audit. I typically require a minimum of three to five discrete activities per change event for anything above $50,000 in value. It sounds excessive. It isn't.

Common Pitfalls That Make TIAs Look Amateurish

There are several recurring issues I see that immediately undermine the credibility of a Time Impact Analysis Template submission. The first is the use of dummy activities to force logic. You should not be creating phantom dependencies to make the critical path look the way you want it to. If the critical path shifts because of the change, let it shift. Forcing it back to where it was before the change is essentially fraud dressed up as scheduling. The second is ignoring the impact on non-critical paths that become critical after the change. A TIA that only reports on the primary critical path is incomplete. You need to identify at least the top three near-critical paths and show how the change affects each one. I usually calculate a path risk index based on total float and number of activities, then run the before-and-after comparison across the top paths. This takes about twenty minutes in Primavera P6 with a properly structured template and can save you from a very uncomfortable conversation later.

The third pitfall is using outdated or superseded baseline logic. If the project has gone through two baseline revisions since the original approval, you need to know which version the TIA should reference. The rule of thumb is that you use the most recently approved baseline that was in effect at the time the change event occurred. Using a later baseline retroactively is a common tactic that disputes panels reject consistently. I had a project where the owner's scheduler argued that we should use the revised baseline from month six to analyze a change from month three. The panel agreed with me. The owner's scheduler didn't agree with the panel.

What a Good Time Impact Analysis Template Actually Looks Like

The structure I use consistently has these sections, in this order: Header metadata — project name, contract number, TIA identifier, change event description, event date, preparer name, and the baseline version being used. This should be populated automatically from the template header fields so there's no chance of manual entry errors. Executive summary — one paragraph stating the delay impact in days, the affected activities, and whether the critical path shifted. If the critical path did not shift, say so. If it did, note the new critical path. This section is read first and often determines whether the rest of the document gets thorough scrutiny.

Baseline status — a table showing the current schedule status as of the event date, including total project float, number of critical activities, and any known logic issues. I include a screenshot of the schedule from the relevant date range because visual evidence is harder to dispute than a table of numbers. Change event description — a detailed narrative of what changed, when it was communicated, what the scope alteration involves, and how it was implemented on site. This section should be written so that someone who wasn't on the project can understand exactly what happened without reading the contract documents. Schedule modification log — a detailed table of every activity added, deleted, or modified as part of the TIA. Each row should include the activity ID, original duration, modified duration, original logic, modified logic, and the reason for the change. This is the section that gets the most review attention. Get it right.

Before-and-after comparison — side-by-side outputs from the two schedule runs. I use a format that shows both the original completion date and the projected completion date after the change, along with the delta. I also include the critical path from each run so the reviewer can verify the path shift visually. Near-critical path analysis — a list of the top alternative paths ranked by float, showing how the change affected each one. This is where most TIAs are thin. Adding this section alone often elevates a mediocre submission to a defensible one. Supporting documentation — transmittal records, meeting minutes, RFIs, submittal logs, photos, and any other contemporaneous evidence that corroborates the timeline and scope of the change event. The weaker your documentation, the more the schedule analysis itself will be attacked. Strong documentation creates a moat around the TIA that reviewers hesitate to cross.

Limitations You Should Acknowledge Upfront

A Time Impact Analysis Template does not solve every scheduling problem. It assumes you have a credible, logic-rich baseline schedule to begin with. If your baseline is a high-level milestones schedule with no real duration data or only Finish-to-Start relationships, the TIA will produce numbers that look precise but are fundamentally unreliable. I've run TIAs on schedules where 60% of the activities had zero total float and another 20% were connected with loose constraints. The output numbers were technically correct but practically meaningless. In those cases, I recommend rebuilding the schedule logic first before attempting any TIA, even if it means pushing the timeline back by a week or two. Another limitation is that Time Impact Analysis only works prospectively. It measures the impact of a change as it was expected to affect the schedule at the time it was proposed. It does not account for subsequent mitigation efforts, recovery schedules, or productivity fluctuations that occurred after the event. If you need to measure actual delay rather than prospective delay, you're looking at As-Planned versus As-Built analysis, which is a different methodology entirely. Mixing the two approaches in the same document is a fast way to confuse the reader and weaken your position. Resource constraints are also a blind spot in standard TIA methodology. The classic Time Impact Analysis Template doesn't model resource loading unless you specifically build it in. On projects where multiple changes compete for the same crew or equipment, the schedule delay predicted by a resource-neutral TIA will often be shorter than the actual delay experienced on site. I've added a simplified resource overlay to my template in these situations, flagging any shared resources and estimating the cascading delay from resource contention. It's not perfect, but it's better than ignoring the problem.

Practical Tips That Come From Making the Same Mistakes Twice

Use the same software version for both schedule runs. A change from P6 2021 to P6 2024 can produce different float values on the same logic due to algorithm updates. I keep a software version field in my template header and never switch versions mid-analysis. Save the schedule state before every run. I maintain separate .xer or .ppXML export files for the before and after states, along with the original baseline. This lets me regenerate the analysis if something changes without having to rebuild from scratch. The templates I use typically cut rework time from about four hours down to thirty minutes when a resubmission is required. Don't over-engineer the inserted activities. A change event doesn't need every single bolt and weld modeled. But it does need enough granularity to show the actual sequence. I aim for the sweet spot where each inserted activity represents a definable construction phase that a reasonable estimator could price independently.

Document every assumption. If you assumed that weather delays wouldn't apply during the change period, state that assumption explicitly. If you assumed a specific crew size, note it. Reviewers will find unstated assumptions and treat them as concessions. Stated assumptions at least give you the opportunity to defend them. Peer review before submission. Have someone who wasn't involved in the analysis look at it fresh. They'll catch issues you've become blind to, usually within fifteen minutes. I've found that a second pair of eyes catches approximately one logic error or data inconsistency per TIA on average, and catching it before submission rather than during dispute is a significant advantage. The template itself should be designed for speed without sacrificing rigor. A well-structured Time Impact Analysis Template that auto-populates metadata, locks calculation settings, and flags missing logic ties can reduce the time from change event to first-draft analysis from a full workday to about two hours on a standard mid-complexity project. That speed advantage compounds across a project with multiple change orders, and it's the main reason I insist on using a consistent template rather than building each TIA from a blank file.