Extension of time: the clauses, the clocks, and the gate
This page is not legal advice and states no jurisdiction's answer. It sets out what named published specifications and recommended practices say about extensions of contract time — the notices they require, the clocks they run, the contents they prescribe for an analysis, and the one test that recurs in almost all of them. Whether any particular delay reaches any particular outcome is a question for the contract, the governing law, and the reviewing authority. This page names positions and does not resolve them.
Most of what is published on this subject is about the argument. The part that is actually in the documents, and that decides a great many requests before anybody reaches the argument, is the machinery: who must tell whom, within how many days, in what form, and containing what. That machinery is primary material, it differs sharply between agencies, and it is assembled below.
What the documents mean by an extension of time
An extension of time moves a contractual date — most often the completion date, sometimes a milestone or an interim date carrying its own consequences. The documents treat the time question and the money question as separate axes. The SCL Protocol is explicit that extension-of-time entitlement and compensation entitlement are decided independently and can come out differently on the same facts. AACE RP 52R-06 separates them deliberately as well, and states that time is granted without regard to a concurrent contractor cause unless the contract says otherwise. Which of those readings applies to a given contract is not something a schedule decides.
What is common to all of them is that the extension is a consequence of a finding, and the finding rests on an analysis of a network. That is where a schedule tool has something to contribute, and where it stops.
The gate that appears almost everywhere
Before anything else, nearly every specification read for this site imposes the same threshold: the delay must reach the completion date through the critical or longest path, having first consumed whatever float stands in front of it. A delay to work that never becomes controlling does not move the contract date.
The federal specifications state it plainly, and as United States Government works they can be quoted at length. UFGS 01 32 01.00 10 §3.8.6:
No time extension will be granted unless the delay consumes all available Project Float and extends the projected finish date ("End Project" milestone) beyond the Contract Completion Date.
Its NAVFAC sibling, UFGS 01 32 17.00 20, puts the same gate inside the clause that requires the analysis, at §1.11.1:
Submit a Time Impact Analysis with each cost and time proposal for a proposed change. TIA must illustrate the influence of each change or delay on the Contract Completion Date or milestones. No time extensions will be granted nor delay damages paid unless a delay occurs which consumes all available Project Float, impacts the longest path, and extends the Projected Completion beyond the Contract Completion Date.
Three conditions, conjunctive, in one sentence — float consumed, longest path impacted, projected completion pushed past the contract date. State agencies reach similar ground in their own words: ADOT's Section 108 provision, for instance, will not consider a request unless the affected work is a controlling item or becomes one, and MDOT SHA analyses a weather request for its impact on the longest path rather than by counting bad-weather days.
Two things follow that are easy to miss.
The gate is a network question, and it is the one thing on this page a tool can actually compute. Whether a given date movement reaches the contract completion date through the longest path is arithmetic over the imported schedule.
Whose float it was is not. The specifications differ on who owns float, and the difference changes how much delay the gate absorbs before anything reaches the date. See float ownership — Caltrans is the outlier among the agencies indexed here, and the federal sections assign float to the project rather than to a party.
The notice and submission machinery, agency by agency
Every row below paraphrases the cited clause; go to the agency page for the clause-level treatment, and to the specification itself for its own words. Where a column reads "not established", the requirement was not found in the material read, which is a statement about the reading and not about the specification.
| Authority | Notice or trigger | Analysis required | Submission clock |
|---|---|---|---|
| UFGS 01 32 01.00 10 §3.8 | Justification of the delay goes to the Contracting Officer within 10 days of the delay occurring | §3.8.3 prospective time impact analysis on AACE 52R-06; §3.8.4 forensic analysis for impacts already suffered, where a method drawn from AACE 29R-03 must follow ASCE 67-17 and ASCE 67-17 governs any conflict | Tied to the 10-day justification and to the change process |
| NAVFAC UFGS 01 32 17.00 20 §1.11.1 | A TIA accompanies each cost and time proposal for a proposed change | Narrative plus schedule form, with at least three native XER files — the fragnet, the pre-impact accepted or updated schedule statused to the impact start date, and the impacted schedule after insertion and rescheduling | With the proposal |
| Caltrans §8-1.02C(8)(b) | With each request to adjust contract time, and whenever a change may affect the critical or near-critical path | Insert the change into the accepted schedule whose data date is closest to and before the event, then compare the two scheduled completion dates | Within 5 business days of the proposed change, and within 10 days of a written request |
| VDOT Section 109.08(a), Category III §V | Time extensions route through the contract time provision; a Revised Baseline Progress Schedule follows the Engineer's written request | Two named forms — Prospective Schedule Impact Analysis, built by inserting a fragnet into a pre-impact copy, and Retrospective | Prospective analysis within 7 days of the Engineer's request and before the changed work proceeds; the Engineer responds to a revised baseline within 7 days |
| WVDOH §108.3.5, §108.3.4 | Any one of three conditions obliges the Engineer to request a revised Schedule, among them a delay greater than 10 calendar days on any critical activity | Not named as a method in §108.3. Where the Division revises work affecting sequence or duration, a written report follows under §108.6, which governs extensions of contract time | 7 calendar days to submit the revised Schedule; 7 calendar days for the written report |
| WisDOT §108.4.4.5, §108.4.4.6 | Three grounds on which the Engineer may require a revised schedule: completion targets delayed 14 calendar days on a calendar-day contract or 10 working days on a working-day contract; progress differing significantly from the current schedule; or a change order that adds, deletes or revises activities and changes the work sequence | Not named as an analysis. §108.4.4.6 requires documentation including schedule updates in support of a time extension request | Revised schedule within 10 business days |
| NYSDOT Item 639 | A Recovery Schedule where work slips ten percent or more beyond the required contract or milestone duration | A time impact analysis is a defined term in the specification and is required with any request to extend contract time | Not established from the material read |
| MnDOT §1803.3B.6, §1806 | An Impact Schedule quantifies a contemporaneous or prospective impact and establishes the need for a milestone extension | §1806 names the methods: prospective delays to AACE International RP 52R-06, delays already suffered to the MIP 3.4 approach of AACE International RP 29R-03 | Update cycle under Table 1803.3-2: data date the 15th, submission 4 business days later, Department review inside 7 business days, resubmission inside 3 |
| NJDOT 108.11.01.C | On an excusable delay the Contractor gives notice; when the extent of the impact can be determined, a request for a time extension follows | A Time Impact Evaluation Form together with a CPM fragnet showing logic revisions, duration changes, and new activities with their predecessors and successors | Failing to give the notice, or to provide the evaluation, waives the claim to more contract time |
| MDOT SHA §109.03.04, §109.03.04.01 | A request goes in separately from the update narrative | An extension of the Substantial Completion Date or of an Incentive/Disincentive Date rests on the calendar days of impact as determined by a Time Impact Analysis the Contractor submits; §109.01.01 defines the method as prospective | Administration responds to a monthly submission within 20 days; the revision route runs where an update calculates Substantial Completion more than 30 days past the contract date |
| SCDOT | Not stated in the provision read | No named method and no fragnet requirement were read. The schedule is stated to be a basis for evaluating requests for additional contract time | Not established |
| ADOT §104.03, §108.08 | A Request for Extension of Contract Time, with a revised schedule and supporting data | No named method and no fragnet requirement were read | Not established. §108.08 will not consider an extension unless the affected work is a controlling item or becomes one |
Read down the "analysis required" column and the pattern is not that the agencies disagree about delay analysis. It is that half of them prescribe a method by name and half say nothing at all — and for the half that say nothing, which method governs is a contract question that the scheduling specification does not settle. The DOT comparison sets the same twelve documents side by side across every other requirement.
What a time impact analysis has to contain, where a specification says so
The most specific list among the documents read is NAVFAC's, and it is quotable. UFGS 01 32 17.00 20 §1.11.1 requires the narrative to define the scope and conditions of the change; give the start and finish dates of the impact to the longest path; identify the accepted schedule it works from and any changes made to it; name the predecessor and successor activities to the impact period; name the responsible party; and describe how the impact originated. It then requires at least three native XER files, and for a claimed as-built delay it requires the inserted-fragnet method to be modified to account for events known to have occurred after the data date of the update used, with the impact on the longest path determined for each following update period. On apportionment, §1.11.1(d):
All TIAs must include any mitigation, and must determine the apportionment of the overall delay assignable to each individual delay. Apportionment must provide identification of delay type and classification of delay by compensable and non-compensable events.
Note what that clause does: it makes the classification a required content of the submission, supplied by the submitting party, and reserves the determination to the reviewing authority. That division is exactly the one this tool keeps.
Prospective and retrospective
The two postures share a mechanic and almost nothing else.
A prospective analysis is run while the job is live, days after the event, to support a contemporaneous request. AACE RP 52R-06 is the recommended practice the federal and Minnesota specifications name for it. Its base schedule is the last owner-reviewed update statused before the delay — not the baseline — it declines to analyse concurrency at all, and hindsight about the base is forbidden.
A retrospective analysis is run after the fact, over the record of what happened. AACE RP 29R-03's nine method implementation protocols are the taxonomy for it, and UFGS 01 32 01.00 10 §3.8.4 routes retrospective work to them while subordinating them to ASCE 67-17 where the two conflict.
The same technique in the wrong posture is a different analysis wearing its name, and a prospective analysis presented years later as though it had been contemporaneous is the first thing the other side will take apart. Methods owns the detail — all nine protocols, the eight steps of the prospective TIA and who decides each of them, and a table for choosing between them. The delay method comparison is the shorter version. Neither is restated here.
What this project's tool does, and what it refuses
It imports the schedule files, computes the dates and the floats, and reports. Specifically, on this subject:
- It computes the network arithmetic the gate turns on — early and late dates, total and free float, and the longest path — so the question "does this reach the contract completion date" has a computed answer rather than an asserted one.
- It checks the submission against the clauses of the specification you name and reports what each clause asks and what the imported file contains. Where a clause needs a fact the schedule does not carry, it abstains and names the input, rather than scoring the absence as a pass or a failure.
- It runs a prospective TIA under RP 52R-06 step by step, recording for each step what it did, what it assumed, and whether the tool or a person decided it — including the standard's own zero-duration correctness gate, which a fragnet must clear before the analysis proceeds.
- It refuses to decide entitlement. Whether a delay is excusable, whether it is compensable, whose it was, and what any of it is worth are not outputs. The party responsible for a delay period is an input a person supplies and is never inferred; where it is unknown, "undetermined" is a real answer that keeps the period out of every pairing and lists it as an open question.
- It decides no submission. Whether a schedule or a request is acceptable is the reviewing authority's determination. This is a tool, not an opinion.
What it does lists the commands and says which of them need a file you write. Limitations records what it does not do.
Related
- Concurrent delay — the authority map, and the four readings this tool reports without choosing one
- Acceleration and disruption — including pacing, and the notice conflict
- Methods — the nine protocols and the prospective TIA
- Float ownership — what stands in front of the gate
- DOT scheduling requirements — the twelve specifications compared
- UFGS 01 32 01.00 10 — §3.8, quoted clause by clause
- Standards crosswalk — which document says what
Source: web/pages/extension-of-time.md. Source commit date: 2026-09-11.