8.3 TIA, Windowed Analysis, and Subtractive Models

8.3 TIA, Windowed Analysis, and Subtractive Models

Forensic methods answer different questions. A method should fit the timing of the analysis, the available schedules and records, and the governing contract. A sophisticated calculation on unreliable data is not stronger than a simpler method whose assumptions can be tested.

Prospective time impact analysis

A time impact analysis (TIA) models the prospective incremental effect of a defined change or event. A common workflow is:

1. select the appropriate accepted or otherwise justified contemporaneous schedule;
2. verify its data date, status, logic, calendars, and critical path;
3. build a fragnet that represents the event’s activities, durations, and tie-ins;
4. insert the fragnet without silently changing unrelated logic;
5. recalculate and compare relevant milestone dates; and
6. document mitigation, assumptions, and subsequent developments separately.

“Immediately preceding update” is a useful starting concept, not a substitute for judgment. The analyst must consider whether that update reflects status immediately before the event and whether the contract identifies a schedule of record. RP 52R-06 provides prospective TIA guidance but describes itself as a Recommended Practice, not an inflexible universal rule.

Windowed observational analysis

A windowed or contemporaneous-period analysis examines change over successive periods. Typical steps include validating each update, selecting consistent window boundaries, identifying the controlling or longest path, measuring milestone movement, and tracing the events active in that window.

Strengths include visibility into critical-path migration and contemporaneous management decisions. Limitations include dependence on update quality and possible sensitivity to the chosen windows. If logic is heavily revised without explanation, the analyst must distinguish progress effects from non-progress schedule changes.

Subtractive or collapsed as-built analysis

A collapsed as-built method begins with an as-built model and removes selected impacts to estimate a but-for completion. It can be useful when the completed sequence is well documented but reliable baseline/update models are absent.

Its central challenge is reconstructing logic. Actual dates show when work happened, not necessarily why the sequence occurred or which relationships were controlling. The analyst must justify the as-built logic, removal rules, and treatment of pacing, mitigation, and parallel paths. The method is not automatically invalid, but it is often assumption-sensitive.

Comparison

Keep conclusions within scope

If a fragnet moves completion by ten days, the calculation establishes a ten-day modeled incremental effect under the tested assumptions. It does not alone establish that one party caused all ten days, that the contract grants ten days, or that ten days of costs are recoverable. The analyst separately evaluates responsibility, concurrency, mitigation, notice, and cost evidence.

Reproducibility checklist

• Preserve native source files and calculation settings.
• State the calendar and date-counting convention.
• Identify every added, deleted, or revised relationship.
• Explain critical-path or longest-path criteria.
• Reconcile actual dates with records.
• Test material alternative assumptions.
• Separate schedule impact from legal entitlement.

These practices make the work reviewable even when reasonable analysts disagree about method selection.

Applied review: understand what each method changes

A prospective time impact analysis inserts a modeled fragnet into an appropriate unimpacted or current schedule to estimate forward-looking effect. A windows analysis examines changing conditions and controlling paths across defined periods using contemporaneous updates and records. A collapsed as-built analysis removes modeled delay influences from an as-built representation to test a hypothetical result. These methods do not share the same data needs or answer exactly the same question.

For any method, validate the source schedules, calendars, constraints, actual dates, and logic; identify analyst modifications; and perform sensitivity checks. The selected window boundaries should reflect meaningful changes in status or driving path, not dates chosen to favor a conclusion. A fragnet should include all necessary predecessors, successors, approvals, and resulting effects rather than only the event duration.

Results remain technical opinions conditioned on assumptions and evidence. They do not automatically establish contract entitlement or responsibility. In an exam scenario, match the method to timing, records, and purpose, and reject answers that describe one technique as universally required.