The Windows Technique

When a project finishes late, everyone wants to know two things: how much delay there was, and who caused it. A windows analysis answers by measuring delay the way the project team actually experienced it, one update period at a time.

The technique slices the project timeline into consecutive chronological windows. Within each window, the analyst steps through the critical path chronologically and cumulatively, using the schedule logic that was actually in effect when the delay events were happening. It works much like a retrospective Time Impact Analysis (TIA), which walks through each delaying event in order, but it is anchored to the contemporaneous schedules. That is why this variation is called a Contemporaneous Period Analysis (CPA).

In AACE International Recommended Practice 29R-03, Forensic Schedule Analysis, this approach is classified as MIP 3.4: Observational / Dynamic / Contemporaneous Split. The "split" refers to the bifurcated analysis described below, which separates the effects of progress from the effects of schedule revisions.

Here is how I perform one, step by step.

Step 1: Collect and validate the schedules

A CPA is only as good as its source data, so the first job is to gather and validate the schedules.

The baseline. Check the project records for an approved CPM baseline schedule that meets the contract completion date. Review it for complete logic, reasonable durations, and appropriate calendars. If it holds up, it becomes the Accepted Baseline Schedule.

The updates. Next, identify every contemporaneous progress update, whether monthly, bi-weekly, or weekly. Evaluate each one the same way you evaluated the baseline.

Reliability, not perfection

The baseline and updates do not need to be perfect. Contemporaneous schedules rarely are.

There is an important difference between validating a schedule for project controls and validating it for forensic analysis. In day-to-day project controls, an owner may rightly reject an update for too many constraints, overly long durations, or minor missing logic. Strict compliance matters when you are administering construction contracts, especially on public projects.

In forensic analysis, rejection is usually not an option if those schedules were the tool the parties actually used to manage the job and make decisions. CPA is designed to analyze schedules as they were submitted. "Correcting" logic or rewriting the planned sequence after the fact can destroy the schedule's value, because it no longer reflects the project team's contemporaneous thinking.

How I treat a flawed schedule depends on how badly it is flawed:

Condition of the schedule	Examples	What the analyst does
Technical flaws, but it still tracks the critical path and overall progress	Excess constraints, long durations, minor logic gaps	Use it as-is. Identify, document, and disclose the flaws in the report.
Gross errors that break the CPM calculation but can be fixed surgically	Logic loops, progress reported after the data date	Make the minimum changes needed for the network to run, document every change, then proceed.
Updates so flawed or manipulated they cannot be used as-is	Excessive open ends, plugged start dates, artificial recovery / manipulation	Reject the updates and use a method that does not rely on them, such as a retrospective TIA or As-Planned vs. As-Built.

The threshold is data reliability, not data perfection. A schedule rejected for project-controls purposes can still be forensically viable. As long as it reflects the contemporaneous critical path and actual progress, it is valuable source data for measuring delay.

Build the as-built record

Finally, collect the records that make up the as-built record: daily logs, site diaries, progress photos, meeting minutes, weather data, and correspondence. Use them to spot-check the key actual start and finish dates reported in the updates.

Step 2: Define the windows

Divide the project timeline into discrete periods. Windows are typically bounded by the data dates of consecutive updates: Window 1 runs from the January 1 data date to the February 1 data date, Window 2 from February 1 to March 1, and so on.

Sometimes the plan changes fundamentally mid-project. The job may be formally re-baselined after significant scope changes or disruptions, or the team may shift focus to finishing one phase while others go on hold. In those cases, the re-baseline becomes a new starting reference point for the windows that follow, or for separate analyses of the split paths.

Step 3: Separate progress from revisions

CPA requires the analyst to separate and quantify the effects of progress and the effects of revisions, update by update. This is known as a bifurcated analysis. Its strength is that it mirrors how schedules are actually updated.

When a scheduler prepares an update, they first update the rear-view mirror: they enter the actual start and finish dates for the period just completed. Then they move the data date forward and recalculate. Finally, they adjust the windshield view, changing sequencing, logic, and durations so the schedule reflects the evolving plan for the next period and the rest of the job.

CPA unwinds those steps. It first measures how actual performance varied from the plan (progress), then measures how the plan itself changed (revisions). The tool that makes this possible is the half-step schedule.

Whatever moves between Schedule 01 and H1 is progress; whatever moves between H1 and Schedule 02 is a revision.

Step 4: Analyze each window

Build the half-step schedule

1.       Start with the schedule at the beginning of the window. For Window 1, that is the Accepted Baseline. For Window 2, it is the end-of-period update from Window 1. Call this Schedule 01.

2.       Make a copy of Schedule 01. This copy becomes the half-step schedule, Schedule H1.

3.       Update H1 with the actual start and finish dates for the period, plus remaining durations for in-progress activities. This progress data comes from the next update, Schedule 02.

4.       Move H1's data date to match Schedule 02 and recalculate. You now have the half-step schedule for the window.

H1 contains the original plan from Schedule 01 with only the actual progress from Schedule 02 applied. That is what lets you separate the two effects.

Once the half-step schedule is built, you already have the answer to a key question: how many days of delay (or gain) resulted from progress, or lack of it, during the window. The difference between the forecast completion dates in Schedule 01 and H1 is that number. Now you just have to figure out how to get from A to B: which activities drove the slippage, and when. It’s like a Sudoku puzzle where you can check your answer at the end. The chronological analysis in Part 1 has to land on the same number H1 already gave you.

Part 1: Measure the effect of progress

Compare Schedule 01 to the half-step schedule. Using the same chronological, cumulative approach as a retrospective TIA, step through the window and identify each controlling delay in the order it occurred, updating the start-of-window schedule as each impact is recognized. By the end of the window, your stepwise analysis should produce the same delay (or improvement) and the same critical path as H1.

An alternative is the Daily Delay Measure. Copy the start-of-window schedule and enter progress one workday at a time. Advance the data date a day, enter that day's progress, recalculate, and re-filter the critical or longest path. Record the critical activity and any change to the substantial completion date each day until you reach the end of the window. Again, the end-of-window result should match H1.

Either way, focus only on critical-path variances, looking at the critical and near-critical paths active during the window. Slippage or gain in the substantial completion date is the key variable. Only delays or improvements on the critical path move the forecast completion date.

Delays on non-critical paths still matter if they consume all available float. When a path loses its float and becomes critical, note the date it happens and identify it as a critical path shift.

Part 2: Measure the effect of revisions

The second half of the bifurcated analysis isolates delays and improvements caused strictly by changes to the plan. Compare the half-step schedule (H1) to Schedule 02.

Because both schedules share the same data date, any difference in the critical path or forecast completion date is attributable to revisions: logic changes, duration changes, added or deleted activities, calendar changes, and added or deleted constraints. Only revisions that resulted in a change(s) to the forecast substantial completion date count as the controlling revisions that resulted in the differences between the half-step schedule and the update. Tabulate each controlling revision as a distinct delay for the causation analysis step.

Step 5: Research causation and allocate responsibility

Cross-reference every controlling delay and controlling revision identified in the window against the project records. Review the available project documents, such as the daily reports, RFIs, change orders, and project correspondence until you find cause of the delay and the party responsible. Then assign responsibility for the window:

Responsible party	Typical classification
Owner / Employer	Excusable and compensable
Contractor	Inexcusable
Third party or Force Majeure	Excusable, non-compensable
Overlapping critical paths or causes	Concurrent delay

Finally, build a variance and allocation table for the window. It should show planned vs. actual progress delays and improvements, delays or improvements due to schedule revisions, calendar days of slippage or gain, the root-cause event and supporting evidence, and the net delay assigned to each party.

The bottom line

Repeat the process window by window, and the results build into a chronological, cumulative account of how the project's completion date moved and why. Because CPA uses the schedules the team actually relied on, its conclusions reflect what the parties knew and planned at the time, not a plan rebuilt in hindsight. That is what makes it one of the most persuasive delay methods available when the contemporaneous updates are reliable.