As-Planned, As-Built, and Windows: Forensic Schedule Analysis Methods

Forensic schedule analysis is the after-the-fact version of delay analysis: the project is finished, or far along, and someone needs to figure out how late it got, why, and who was responsible for which days. There are several accepted methods, and they don't always give the same answer from the same records. This post describes the common methods in plain terms, what each one needs, where each is vulnerable, and how practitioners usually choose. There's a worked windows example in the middle.

This is an overview for schedulers and project people, not legal advice and not a substitute for an expert. Contracts sometimes specify the method, and the forum you end up in may have preferences. Read your contract and talk to counsel before committing to an approach.

The vocabulary

AACE International's Recommended Practice 29R-03, Forensic Schedule Analysis, is the most widely cited reference. It sorts methods along a few axes, and the axes are more useful than the method names, because people use the names loosely.

• Retrospective vs. prospective. Forensic analysis is retrospective: it looks back. A time impact analysis done at the time of the event is prospective.
• Observational vs. modeled. Observational methods look at the schedules and records as they are and interpret what happened. Modeled methods insert or remove delays and recalculate to see what the CPM math says.
• Static vs. dynamic. Static methods compare against one fixed schedule, usually the baseline. Dynamic methods use the sequence of updates, so the critical path can move over time as it did on the job.
• Additive vs. subtractive. Additive models insert delay events into a schedule. Subtractive models remove them from an as-built schedule.

The main methods

As-planned vs. as-built

Observational and static. Compare the baseline to what actually happened, activity by activity and path by path, and identify where the actual dates diverged from the plan and why.

• Needs: A reliable baseline, actual start and finish dates, and project records explaining the variances.
• Strengths: Simple to explain. Works even when updates were poor or missing.
• Weaknesses: Ignores how the critical path shifted during the job. Struggles with concurrency and with changes in sequence. Gets weaker the more the project departed from the original plan.

Contemporaneous period analysis (update analysis)

Observational and dynamic. Use the monthly updates as they were actually prepared during the job. For each period between updates, look at how much the forecast completion moved and what was driving the critical path.

• Needs: A series of updates prepared during the project, ideally accepted by both parties.
• Strengths: Uses the records the parties relied on at the time. Captures shifts in the critical path. Hard to accuse of hindsight.
• Weaknesses: Only as good as the updates. Updates with bad logic, overridden progress, or changes made between periods without explanation undermine it. Sometimes the updates need to be corrected first, which opens its own argument.

This is the method most people mean when they say "windows analysis," though the term gets used for several dynamic methods.

Impacted as-planned

Modeled, additive, static. Insert fragnets representing one party's delays into the baseline and recalculate. The difference in finish is the claimed delay.

• Needs: A baseline and fragnets for each delay event.
• Strengths: Simple and cheap. Easy to show.
• Weaknesses: Ignores what actually happened, including the other party's delays and any progress that differed from plan. Generally considered weak in a contested dispute for exactly that reason. Better suited to estimating than to proving.

Time impact analysis, windowed

Modeled, additive, dynamic. For each event, insert a fragnet into the update in effect just before the event, and measure the change in forecast completion. Repeat through the job, in order.

• Needs: Good updates and well-built fragnets for each event. See Fragnets: What They Are and How to Write One.
• Strengths: Accounts for the actual status of the job at each event. Widely used and well understood.
• Weaknesses: Labor-intensive for many events. Done retrospectively, there's a temptation to tune fragnets with hindsight. Results depend on which update and ties you choose.

Collapsed as-built (but-for)

Modeled, subtractive. Build an as-built schedule with logic, then remove one party's delays and recalculate. The project would have finished earlier "but for" those delays; the difference is attributed to them.

• Needs: A detailed as-built schedule with defensible logic, which usually has to be reconstructed from records.
• Strengths: Grounded in what actually happened. Useful when updates are missing or unreliable.
• Weaknesses: Building as-built logic is subjective, and the result is sensitive to it. Removing delays from an as-built that was shaped by those delays can produce odd results.

A worked windows example

A project's baseline shows substantial completion on day 200. Monthly updates were accepted throughout. The analyst groups the job into windows and records the forecast completion at the end of each, plus what drove the critical path during it.

Actual completion is day 212, which is 12 days late. The windows add up: 8 plus 7 minus 3 is 12.

The allocation is where judgment comes in. The owner's rock caused 8 days. The contractor's steel caused 7. The contractor then recovered 3 days at its own expense. A common approach credits the recovery against the contractor's own delay, leaving 8 days owner-caused and 4 days contractor-caused. Another approach applies it proportionally, or to the period in which it occurred. Which is right depends on the contract, the facts (was the recovery voluntary or directed acceleration?), and the forum. The analysis should state the approach and why.

Each row also hides a smaller analysis. Within window 1, the analyst has to confirm that the rock was actually on the critical path, not just that it happened, and check whether anything else was critical during the same days. If the contractor's rebar was also late during that window, part of those 8 days may be concurrent. See Excusable, Compensable, and Concurrent Delay.

How to choose

Practitioners usually pick based on what records exist and what the dispute is about.

The quality of the updates usually decides it. A project with clean, accepted monthly updates and narratives makes the dynamic methods straightforward. A project with updates nobody trusted makes every method harder.

What makes any method easier

This part is for people still building the job, not analyzing it.

• Accept a baseline with sound logic. See Baselines: When to Set Them and When to Re-Baseline.
• Update monthly, with actual dates, and keep every update file.
• Write a narrative each month that names the critical path and explains changes to it.
• Record logic changes between updates, with reasons.
• Send notices at the time of events and do TIAs close to them.
• Keep daily reports that say what was stopped and why.

In schedule.construction, Claim Digger compares a baseline to an update, or one update to another, activity by activity, which is a fast way to see what moved in a window before you start explaining why. The explaining is still the analyst's job.

Key takeaways

• Methods differ on two main axes: observational vs. modeled, and static (one schedule) vs. dynamic (the sequence of updates).
• As-planned vs. as-built is simple but blind to critical path shifts; impacted as-planned ignores what actually happened.
• Contemporaneous period analysis and windowed TIA use the updates and capture shifts, but depend on update quality.
• Collapsed as-built works without updates but rests on reconstructed logic.
• The records you have usually pick the method. Good monthly updates make every method easier.