Windows Analysis: Splitting a Schedule Into Delay Periods

What Windows Analysis Is

Windows analysis (also called time slice analysis) divides a project’s duration into consecutive periods -- windows -- and analyzes each one on its own terms: which activities were actually driving the critical path during that period, how many days the forecast finish date moved, and what caused that movement. The results are then added up across all the windows to explain the total gap between the original planned finish and the actual finish.

The choice of window boundaries matters more than it might seem. The standard, defensible approach sets each window boundary at a schedule update that actually existed on the project -- a monthly progress update, a recovery schedule, an update issued around a major change order -- rather than an arbitrary calendar split (every 30 days, every quarter). A window backed by a real update can be checked against the record; a window drawn on the calendar for convenience can’t.

The Fictional Project: Riverside Commons

A 210-calendar-day mixed-use building project, baselined with a substantial completion milestone on Day 210. Four schedule updates were issued over the life of the project in addition to the baseline, which sets up four windows. The major phases, several of them overlapping in the baseline logic:

The Four Windows

Each window compares the forecast finish date at the start of the period against the forecast finish date at the end of it. The difference is that window’s delay, and it’s attributed to whatever was actually driving the critical path during that specific period -- not to whatever looks like the biggest problem across the whole project.

Adding It Up

Summed across all four windows, the 35-day gap between Riverside Commons’ planned and actual finish dates splits roughly down the middle between owner-caused and contractor-caused delay -- a distinction that would be completely invisible in a single planned-vs-actual comparison run on the finish date alone.

Frequently Asked Questions

Do window boundaries have to line up with calendar months?

No -- and they usually shouldn't. Window boundaries are normally set to match the periodic schedule updates that actually exist for the project (monthly updates, a recovery-schedule update, a schedule tied to a specific change order). Matching real updates means every window's critical-path snapshot is backed by a schedule that was actually issued and can be checked, rather than an arbitrary calendar slice with nothing to verify it against.

What if the critical path changes partway through a single window?

It often does. If there happens to be an interim update at the point of the shift, that update becomes a new window boundary. If there isn't, the analyst has to reconstruct the shift within the window using the network logic itself -- identifying the date the driving path changed from the schedule's own float and logic, not just from the two update snapshots at the window's edges.

Can windows analysis be done while the project is still underway?

Yes. Done contemporaneously, each new periodic update simply closes one window and opens the next, so the delay attribution for each period gets locked in close to when it happened. Done retrospectively -- the more common case in a dispute -- the same method is applied after the fact using the string of updates that were actually issued over the life of the project.

How is this different from a Time Impact Analysis?

A Time Impact Analysis is prospective and single-event: it inserts one delay event into one schedule model to forecast that event's impact on the finish date. Windows analysis is retrospective and multi-period: it looks back across the project's actual sequence of updates and asks, separately for each period, what was really driving the critical path and how many days it moved -- often used specifically because a chain of Time Impact Analyses was never run contemporaneously.