Windows Analysis Part-1

windows analysis

Preparing a Windows Analysis – (Part 1) How Many Windows Should be Analyzed in Each Window of a Windows Analysis?

Preparing a Windows Analysis

Part 1 – How Many Windows Should be Analyzed in Each Window of a Windows Analysis?
That question is a mouthful, but very significant. Schedule analysts have several methodology options to select from when preparing a delay analysis. A good categorization is provided in the AACE 29R-03 publication. While some methodologies may be more appropriate in certain circumstances, I believe any method selected should reach similar conclusions if performed correctly.

I am a big proponent of the windows analysis (MIP 3.3 – Retrospective, Observational, Dynamic) approach to analyzing delays on projects where somewhat consistent and accurate schedule updates are available. This approach is the most objective and precise – if performed correctly. The AACE provides guidelines for this methodology, as well as other forms of windows analyses, but leaves out a key component for an accurate implementation of their protocols.
In my work I get to review analyses as well as prepare them. In recent reviews I have come across several expert reports that have misused this “windows analysis”, and as a result, misrepresented delay impacts to a project.
The referenced AACE protocols state, “Identify changes (gained or lost time) in overall Project completion date …and if necessary, in interim milestone completion dates” (29R-03, Page 52). Although a subsequent recommendation directs the analyst to “identify start and finish variances of critical and near-critical activities in the analysis period” (29R-03, Page 53), there is no specific direction on reviewing specific time frames within the analysis period.
Let me explain why more detail should be added to this protocol. As a scheduler I’ve spent years arguing what “on schedule” really means. Here is a typical scenario that will help set the stage – A contractor falls behind schedule (the Critical path slips in a schedule update), makes adjustments to future activities (reducing durations or resequencing) to keep the completion date from slipping, and reports that the project is on schedule.

My argument, illustrated here, is that there is a difference between “on schedule” and showing an “on time completion”. In this case I argue that the contractor is not on schedule, but instead is falling behind. Changes in future work was made to show a planned on time completion.

In other words, the represented completion date may not be an accurate reflection of the project status. From this example one may begin to see the two windows in a periodic schedule analysis. One window is the time frame between a previous schedule and a current schedule date reflecting current critical path progress compared to the previous report. The second window is the time frame from the current schedule date to the planned completion that can be manipulated independent of the current progress period or the impact of delays.
In the following chart the two windows are illustrated with a delay in the first and manipulation in the second to show on time completion. This is called critical path compression.

Picture1

The first window is the schedule progress period between the previous update and the current schedule date. In this period a delay occurred impacting progress on the critical path. The second window is the time frame between the current schedule date and the planned project completion. Between the current schedule date and the planned completion date, the schedule was adjusted to reduce the remaining project duration.

As you can see in this simple example, the project completion date can be bifurcated from the actual progress or delays. Therefore, on its own, the project completion date may not accurately represent delays to the project schedule. As a result, the analyst, when preparing a windows analysis, must look at the schedule progress in both windows of the update to accurately report on delays and impacts to the critical path as well as the planned completion date.

If an analyst is looking solely at the planned completion date to determine delays, there are only three possible conclusions. The project either gained time, maintained scheduled completion, or the scheduled completion slipped. On the other hand, if both windows are analyzed there are nine possible conclusions (three for each window):

• The critical path slipped during the first window, but the completion date maintained its planned date (the example above);
• The critical path maintained planned progress during the first window and the planned completion date also maintained its planned date.
• The critical path gained time during the update window, but other changes were made to show the completion date did not gain time, but instead maintained its planned date.
• The same three options on the critical path of the first window could occur while the planned completion date slips.
• The same three options on the critical path of the first window could occur while the planned completion date gains time.

Breaking the standard windows analysis into the two (2) time frames for each period gives the analysts a better perspective on what truly happened during the period. Without breaking the analysis into the two separate windows, the analyst is only giving half the story.
In part two, we’ll detail a process of analyzing each of the schedule windows. You can also register for our free webinars on “Managing Delays” and join the discussion.

Scroll to Top