Windows analysis or retrospective time impact analysis?

When a project finishes late and the delay is disputed, someone has to show when the time was lost, on which work, and who was responsible for it. Two families of method dominate that work: the windows analysis, which observes what the schedule updates recorded, and the time impact analysis, which models the effect of an event by adding it to a schedule.

Both are recognised methods. They answer different questions, and using one where the other belongs is one of the most common reasons an analysis does not survive scrutiny.

Windows analysis: observing the record

A windows analysis divides the project into periods, usually between consecutive schedule updates. For each window it measures how far the forecast completion moved, and identifies the path of work that drove the movement.

Its strength is that it works from contemporaneous evidence: the schedules the project team actually issued, statused at the time, with the critical path they showed then. The analyst's main judgements are which updates to rely on and how to explain the movement in each window, and both can be checked against the same documents by anyone.

Its weakness is that it is only as good as the updates. Poorly statused updates, missing logic or re-baselining in the middle of the project all make the windows harder to read, and sometimes have to be corrected and explained before the analysis can stand.

Time impact analysis: modelling an event

A time impact analysis takes a schedule, inserts a fragment of activities representing a delay event (a fragnet), recalculates, and measures how far the completion date moves.

Used prospectively, while the work is still ahead, it is the natural way to price a time extension for a change: it asks what this event is expected to do to the plan. That is how many contracts expect extension requests to be made.

Used retrospectively, after the work is done, it has drawn sustained criticism. The result depends heavily on the analyst's choice of schedule, fragnet durations and logic, and it can show an effect on completion that the project's own record never showed. Where good contemporaneous updates exist, a modelled answer that disagrees with them is hard to defend.

Choosing between them

The method should follow the evidence and the contract, not the other way round:

• Good, regularly statused updates exist. A windows analysis can rely on them directly, and is usually the stronger choice after the fact.
• The contract prescribes a method for extension claims. Follow it, and say so.
• The question is prospective: what will this change do to the finish? A time impact analysis is built for that.
• The record is poor. Every method becomes harder. The updates may need correcting first, and that correction is itself part of the analysis that must be explained.

Whichever method is used, overlapping delay has to be dealt with explicitly, and the allocation of responsibility is an expert judgement that the method informs but does not make.

How Schedule Cracker approaches it

Schedule Cracker measures the movement of the forecast finish in each window between your updates, and shows the path that drove it, from the dates stored in the updates as they were issued. Where delays overlap, the overlap is flagged as candidate concurrency for the analyst to assess. Responsibility is set by the analyst, day by day, and can be changed.

It also has a time impact tool for what-if questions. Its results are labelled as a model, and they never replace the observed record or decide entitlement.

Questions

Is one method accepted and the other rejected? No. Both are recognised. What matters is whether the method suits the question, the contract and the records available, and whether the analyst can explain each step.

Can a windows analysis be done without schedule updates? Not in the usual form. Without contemporaneous updates, the windows have to be reconstructed, and the reconstruction must be justified.

What is a fragnet? A small network of activities and logic representing a delay event, inserted into a schedule to model that event's effect.