Acceleration and disruption: an authority map, and a scope boundary

This page is not legal advice and states no jurisdiction's answer. It sets out what named published documents say about acceleration and about disruption, where they diverge, and — the part almost nobody writing on this subject puts in writing — how little of either a CPM schedule can evidence on its own.

Acceleration and disruption get filed together because they arrive together in a claim and because both are about effort rather than about dates. They behave completely differently under the documents, and the reason is worth stating up front: acceleration is an event you can describe with a compliance checklist, and disruption is a measurement you cannot take without records a schedule file does not contain.

Acceleration: three kinds, and a different test for each

The documents that set out acceleration treat it as three separate things, not as one thing with three causes.

Kind What the cited documents describe What each asks for
Voluntary A party compresses the work on its own motion — to exploit a season, to release resources, to finish early for its own reasons ANSI/ASCE/CI 67-17 §11.1 puts the cost of it on the party that chose it
Directed The owner instructs the work to be compressed ASCE §11.2 places the agreement of the plan, the basis of payment and the revised completion date before implementation. SCL Protocol CP16 ¶16.1 takes the same position: where the contract does not already provide a basis of payment, one is agreed before the acceleration begins
Constructive No instruction to accelerate was given; the argument is that refusing or failing to act on a time-extension request had the same effect ASCE §11.3 states a conjunctive, sequenced set of five elements — an excusable delay, a request for a time extension appropriate to it, denial or a failure to act within a stated period, insistence on the earlier date together with the contractor's notice of a constructive change, and cost actually incurred. SCL ¶16.5 asks that the extension-of-time dispute route be exhausted before a constructive-acceleration claim is pursued

Three observations about that table, none of them a conclusion about any project.

Every cell is about the record, not about the network. Whether an instruction was given, whether a basis of payment was agreed, whether a request was denied — none of it is in an .xer file. A tool that read a compressed programme and reported acceleration would be inferring the whole claim from the one fact that is equally consistent with the contractor simply having replanned.

The five elements are conjunctive and each one is separately evidenced. That is ASCE's structure, and it matters because a checklist that scores four of five as a near miss has misread the test.

ASCE §11.4 makes the arithmetic iterative. Shortening the longest path does not finish the exercise; another path becomes binding behind it, and where different parties are responsible for delays on different paths the effort has to proceed path by path. This one is partly visible in a network — a second path sitting close behind the longest one is computable — and it is the only part of the acceleration subject where a schedule has something to say without an analyst first declaring the facts.

Why the schedule alone rarely shows acceleration

A programme that has been compressed between two updates does not distinguish acceleration from replanning. Durations shortened, relationships changed, crews notionally doubled — the file looks the same whether the change was directed, voluntary, or simply a planner's revised view of the same work.

The federal specification makes the point from the other side. UFGS 01 32 01.00 10 is a United States Government work and can be quoted directly. §3.9.1, on recovering progress:

Artificially improving progress by means such as, but not limited to, revising the schedule logic, modifying, or adding constraints, shortening activity durations, or changing calendars in the project schedule is prohibited.

and the same section requires that whatever a recovery plan proposes in resources, manpower or work hours "must be evident at the work site and documented in the daily report."

That is a specification saying, in its own words, that the schedule change is not the acceleration — the site is. It is also the clearest available statement of why this tool refuses to read acceleration out of a file.

Pacing, and the notice question where two documents conflict

Pacing is the other half of the same conversation and is frequently confused with it. A contractor who slows non-critical work in deliberate response to an owner delay that has already made speed pointless is pacing, not delaying. The distinction decides whether an alleged concurrent contractor delay exists at all — see concurrent delay for what turns on that.

AACE RP 29R-03 §4.2.G sets out three tests: that a parent delay exists, is at least as critical, and precedes the pacing; that the pacing party was contemporaneously able to resume; and that the decision to pace was contemporaneous and evidenced. The second limb of the first test is a calculation — the RP asks for the total float of the paced activity compared against the parent's, and that comparison is computable from a network. The other two are facts about the project record and are not.

The genuine conflict is on notice. The SCL Protocol at ¶15.2 recommends that a contractor intending to pace notify the other party of the intention and the reasons. AACE RP 29R-03 §4.2.G takes the position that contemporaneous pacing notices are exceedingly rare in any form, and that the absence of one must not be treated as a strict requirement of proof. For a claimant with no notice in the file those point opposite ways, and a rule that fails a pacing claim for want of a notice has silently picked one of them.

The standards crosswalk carries that conflict beside the others. This tool reports an unnotified pacing claim and does not fail it, and says in the finding which document it is following and which it is not.

Disruption is a productivity question, not a critical-path question

Here is the sentence that the rest of this page exists to support: disruption is largely outside what any CPM tool can evidence, this one included.

Disruption is loss of productivity — the same work taking more labour hours than it would have absent the disrupting events. It is not the gap between the plan and the outcome; the SCL Protocol is explicit at ¶18.6 that many causes of poor productivity are excluded from a disruption claim regardless of who carries the time risk, naming among them poor supervision, rework from the claimant's own defects, and over-optimistic tendering. A delay claim asks which events moved the completion date. A disruption claim asks how many hours were burned, on which work, against what the same crews achieved when nothing was interfering.

Nothing in that question is answered by a network of activities and relationships. The units are wrong: a schedule carries durations and dates, and disruption is measured in hours per unit of work installed.

What the literature asks for

Both of the major documents rank the methods, and they rank them the same way.

Family SCL Protocol (¶18.12–18.24) AACE (the lost-productivity cluster)
Project-specific studies Preferred. The measured mile heads the list at ¶18.16, together with earned value, work sampling and craftsman questionnaires The most preferred tier, and the same four techniques, with the measured mile described as the one that fares best in litigation
Project-comparison studies ¶18.17 — productivity on this project against a comparable project unaffected by the events, used where project-specific records are insufficient Second tier, and weighted below project-specific work
Industry studies ¶18.18–18.20 — published factor tables applied to actual losses; lowest of the productivity-based tiers and liable to be criticised as theoretical without corroborating project data Split into specialty and general industry studies, third and fourth, with the claimant required to show the project's facts fit the study's fact pattern
Cost-based methods ¶18.21–18.24 — last, and described as unlikely to persuade where a productivity-based method could reasonably be run; the output is effectively a global claim, carrying CP17's risks The last resort, gated behind a test about whether the bid and the incurred cost can each be relied on

The measured mile, as those documents describe it, compares productivity on an unimpacted period or area of the same or comparable work against an impacted one, on the same project. Its appeal is that both halves of the comparison come from the project's own actual performance, so no tender assumption has to be defended. Its precondition is the part that bites: a genuinely unimpacted comparator of sufficient length has to exist, and where the "impacted" period was also affected by causes nobody is claiming for, the adjustments needed to correct for that erode the result. SCL ¶18.16(a) says so in terms.

AACE's cluster adds one thing the SCL treatment does not stress: a productivity analysis is not a substitute for a schedule delay analysis. The two are companion exercises, and a claim for delay damages resting on a lost-labour calculation alone is described as insufficient for that purpose.

What a measured mile needs that a schedule file does not carry

Four things, in descending order of how far out of reach they are for a schedule-only tool:

  1. Resource assignments and actual installed quantities, per activity, per period. The XER format does carry resource and hour records; this project's importer reads the schedule and does not consume them, and even where it did, installed quantities are not in the file.
  2. A defensible unimpacted comparator period or area. SCL ¶18.19–18.23 makes that a judgment about the project, not a query over data.
  3. A productivity metric in units the contract recognises. Declared, never derived.
  4. Area, crew and event tagging, so that a productivity observation can be tied to the disrupting event rather than merely correlated with it.

What a schedule can contribute here

Not nothing, and it is worth being precise about the four things it does.

What this tool does, and what it refuses

It computes dates and floats, it checks a submission against the clauses of a named specification, and on this subject it mostly reports what a person has declared.

What it does lists the commands. Limitations records this scope boundary alongside the others.

Source: web/pages/acceleration-and-disruption.md. Source commit date: 2026-09-11.

See it in practice

Follow the evidence, from the schedule to the finding.

Explore the sample