DOT and federal CPM scheduling requirements, compared

Sixteen public-agency scheduling documents, read end to end, put side by side: fourteen state transportation agencies and two federal Division 01 specifications. Each row below is a clause somebody read, with the section number to check it against.

What this covers, and what it does not

Sixteen documents compared. Four more states read and reported below as findings rather than as pages. Thirty-two states not read. This page compares Arizona, California, Colorado, Maryland, Minnesota, New Jersey, New York, Pennsylvania, South Carolina, Texas, Virginia, Washington, Wisconsin and West Virginia, plus the two Unified Facilities Guide Specifications sections that govern federal construction scheduling. Georgia, Florida, Ohio and Illinois were read and are summarised in the section headed Four states read that do not require a CPM schedule; they have no page of their own because the requirement read was short enough to state in a paragraph. Every other state's requirement is absent — not summarised, not inferred from a neighbour, not filled in from an industry norm. Where a document says nothing on a subject, the cell says so.

Nine of the sixteen rest on a reading rather than on a rule pack. Arizona, Colorado, Maryland, Minnesota, New Jersey, Pennsylvania, South Carolina, Texas and Washington were read for this comparison; they have no implemented rule set behind them, so every requirement stated for them cites the clause it was read from, and anything that could not be established from the text is marked as not established rather than filled in. The agency column of each table below marks which basis a row rests on.

That gap is deliberate. The best public comparisons of US DOT scheduling requirements are a 2015 university thesis and an eleven-state 2024 study, both fixed PDFs that were true on the day they were published. A fifty-state table nobody re-checks becomes one of those within two years. This page is narrow so that it can stay current, and it is dated so you can tell when it stopped being.

Two editions to watch. Caltrans cuts over to its 2026 Standard Specifications on 19 October 2026; a departmental memo dated 20 July 2026 states that the 2025 edition will not be supported after 16 October 2026, and the 2026 text is not yet public. The Caltrans rows below are read from the 2025 edition. And WisDOT's current book is the 2025 Standard Specifications, effective with the November 2024 letting; the §108.4 clauses cited below were read in the 2022 edition, so treat their clause numbers as needing a re-check against the current book.

And two editions whose currency was not established. Arizona's book read here is the 2021 edition and South Carolina's supplemental specification is dated 4 November 2013; on the retrieval that obtained them, neither agency's specifications index resolved, so whether a later edition exists is unconfirmed in both cases. They are reported as read, with the edition stated, and not as current.

One row was corrected on 11 September 2026. An earlier version of this page read only MDOT SHA's GP-8.04 and reported Maryland as stating no method. The same book's Section 109, Project Schedule is the scheduling specification and has now been read in full; the Maryland rows and the Maryland section below are rebuilt on it, and Maryland has a page of its own.

Readings taken: 1–11 September 2026.

The comparison, part one: document, software, first schedule, updates

The comparison, part two: narrative, revision triggers, time impact, float

The same sixteen documents, in the same order. This table is split from the one above so that each row stays readable when read aloud; the agency column is the join between them.

Which of these name Primavera P6

Six of the sixteen mandate it outright: Caltrans (§8-1.02C(3), the latest version "or equal"), NYSDOT (on the Department's own servers, with the State supplying the software), VDOT (P6 and .xer, plus seven named Schedule Options values), WVDOH (P6 version 6.0 or higher), SCDOT (Primavera Project Management 5.0 or Primavera Contractor 5.0 at minimum, exported so the Department's version will read it) and NAVFAC (P6 by name, with required settings and screenshot submittals).

Two name no product at all. WisDOT's §108.4 asks for computerized scheduling software and for the software used to be identified. ADOT's §108.03 asks only for critical path method format.

PennDOT names a different product, and it is the finding that breaks the pattern — see the section on Asta Powerproject below.

CDOT names two and lets the Contractor pick one, then fixes it. 108.03(b) requires either Microsoft Project or Primavera, with the choice notified in writing before or at the preconstruction conference and unchangeable after the first schedule submittal. Where Primavera is the choice, the same clause mandates that the schedule be calculated using the Retained Logic option. That is the only clause among the sixteen that reaches into a scheduling tool's calculation behaviour outside a list of named settings, and it is a mandate on how the dates were produced rather than on what produced them. P6 schedule options covers what the setting changes.

TxDOT and WSDOT name P6 without mandating it, in two different registers. TxDOT's 5.5.2 asks for the scheduling software's native file in a format the Engineer accepts and then states that a P6 .xer will be accepted in every case — a safe harbour rather than a requirement. WSDOT's 1-08.3(2)B does not name a product at all and instead requires the schedule data to reach the Engineer in a format compatible with Primavera Project Manager Enterprise, as an .XER or .XML file with a unique name and date identifier per submittal.

MnDOT, NJDOT and MDOT SHA are in between, in three different ways. MnDOT names P6 as the software the Department uses and permits others, putting the cost of conversion discrepancies on the Contractor — a mandate on the outcome rather than on the tool. NJDOT names no product but requires the submission in XER format, built on the agency's own coding manual and template. MDOT SHA's §109.03.01.02 names no product either, and states the outcome twice over: the software has to export .xer that the Administration's reviewer can open in its version of Primavera, and the network is built by the precedence diagramming method with retained logic. A file format requirement and a product requirement are not the same clause, and only one of them is decidable from the file: what wrote it and in what format is declared in the export; whether the Contractor held a licence for a named version is not.

UFGS is the interesting case. §2.1.2.2 expressly permits software other than P6 — at the cost of providing the Government two licences, two stand-alone computers and training for two Government employees. Yet §3.12 is titled Primavera P6 Mandatory Requirements and lists eleven settings, a to k, that every submission must carry. A contractor is free to choose, and the clause structure makes the choice consequential. The UFGS page covers all eleven.

How float ownership differs

This is the sharpest divergence on the page, and it is not a matter of degree.

Twelve documents say some version of shared: VDOT's II.7 (a project property shared amongst all activities, not for either party's exclusive use), WisDOT's §108.4.4.3(3), WVDOH's §108.3.1 and MDOT SHA's §109.01.01 (a shared commodity, full use by either party until depleted), SCDOT's Float heading (not for the exclusive use or benefit of either party, with negative float barred from the original baseline), MnDOT's §1803.3A.5, NJDOT's 153.03.01, TxDOT's 5.4 and PennDOT's 689.1 (each using the phrase shared commodity), CDOT's 108.03(b) (a project resource available to both until depleted), WSDOT's 1-08.3(2) item 7 (belonging to the project, not for either party's exclusive benefit), and NAVFAC's §1.12, which says the same of Project Float specifically. UFGS §3.10 states it differently again: float belongs to the Project, and is available for Contractor and Government use.

Three of the sixteen put the allocation inside a definition rather than in a clause of its own, which matters to anyone searching a book by heading. MDOT SHA's §109.01.01 is the allocation for the whole of Section 109, so a reader skimming its subsection headings will not find an ownership clause. PennDOT's 689.1 does the same: the sentence naming float a shared commodity is the second half of the definition of float itself, in the definitions list at the head of Section 689. TxDOT's 5.4 attaches it to the sentence defining total float in whole days, inside the clause on activity format.

MnDOT adds a dimension the others leave out: time. §1803.3A.5 calls float an expiring resource, and §1803.3D's weather and duration contingency becomes available float as the days pass unused — so contingency and float are the same substance at two moments rather than two separate allowances. §1803.3A.4 then names three ways of suppressing float and prohibits each: relationships with no real sequential content, a relationship forcing an activity to finish when it could have run past its successor, and a duration stretched beyond the work.

Two of the sixteen state no ownership rule at all: ADOT's Section 108 contains no allocation clause, and NYSDOT states none in the paragraphs read. Absent is not the same as shared, and neither is reported here as either.

Caltrans is the outlier, and it is structural rather than doctrinal. §8-1.02C(8)(c) makes Department-owned float a resource for the exclusive use of the Department, accrued by the Engineer and logged in the narrative report; the same section makes early completion time a resource for the Contractor's exclusive use. §8-1.02C(2)(12) then requires Department-owned float to appear in the schedule as the predecessor activity to the scheduled completion date. Two named ownership classes, one of them an activity you can point at in the file.

NYSDOT states no ownership rule in the paragraphs read, though its definition of float suppression assumes total float is shared between the parties.

Which require a time impact analysis

Eleven of the sixteen require an analysis of the impact on time behind a request for more of it, whether or not they name a method for it. Caltrans requires one with each request to adjust Contract time, or whenever a change may affect the critical path, and monthly for a Change Order with deferred time. NYSDOT requires one with any time extension request. VDOT requires two distinct forms, prospective and retrospective. NJDOT requires a Time Impact Evaluation on a stated form, with a CPM fragnet, and waives the claim to more contract time where the notice or the evaluation does not arrive. MnDOT requires an Impact Schedule. MDOT SHA makes it the basis of the extension itself — §109.03.04.01 measures the extension by the calendar days of impact a Contractor-submitted Time Impact Analysis determines, and §109.01.01 defines the method as prospective. UFGS splits prospective from retrospective. NAVFAC requires one with each cost and time proposal. CDOT requires one within 30 days of a written delay notice that is itself due within 7 days. TxDOT prescribes a four-step analysis when directed. PennDOT requires no named analysis but a prescribed pair of schedules.

Three name their methods, and they name the same two recommended practices. UFGS §3.8.3 and §3.8.4 send prospective analysis to AACE 52R-06 and retrospective analysis to a method from AACE 29R-03, with ASCE 67-17 governing a conflict. MnDOT's §1806 sends prospective delay to 52R-06 and delay already suffered to the MIP 3.4 approach within 29R-03, and states which accepted schedule the calculation starts from — the most recent one accepted before the event. CDOT's 108.08(d) does the same split — 52R-06 for forward-looking impacts, 29R-03 for impacts already absorbed into the schedule — and adds a third route, another method the Engineer approves, with an explanation of the choice required in every case. CDOT attaches two conditions to the schedule the analysis rests on rather than to the analysis: the supporting schedule must carry a data date within 30 days before the alleged delay, and having no current approved schedule precludes an extension, which turns the monthly update obligation into a precondition for the delay remedy. The CDOT page sets that out; how delay analysis methods differ compares the families, and the methods this project uses states what it computes.

Two prescribe a shape instead of citing a method, and the two shapes are different. TxDOT's 5.5.4 sets four steps — status before the impact, prediction of its effect, tracking during it, status after it ends — and makes steps 1, 3 and 4 the ones that must be complete before an extension is considered, with step 4 due within 15 calendar days of the effects ending. PennDOT's 108.06(a) instead asks for a pair of schedules with each request: whichever accepted schedule stood before the impact, and a post-impact schedule showing the effect on the Required Completion Date or a Milestone Date. One describes a procedure over time; the other describes two artefacts.

Five require no analysis of the impact at all. WisDOT asks for documentation, including schedule updates, to support a time extension request. WVDOH's §108.3 is silent and routes time extensions to §108.6. SCDOT makes the schedule a stated basis for evaluating requests for more time, and requires supporting documentation to be included and referenced in the schedule, but prescribes no form. ADOT requires a revised schedule with the request and gates the whole question at §108.08 — an extension is not considered unless the affected work is a controlling item, or becomes one — without saying how that is to be demonstrated. WSDOT's 1-08.3 names none either, and instead makes the update carry the open question: an unresolved request for a time extension is shown assuming no extension will be granted, with the effects on the following activities inside the currently authorised time.

Pennsylvania standardises on Asta Powerproject, not Primavera

Publication 408's §689.2 names Asta Powerproject, from Elecosoft, as what the Department has settled on for both scheduling and project management. The CPM Schedule is produced in Asta Powerproject (.pp) or in one of six listed compatible formats — .mpp, .xml, .xer, .p3b, .dir, .stx — and where a compatible format is used, the native file is converted to .pp through the PennDOT Construction template defined in Publication 615, checked one to one against the native file, and uploaded through the PennDOT Project Collaboration Center. The accepted .pp file is then the governing schedule of record and is loaded into Asta Vision.

Of the sixteen documents on this page, that is the only one naming a scheduling product other than Primavera as the standard. Six name Primavera outright, two name nothing, CDOT names Primavera or Microsoft Project, and the remainder specify a format or an outcome instead of a tool. Pennsylvania is a category of one.

The finding matters beyond Pennsylvania because of what it falsifies. It is easy to read a run of P6-naming specifications and conclude that Primavera is the assumed tool of US public-agency scheduling, and to build on that assumption — a reader assessing a specification they have not read, a tool supporting one format, a comparison written from a sample. One state in this sample standardises elsewhere, and .xer appears in its list as an import format rather than as the submission format. A schedule submitted to PennDOT is a .pp file.

This project reads .xer and P6 XML and does not read .pp, which is stated plainly on the schedule formats page and in the limitations. Where an agency's submission format is one this project does not read, the honest answer is that it cannot check that submission, and that is the answer here. The PennDOT page reads Section 689 clause by clause.

Texas is the only one of the sixteen asserting copyright

TxDOT's 2024 Standard Specifications carries a copyright notice on its title page reserving all rights in the book, and the book is sold. It is the only one of the sixteen on which such a notice has been found. The title pages and the full text of the WSDOT, PennDOT and CDOT books were searched on the retrieval that obtained them and none carried one; no notice has been recorded for the state documents read earlier either, though absence of a record is weaker evidence than a search.

Absence of a notice is a finding, not a permission. None of the state documents is a US Government work, none states a licence, and a specification published for use on an agency's contracts is published for that purpose rather than for republication. So the same discipline is applied to all sixteen on this site: requirements are characterised in this project's own words, cited to the clause, and not reproduced. The Texas copyright notice changes nothing about how this page is written; it is recorded because it is a fact about the document that a reader going to find the source should know before going.

The related question — what this project may republish from the standards it implements — is settled separately and more strictly for AACE International recommended practices, which are not quoted at all here. See the standards map.

Four states read that do not require a CPM schedule

These four were read and are reported as findings rather than as pages, because what each document states is short enough to state here. Each entry describes the document that was read. Whether a project-specific provision imposes more is a fact about that contract, and nothing below is a judgement about any agency's requirement.

Georgia — the CPM requirement is not published as a standing statewide document. The 2021 Standard Specifications, Construction of Transportation Systems, as modified by the 2024 Edition Supplemental Specifications (first use April 2024), require a progress schedule furnished to the Engineer for approval immediately after the Notice to Proceed is received. Unless otherwise specified, it is prepared on Department forms, or an acceptable critical path schedule is used, to establish which items of work are controlling and for checking progress. The schedule is not required on resurfacing projects. Where the Contractor's operations are materially affected by plan or quantity changes, or where the approved schedule has not been kept to, a revised schedule follows within 10 days of the Engineer's request. Payments are not made while a schedule or a revised schedule is outstanding. Section 108's own text refers to the progress schedule "as provided in Subsection 108.03" and notes that a Special Provision may exempt it. On the retrieval that obtained these two books, the agency's specifications index linked only the two books, and two candidate URLs for a standing Special Provision 108 did not resolve. So Georgia's CPM requirements, where a project carries them, live in a project-specific special provision, and they were not available as a statewide document to read.

Florida — a Contract Schedule, and CPM is never required. The FY 2026-27 Standard Specifications for Road and Bridge Construction, §8-3.2, require a Contract Schedule inside 21 calendar days of Contract award, or at the preconstruction conference, whichever is earlier, with the Engineer responding within 15 calendar days. The schedule shows activities in enough detail to demonstrate a workable plan within Contract Time, with the order and interdependence of activities, a beginning work date and a duration for each, procurement, fabrication and delivery activities, review time for shop drawings and submittals, and milestone activities where the contract requires them; on a multi-phase project each phase is identified and activities do not span more than one. A concise written working plan accompanies it. An updated schedule is submitted only where the planned order or duration of an activity changes significantly, with a 7-calendar-day agency response; an inadequate schedule is returned and a corrected one follows within 15 calendar days. No software is named, no scheduling method is prescribed, no update cycle is set, and float is not allocated anywhere in the clause.

Ohio — a bar chart, with real rules attached. The 2023 Construction and Material Specifications, 108.03.A, require a bar chart progress schedule furnished to the District Construction Engineer at or before the preconstruction meeting, with the Engineer accepting it or providing comments within 14 calendar days and clarification due within 10 days of a written request; estimates are withheld until it is accepted. It is a working-day schedule carrying eleven administrative identifiers, reflecting phasing, maintenance of traffic, interim completion dates and other contract milestones, with unambiguous activity descriptions. Activity durations do not exceed 20 working days without the Engineer's approval, and maintenance of traffic, erosion control and similar items may not be represented as single activities extending to the Completion Date — they are broken into components to meet the duration rule. An updated schedule is submitted when ordered, and the Engineer may order one where progress has fallen more than 14 calendar days behind the latest accepted schedule; a recovery schedule is required where the schedule projects a finish more than 14 calendar days past the Completion Date. The early-completion rule is the distinctive one: where an Early Completion Schedule is accepted, the Engineer initiates a change order amending the Completion Date to the finish date it shows, and every contract provision keyed to the Completion Date — incentives, disincentives, excusable and compensable delays, liquidated damages — is then measured against the amended date. The Contractor may decline to execute that change order and in doing so waives rights to delay damages in meeting the projected early date.

Illinois — one page, and a production rate. Article 108.02 of the 2022 Standard Specifications for Road and Bridge Construction requires, after award and before starting work, a satisfactory progress schedule or critical path schedule showing the proposed sequence of work and how the various items are to be completed within the working days or by the completion date the contract sets. It is the basis for establishing the controlling item — defined as the item that must be completed, partially or completely, to permit progress to continue — and the Contractor is responsible for showing the intended rate of production for each controlling item while that item is controlling. Where working days charged exceed the schedule's proposed working days by ten, or where progress on a completion-date contract falls 14 calendar days behind, the Engineer selects the controlling item for charging or checking purposes, and continues to do so until a satisfactory revised schedule arrives. No payment is made until a schedule has been submitted for approval. No software is named, no update frequency is set, no float rule appears, and no analysis of time impact is prescribed. The article read here is the 2022 book's; the current supplemental specifications were not obtained, so whether they modify Article 108.02 is not established.

Maryland: the method requirement is not where the search box takes you

Maryland's rows above cite Section 109, Project Schedule, of MDOT SHA's 2026 Standard Specifications for Construction and Materials. The reason this section exists is that the same book carries a second scheduling clause, earlier and easier to find, which states almost none of the requirement — and reading it alone gives the wrong answer about what Maryland asks for.

GP-8.04 Progress Schedule sits in the General Provisions, under prosecution and progress. It requires a progress schedule within 30 days after Notice to Proceed showing the proposed order of work and the time the work needs; revised schedules as the procurement officer directs; withholding of progress payment estimates or termination for default where it does not arrive; and supplemental progress schedules where the procurement officer judges the Contractor to be well behind. For Administration Contracts it points onward to TC-5.02, which was not read for this page. It names no method, no software, no file format, no float rule and no analysis for a time extension.

Section 109 is the scheduling specification, and §109.01 points back at GP-8.04. It classifies projects by complexity and cost into Type A, a bar chart schedule; Type B, a CPM schedule for typical projects; and Type C, a CPM schedule for complex projects — with Type B applying unless the Invitation for Bids designates otherwise, so CPM is where a Maryland project lands by default. It requires .xer export to a compatible version of the Administration's Primavera, the precedence diagramming method and retained logic, an initial schedule within 20 days of Notice of Award, monthly updates, a written narrative with every submittal, a Time Impact Analysis behind every extension request, and shared float. The cross-reference to GP-8.04 covers the submission provisions and the consequences of not keeping to the schedule.

So the two clauses are complementary rather than alternative: GP-8.04 carries the enforcement, Section 109 carries the specification, and neither is the whole requirement. The general form is worth carrying to the other documents on this page — a general-provisions clause about progress is not necessarily an agency's scheduling requirement, and where one exists, look for the specification section it refers to. The MDOT SHA page reads Section 109 subsection by subsection. Nothing here establishes what a particular Maryland contract requires; the IFB and the incorporated documents do.

A requirement is only a requirement where the contract incorporates it

None of these documents governs a project because of the agency's name on it. A Caltrans clause binds where the Bid Item List carries a Level 2 CPM schedule bid item; a VDOT Category III provision binds where that provision — rather than Category I or II — is the one the contract carries, and the clause numbering shifts between them; a UFGS section binds where the contract incorporates that section rather than its NAVFAC sibling, which contradicts it in plain text on out-of-sequence progress. A South Carolina provision binds at the level — 1, 2 or 3 — that the special provision names, and the three are not variations on one requirement. Two of the twelve documents read here are not contract terms at all: NYSDOT's Best Practices manual says in its own first page that it is guidance and not official policy, and WVDOH's review manual is staff training material.

So which clauses govern is a fact about the contract documents, and somebody has to state it. Naming the agency does not settle it.

Where this project's reading lives

Seven of the twelve documents above are implemented as rule packs — the Caltrans, NYSDOT, VDOT, WisDOT and WVDOH readings, plus the two UFGS sections. A rule pack checks an imported schedule against the document's clauses, cites the clause in every finding, and refuses to decide where the schedule does not carry the input the clause needs — see how conformance rules are organised and what the rules depend on. Where two documents disagree on one metric, the disagreement is recorded rather than resolved; the standards crosswalk shows the overlaps.

The other five are readings only. Arizona, Minnesota, New Jersey, South Carolina and Maryland have no rule pack behind them, so nothing in this engine checks a schedule against their clauses today. Their pages state requirements with the clause cited and mark what could not be established, which is a different and weaker thing than a checked rule — and it is marked as such on each page rather than left to be inferred from the absence of a pack.

Per-agency detail, rule packs: Caltrans · NYSDOT · VDOT · WisDOT · WVDOH · UFGS 01 32 01.00 10.

Per-agency detail, readings: ADOT · MDOT SHA · MnDOT · NJDOT · SCDOT.

Related: the GAO Schedule Assessment Guide · the DCMA 14-point check · glossary · what this tool does · its limitations.

Source: web/pages/dot-scheduling.md. Source commit date: 2026-09-11.