Choosing between delay methods
Methods describes each AACE method implementation protocol in turn — what it is, what it needs, and what a tribunal tends to make of it. This page is the other half: the places where two methods are both available, both defensible, and give different numbers on the same file.
That is where a reader actually gets stuck. Nobody is confused about what a collapsed as-built is. People are stuck on whether to run one instead of a windows analysis, and on why the other side's expert reached a figure three times theirs without doing anything improper.
Method selection is a judgement the analyst makes and defends. This project does not make it for you — it runs the method you name, records the choices that produced the answer, and refuses a method name that does not identify one method.
The five pairings, in one table
| Pairing | The question that separates them |
|---|---|
| Time impact analysis vs windows analysis | Are you pricing named events, or locating where the time went? |
| As-planned vs as-built compared with collapsed as-built | Are you describing the variance, or running a counterfactual on it? |
| Observational vs modelled | Did the analyst alter the network, or only read it? |
| Prospective vs retrospective | What was known when the analysis was performed — and when was it actually performed? |
| Additive vs subtractive | Are delays being added to a plan, or removed from a record? |
Time impact analysis versus windows analysis
These two names are not even disjoint, which is the first thing to settle. A "time impact analysis" is additive and modelled, but the phrase does not say whether the fragnets went into one fixed base schedule or into the contemporaneous update current when each event happened. "Windows analysis" is looser still: it can mean static logic cut into periods, the project's own updates read period by period, or a modelled delay event inserted per window — and that last one is also a time impact analysis. Ask this tool for either name and it refuses, naming the methods the phrase could mean.
Once resolved, they answer different questions. A time impact analysis prices named events: for each one, what did it do to the completion date? It needs a base schedule, a fragnet per event with a duration and an attachment point, and the date the event is taken to have begun. It assumes the fragnet faithfully models the event and that the base is a fair reference to measure against.
A windows analysis locates time: between these two data dates, how much did the finish move, and what was driving it? It needs the update chain in order, with data dates, and nothing else. It assumes the updates are what they claim to be — which is why source validation matters more here than anywhere.
Each is inappropriate where the other's input is missing. A time impact analysis performed against a fixed baseline when a credible update chain existed and was not used is the most attacked analysis in this field, because it measures every event against a plan the project may never have been achieving. A windows analysis cannot price an event at all: it reports that the finish moved and what was driving, and movement no single activity owns stays unattributed. That is an honest limitation rather than a gap, and analysts needing a per-event figure sometimes read it as a reason to reach for an additive method the data does not support.
As-planned versus as-built, compared with collapsed as-built
Both start from what actually happened. Only one of them reschedules.
An as-planned versus as-built comparison is observational: set the plan beside the record and report the variance, over the whole job or period by period. It needs an as-planned schedule and an as-built record of dates, and no logic in the as-built at all — which is its whole appeal, because most as-built records are collections of dates rather than networks. It assumes the baseline was achievable, and it establishes variance rather than causation: the time was lost, not that any particular event lost it.
A collapsed as-built is modelled and subtractive: remove the delay activities from an as-built network and reschedule to ask when the work would have finished but for them. It needs a logic-bearing as-built whose durations and relationships recompute the dates the project actually recorded. That condition is a real gate rather than a formality, and most as-built models do not pass it — a model whose computed dates do not reproduce its own recorded dates is generating a counterfactual about a network the project never had.
The crux: an as-planned versus as-built comparison is cheap, usually admitted, and usually given little weight where the updates existed and were not used. A collapsed as-built makes a much stronger claim and carries a correspondingly heavier burden, because the as-built logic is normally built by the analyst after the fact and that construction is what the cross-examination will be about.
Observational versus modelled
This is the deepest of the five divisions and the one with a bright line across it: the analyst either altered the network or did not.
Observational methods read what is there — the baseline, the updates, the record — and quantify movement. Modelled methods insert fragnets or remove activities and reschedule, producing a network that never existed and asking what it says.
Both are legitimate. What is not permitted is mixing them in one analysis, because the result then acquires support its inputs do not give it. This tool keeps the two families in separate modules and every result names which produced it.
The asymmetry worth understanding: an observational method can show that time was lost and leave part of it unattributed, which looks like a weakness and is the measurement being honest. A modelled method attributes by construction — every day it reports is attached to an event, because events are what were inserted or removed. That is why modelled results read more decisively and are easier to attack.
One distinction inside the observational family accounts for real disagreements: an update chain contains revisions — added activities, changed logic, altered durations — mixed in with the progress. A method separating what the work did from what somebody changed about the plan attributes movement differently from one that does not, on the same updates, with neither analyst doing anything wrong.
Prospective versus retrospective
Timing here is a point of view, not a technique, and that is where the category error lives. An analysis performed after completion is retrospective even when the technique it uses looks forward. Inserting fragnets into an as-planned programme six months after handover is not a prospective analysis; it is a retrospective one using an additive technique, and it carries all of that technique's problems.
A genuinely prospective time impact analysis is a change-management exercise carried out while the job is live, days after the event, to support a contemporaneous request for a time extension. Its posture differs in three ways that matter: the base is the last owner-reviewed update statused before the delay rather than the baseline; hindsight is forbidden, because the base is assumed frozen; and it declines to analyse concurrency at all, deferring that to a retrospective method later.
Performed and submitted at the time, it carries the weight of a contemporaneous document, which is most of its value. Produced years later and presented as though contemporaneous, that is the first thing the other side will establish. This tool marks a prospective result as prospective and refuses to print a forensic method code for it, because a report that can print one eventually will.
Additive versus subtractive
They look like mirror images and they are not.
Additive modelling inserts delay into a plan and measures the movement. It needs a base schedule and an explicit definition of each event. Its structural limit is that it can only see what was inserted: delays nobody modelled — very often including the contractor's own — are invisible to it, so it cannot find concurrency by itself. Where two events interact, inserting all the fragnets at once and inserting them one at a time with a reschedule between each give different answers, and that choice is itself disclosable.
Subtractive modelling removes delay from a record and measures what is left. It needs a logic-bearing as-built, which is the expensive part. Its limit is different: removing an activity can change what was driving, and whether the resulting path is a fair counterfactual is a judgement rather than an arithmetic result.
So additive starts from a plan that may never have been achieved, and subtractive from a record but with logic nobody had at the time. Neither problem is fixable by care.
The same event, two methods, two numbers
The worked example carries the clearest illustration of this we can publish. One delay event on one generated scenario is worth nought working days under a subtractive collapse and five working days under an additive impact. Neither figure is wrong and neither method is misapplied — which is the whole argument of this page, and the reason a day count quoted without its method is not an answer.
Why two competent analysts differ on one file
Method choice is the largest source of divergence but it is not the only one. Each of the following is a decision somebody has to make, none of them is recorded in the schedule file, and each one moves the number.
| Decision | How it moves the answer |
|---|---|
| Which schedules were supplied | An update the analyst never received is a period nothing measures; a chain with a gap cannot sum to a defensible total |
| Which base schedule each event is impacted into | One fixed plan, or the update current when the event occurred — different analyses, different numbers |
| All fragnets at once, or one at a time | They differ whenever two events interact, which is exactly when the answer is contested |
| Where the window boundaries fall | Fixed periods, or periods chosen around events; the boundary decides which window owns a delay |
| The data date convention | Whether work reported on the data date is history or a future claim moves a day's delay between adjacent windows, usually owned by different parties |
| The progress mode | Retained logic, progress override, or the middle case — on a small worked example in Concepts §4 these differ by two weeks of project finish |
| Which sense of critical was used | Total float at or below a threshold, and longest path membership, disagree on real files |
| Which calendar a lag is counted on | A setting, not a fact about the link; it changes successor dates directly |
| Fragnet durations and event onset dates | Chosen by the analyst, and a fragnet with no stated onset is free to float back and understate its own impact |
| The concurrency analysis interval | Daily and monthly granularity can give order-of-magnitude different overlaps under one of the two theories |
| The day-count basis | Calendar days over an overlap window and working days on a named calendar measure different things and must never be added together |
This tool's position on all of these is the same: the choice is recorded on the result and printed in the report as a choice that could have gone the other way. It does not make the choice quietly and present the number as arithmetic.
And where the authorities themselves disagree
Method selection is not purely the analyst's where the contract has already made it. A specification section can prescribe the method, and a contract term beats a standard it conflicts with. On US federal work, which document governs the analysis is itself answered by the documents — and it is the precedence most often got wrong, because the most widely cited taxonomy is not the one that governs there.
Where two governing documents answer the same question differently, the report prints the disagreement and follows the one that binds, rather than resolving it silently. See the standards crosswalk.
Next: Methods for each protocol in turn, Concepts for the taxonomy the numbering comes from, the glossary for the terms, and the worked example for what the output looks like.
Source: web/pages/delay-method-comparison.md. Source commit date: 2026-09-11.