WSDOT CPM scheduling requirements: Standard Specifications 1-08.3
The Washington State Department of Transportation puts its scheduling requirement at 1-08.3, Progress Schedule, of the Standard Specifications for Road, Bridge, and Municipal Construction, M 41-10. The copy read here is the 2027 edition — the running head prints that year on every page of the division, and it is the year used throughout this page. The subsections are 1-08.3(1) through 1-08.3(5), with 1-08.3(4) vacant.
Two things set this specification apart from the others compared on this site. Its schedule updates are event-driven rather than periodic: there is no monthly cycle, and an update falls due when one of four named things happens. And the progress schedule is a paid lump-sum bid item, so the requirement appears in the Proposal and the schedule type is selected there.
What 1-08.3 requires
| Requirement | What the 2027 Standard Specifications state | Clause |
|---|---|---|
| Scheduling software | No product mandated, but a format is. Whatever software is used, the schedule data is supplied to the Engineer in a format compatible with Primavera Project Manager Enterprise, and each preliminary, progress or update submittal comes with an electronic copy carrying an .XER or .XML extension. Each submittal needs a unique file name and date identifier |
1-08.3(2)B |
| Schedule type | Three. Type A where the Proposal includes no progress schedule item; Type B or Type C where the Proposal provides for one. Type A may be CPM, bar chart or another standard format; Type B is CPM by the precedence diagramming method; Type C is Type B plus further content | 1-08.3(1), 1-08.3(2)A–C |
| First schedule due | Type A: no later than 10 calendar days after the Contract is executed, or another mutually agreed time. Type B and Type C: a preliminary progress schedule at the same 10 calendar days, which may be limited to the activities falling in the first 60 working days and must show the critical path; the complete schedule for the whole project no later than 30 calendar days after execution | 1-08.3(2)A, (2)B, (2)D |
| Agency review | 15 calendar days for the Engineer to evaluate and either accept the schedule or return it for corrections. This applies to Type A and to the Type B progress schedule alike | 1-08.3(2)A, (2)B |
| Update frequency | Event-driven, not periodic. The Engineer may request an update where the project has had a change affecting the critical path, where the sequence of work departs from the accepted schedule, where the project is significantly delayed, or where a time extension has been granted. The update is due within 15 calendar days of a written request, or where another contract provision requires one | 1-08.3(3) |
| "Significant" defined | Defined, and the threshold is the greater of two figures: 10 working days, or 10 percent of original contract time | 1-08.3(3) |
| Look-ahead | Every week that work will be performed, a look-ahead covering the Contractor's and all subcontractors' proposed activities for the next three weeks or another agreed duration, with descriptions, durations, sequence and planned hours. Due by the midpoint of the week preceding the scheduled work, or another agreed time. It may be a network schedule, bar chart or other standard format | 1-08.3(2)E |
| Narrative | Required in two places rather than generally. Where multiple calendars are applied, a written narrative describing the purpose of each. On Type C, fixed constraints are identified on the activity listing and supplemented with a written narrative explaining why each constraint exists | 1-08.3(2)B, (2)C |
| Recovery or revised schedule trigger | No recovery-schedule clause was read. The four update triggers at 1-08.3(3) carry the function; where a submitted schedule does not provide the required information the Engineer returns it for correction and resubmittal | 1-08.3(2), (3) |
| Time impact analysis | Not stated in this provision. No named method and no fragnet requirement were read. Unresolved requests for time extensions are instead reflected in the update by assuming that no extension will be granted, and by showing the consequent effects on the following activities within the currently authorised time | 1-08.3(3) |
| Float ownership | Total float belongs to the project and is not for the exclusive benefit of either party | 1-08.3(2), item 7 |
| Activity durations | No numeric cap. Durations are shown in working days, are to be reasonable for the work intended, and are defined in enough detail that progress on individual activities can be evaluated on a daily basis | 1-08.3(2), items 3–5 |
| Calendars | Project calendars only — not global calendars and not resource calendars. Multiple calendars are permitted with the narrative described above | 1-08.3(2)B |
| Restraints | Permitted, but not so as to alter either the network's logic or the critical path | 1-08.3(2)B |
| Per-activity data | Type B lists thirteen items, among them early start and early finish, late start and late finish, total float and free float for every activity, predecessors and successors, the critical path, the data date and the physical completion date | 1-08.3(2)B |
| Scheduling practice | Scheduling terms and practices conform to the standards in Construction Planning and Scheduling, second edition, an Associated General Contractors of America publication | 1-08.3(2) |
| Payment | A lump sum bid item, "Type ____ Progress Schedule". Type A schedules and weekly look-aheads are incidental. Updates needed because of the Contractor's own operations are not paid; updates caused by the Contracting Agency's actions are paid under 1-09.4 | 1-08.3(5) |
Updates that fall due on an event, not on a calendar
Every other state specification compared on this site sets a periodic update cycle — monthly in most, two-monthly in one. WSDOT sets none. 1-08.3(3) lists four occurrences instead, and the Engineer may request an update when one of them happens: a change affecting the critical path, a departure from the accepted sequence of work, significant delay, or a granted extension of contract time. The clock then runs 15 calendar days from the written request.
So "is this project's schedule current" is not a date calculation on this specification. It depends on whether one of the four events happened and whether a request followed. Two of the four — a critical-path change and a sequence change — are things two schedule files can evidence when compared; the other two are facts about the contract that no file carries.
The third trigger is the one with a number attached, and the number is unusual in being the maximum of two tests rather than a single threshold: a significant delay means the greater of 10 working days and 10 percent of the original contract time. On a short contract the 10 working days binds; on a long one the percentage does. A 400-working-day contract reaches the threshold at 40 working days, not at 10.
This project compares two schedule files and reports what moved — dates, durations, logic and the longest path. Whether a movement amounts to a significant delay under this clause, and whether the Engineer requested an update, are not facts the files carry.
Project calendars only, and what that rules out
1-08.3(2)B states that all calendars used are created as project calendars, not global and not resource calendars. That is a narrow-looking sentence with a wide effect, and it is one of the few requirements on this page that an imported file settles directly.
In a Primavera-family export, a calendar carries a type. A global calendar is shared across the database and editable outside the project; a resource calendar attaches to a resource rather than to the work. A project calendar belongs to the project it is exported with, so the file that arrives contains the calendar that produced the dates in it. The rule is therefore about reproducibility as much as about tidiness: a schedule built on global calendars can be recalculated to different dates in a different database with no change to its own activities.
The narrative required where multiple calendars are applied is the same instinct aimed at the reader rather than at the recalculation. Calendars in an XER file describes what the export records about calendar type and working time.
Type C adds the things a reviewer cannot infer
Type C carries everything in Type B and adds ten items, and the list is worth reading as a set. It calls for a time-scaled logic diagram; activities for traffic detours and closures; milestones for delivery of agency-furnished materials and activities for agency-furnished traffic control resources, where either exists; activities for fabricating materials with more than 90 calendar days of lead time; milestones for interim or stage completion; activities for scheduled outages on illumination, ITS, traffic signal and other electrical systems; nighttime activities coded as such; activities for every submittal needing agency review, including the allowable review duration; and fixed constraints identified on the activity listing with a narrative explaining each.
Most of these are agency-side or externally-paced work, or work whose timing is constrained by something other than the Contractor's own production — agency review durations, agency-furnished materials, long-lead fabrication and permitted outages all sit in that class. A network that omits them still calculates a completion date; it calculates one that assumes those durations are zero or unconstrained.
The constraint narrative is the item most directly checkable against a file: constraints are recorded in the export with their type and date, so the set needing an explanation is enumerable. Whether each explanation is adequate is determined by the reviewing authority. Schedule constraints covers the types.
What this page does not tell you
- It does not tell you which clauses govern your project. The schedule type — A, B or C — follows from what the Proposal contains, and the incorporated contract documents, including every special provision and any amendment to the standard specifications, are what apply. An agency's name alone does not establish which clauses bind.
- Only Division 1-08.3 was read. The AGC scheduling text that 1-08.3(2) incorporates by reference was not obtained, so any requirement carried only there is not established here. Provisions elsewhere in the book bearing on contract time or claims are likewise outside what this page establishes.
- The edition year is taken from the document itself. The running head prints 2027 throughout the division read. Whether a different edition governs a particular contract is a fact about that contract.
- There is no rule pack behind this page. It rests on a reading of the specification text, with each requirement cited to the clause it came from. Nothing in this engine checks a schedule against these clauses today.
- This project computes and reports; it does not decide submissions. Whether a schedule is acceptable, and whether more contract time is due, are determined by the reviewing authority.
Related pages
- How state DOT scheduling specifications compare.
- Neighbouring readings: TxDOT · CDOT · PennDOT.
- Float ownership across specifications · schedule constraints · lags and leads.
- The XER format and calendars in an XER file.
- Glossary — precedence diagramming, restraint, free float.
- What the engine does and its limitations.
- The conformance rule catalogue and the standards map.
Source: web/pages/wsdot-scheduling.md. Source commit date: 2026-09-11.