If the Half-Step is the forensic analyst's scalpel for a single update, Windows Analysis is the forensic analyst's way of making sense of a whole project. The technique does exactly what it says: it divides the project duration into discrete time slices, analyzes delay within each slice, and then aggregates the results to tell a chronological story of how the completion date moved. It remains one of the most widely used retrospective delay analysis approaches in construction because it respects something the more aggregate methods often miss, which is that the critical path does not sit still over the life of a project.
Understanding why Windows Analysis is popular, and where it goes wrong, requires a quick orientation to how AACE RP 29R-03 classifies it, and then a look at the mechanics of doing it well.
A Quick Orientation Within AACE RP 29R-03
Windows Analysis is not a single method in the RP. It is a family of techniques that can map to several different Method Implementation Protocols (MIPs) depending on how the analyst executes it.
- MIP 3.3 (Observational / Dynamic / Contemporaneous As-Is / Fixed Periods) is a classic windows approach: take contemporaneous schedule updates as they were submitted, compare update-to-update, and report variance. Windows are the fixed periods between data dates.
- MIP 3.4 (Bifurcated / Split) adds the Half-Step inside each window to separate progress from revisions.
- MIP 3.5 (Observational / Modified or Recreated) is used when the contemporaneous updates need correction or reconstruction before analysis.
- MIP 3.7 (Modeled / Additive / Multiple Base) applies retrospective Time Impact Analysis to each window, inserting delay fragnets into the window's beginning-of-period schedule.
In practice, when practitioners say "I did a windows analysis," they usually mean one of these, and it matters which one. A sloppy claim that references Windows Analysis without specifying the MIP is a claim that will be vulnerable on cross-examination.
What the Method Does
The common thread across all windows variants is that the project timeline is broken into slices, and delay is measured within each slice rather than across the project as a whole. Slices are typically defined by monthly schedule updates, by significant events (change order executions, major milestones, seasonal transitions), or by quarters or other fixed intervals.
Within each window, the analyst identifies which activities were on the critical path during that window, which activities experienced delay, which of those delays affected the critical path, and what the net movement of the projected completion date was. The windows are then stitched together chronologically to produce a narrative of how the project completion date evolved.
This chronological structure is the method's primary strength. Delay rarely happens as a single event. It accumulates, gets partially recovered, re-emerges on a different path, and interacts with concurrent events. A method that respects this temporal texture produces results a trier of fact can follow. A method that aggregates everything into a single before-and-after snapshot does not.
The Procedure
The mechanics are straightforward, though the bookkeeping is considerable:
- Define the windows. Typically monthly, aligned with contemporaneous update data dates. Shorter windows produce more precise analysis but more work. Longer windows produce less precision but faster results. Match window length to the dispute's economic stakes and to the available data.
- For each window, identify the beginning-of-period (BOP) and end-of-period (EOP) schedules. Validate them. Apply Half-Step bifurcation if appropriate.
- Determine the critical path during the window. Not just at the BOP or EOP, but as it existed during that window. The critical path may have shifted within the window itself.
- Identify delay events that occurred during the window. Owner-caused, contractor-caused, force majeure, concurrent. Date-stamp each one.
- Quantify the delay's impact on the projected completion date as of the EOP. Attribute the delay to responsible parties based on causation evidence.
- Account for float consumption, mitigation, and recovery within the window.
- Move to the next window and repeat, using the prior EOP as the new BOP.
- Aggregate. The sum of window-by-window impacts should reconcile to the total project delay. Discrepancies indicate either analytical errors or legitimate delay drivers the analyst missed.
When to Use It
Windows Analysis is especially valuable in several situations:
- Long-duration projects where the critical path clearly shifted over time and a single before-and-after analysis would miss the texture.
- Multiple concurrent delay events distributed across the project timeline.
- Projects with meaningful schedule updates that document contemporaneous critical path.
- Disputes where causation timing matters, not just that a delay occurred but when it occurred relative to other events.
- Cases where an owner wants a defensible month-by-month story of how the completion date evolved.
The AACE RP generally treats contemporaneous period analyses as among the more reliable approaches when the underlying schedule updates are trustworthy.
Caveats Worth Respecting
Windows Analysis is only as good as its inputs and its discipline.
- Update quality governs result quality. If the contemporaneous updates are inaccurate, manipulated, or poorly maintained, the windows analysis built on them will carry the same defects.
- Window selection can drive outcome. The choice of window boundaries can affect what the analysis shows. An analyst choosing windows to optimize a preferred narrative will not survive cross-examination by a competent opponent.
- Critical path within a window is not always obvious. Projects with multiple near-critical paths, float manipulation, or significant logic changes during a window require careful analysis to identify what was actually driving the completion date.
- Concurrency treatment varies. Different windows approaches handle concurrent delay differently, and the chosen treatment affects results significantly. The analyst has to pick a concurrency theory and apply it consistently.
- Volume of work is real. A twenty-four month project analyzed monthly is twenty-four windows of effort. Tool selection matters.
Where It Sits in the Bigger Picture
Windows Analysis is the methodological middle ground of retrospective delay analysis. It is more detailed than a single before-and-after comparison, more grounded in contemporaneous data than a modeled approach like Collapsed As-Built, and more chronologically faithful than an aggregate impact analysis. For practitioners building a delay analysis that needs to stand up in litigation, arbitration, or serious claim negotiation, windows are often the right starting point.
The practical takeaway is this: Windows Analysis is a framework, not a prescription. Done well, with disciplined window selection, validated updates, and a clear MIP label, it produces a defensible chronological delay narrative. Done poorly, with chosen windows and undisclosed manipulation, it produces a result that will not survive a competent opposing expert. The difference is preparation, rigor, and intellectual honesty about what the data supports.
References
- AACE International, Recommended Practice No. 29R-03, Forensic Schedule Analysis (current edition). See MIP 3.3, MIP 3.4, MIP 3.5, and MIP 3.7.
- AACE International, Professional Practice Guide No. 20 (PPG #20), Forensic Schedule Analysis (2nd Edition). Collected papers on windows methods, including Gothand's "Schedule Delay Analysis: Modified Windows Approach" and related articles.
- Society of Construction Law, Delay and Disruption Protocol (2nd Edition, 2017). Addresses time slice / windows analysis as a preferred prospective and retrospective approach.
- Livengood, J.C. "Retrospective TIAs: Time to Lay Them to Rest," AACE Transactions. Contextualizes windows approaches against time impact analysis.