MnDOT CPM scheduling requirements: 2020 Standard Specifications §1803
The Minnesota Department of Transportation states its scheduling requirements in the 2020 Standard Specifications for Construction, Volume 1, at §1803, Progress Schedules. The section is tiered: §1803.1 states what is true of every schedule, §1803.2 governs bar chart schedules, §1803.3 governs critical path method schedules, and §1803.4 covers temporary suspensions. Delay analysis lives next door, in §1806, Determination and Extension of Contract Time.
One citation caution before anything else. In the copy read here, the volume's table of contents lists progress schedules under a different number than the section heading printed in the body, and the body's own cross-references — to §1803.2, §1803.3, §1803.3B.2 and so on — are consistent with the body heading. This page cites §1803, as the section heading and the internal cross-references print it. If you are quoting a clause into correspondence, cite it by title as well as by number.
The CPM tier applies where the Contractor chooses to use CPM, or where the Department specifies that the work is to be scheduled that way. Where neither happens, §1803.2's bar chart requirements are the ones in force — and they are substantive in their own right, including a quantified monthly allowance for work days expected to be lost to weather.
What §1803 requires of a CPM schedule
| Requirement | What the 2020 Standard Specifications state | Clause |
|---|---|---|
| Scheduling software | Primavera P6 is named as the software the Department itself uses. Other software is permitted, with the Contractor carrying any discrepancies introduced by conversion. Submissions include a compressed .xer file. |
§1803.3A.1, §1803.3C.3 |
| Baseline deadline | Two gates rather than a day count. Acceptance of the first Preliminary Schedule is a condition of the first notice to proceed; acceptance of the Baseline Schedule is a condition of the second. Schedules submitted before the Baseline is accepted are treated as Preliminary. | §1803.3B.1, §1803.3B.2 |
| Update frequency | Monthly. Table 1803.3-2 sets the update data date at the 15th of each month, with the submission due four business days after the data date, Department review inside seven business days, and any resubmission inside three. | §1803.3B.3, Table 1803.3-2 |
| Narrative | Required with every submittal, with one list of contents for Baseline, Revised and Impact schedules and a second for Update schedules — including the reason and purpose of each constraint and the reason for each lag or lead. | §1803.3C.1 |
| Recovery or revised schedule trigger | A Revised Schedule is required where the Contractor intends to depart substantially from the current sequence or durations, at the Department's request (including to show how a missed milestone date is to be recovered, or where the actual work differs substantially from the schedule), or on a contract revision changing the planned sequence or the method of performance. | §1803.3B.5 |
| Time impact analysis | Yes, and the method is named. Impact Schedules quantify contemporaneous or prospective impacts and establish the need for a milestone time extension; §1806 directs prospective delays to AACE International Recommended Practice 52R-06 and delays that have already happened to the MIP 3.4 approach of AACE International Recommended Practice 29R-03. | §1803.3B.6, §1806 |
| Float ownership | Shared. Float is a commodity available to the project rather than to either party, and an expiring resource that absorbs changes and mitigates delay. Suppressing or sequestering float is prohibited, with three named examples. | §1803.3A.4, §1803.3A.5 |
| Activity durations | Expressed in working days, not more than 20 and not fewer than 5, unless the Engineer authorises otherwise. (The bar chart tier states a different band: one to 15 working days.) | §1803.3B.2, §1803.2B.1 |
| Logic completeness | Every activity carries at least one predecessor, except the first, and at least one successor, except the last. Lags and leads need the Engineer's agreement in advance and may be required to be replaced by an activity. | §1803.3B.2, §1803.3A.4 |
| Criticality share | Not more than 20 percent of activities critical, and not more than 30 percent near-critical, unless otherwise authorised. | §1803.3B.2 |
| File and settings conventions | No user-defined fields. Calendars at project level, not global or resource level; activity codes at project level, not global or EPS level. A submission file-naming convention is set out in Table 1803.3-1. | §1803.3A.2, §1803.3A.3 |
| Weather contingency | Contingency belongs in the calendars, not in activity durations. At least three calendars, and the calendar for each major weather-affected item of work carries a weather contingency of at least 15 percent, marked on weekdays only. | §1803.3D |
Two named percentages, and why they are unusual
Two of the rows above state a proportion rather than a count, and both are rare in this family of documents.
Criticality share. A cap of 20 percent critical and 30 percent near-critical describes the shape of the network rather than any one activity, and a reviewer cannot see it by scrolling: it needs the population counted and a near-critical band defined. Caltrans states a comparable cap with the two classes combined into one share; Minnesota separates them, making the near-critical band an object in its own right — and §1803.3C.2 then requires a Gantt chart devoted to it.
Weather contingency. At least 15 percent contingent non-working days in each weather-affected calendar, marked Monday to Friday only, is a floor on a calendar rather than on a schedule. It pairs with the instruction in the same subsection that durations contain the work and nothing else — no padding inside an activity, contingency in the calendar where it can be counted.
Both are decidable from a schedule file, and both need calendars read rather than just activities. What the engine reads from an XER states which calendar structures it handles and which it does not.
Delay analysis by named method
§1806 is the clearest statement of delay method in any of the state documents read for this site. It splits prospective from retrospective analysis and sends each to a named external Recommended Practice — 52R-06 for delays in the future, and the MIP 3.4 approach within 29R-03 for delays that have already occurred — and it states that the schedule relevant to a calculation is the most recent one accepted before the event, with a worked illustration of what that means when a change order lands mid-month.
That is worth noticing for a reason beyond Minnesota. Naming the method is what makes two analyses of the same delay comparable; leaving it unnamed is how two competent analysts reach different day counts and neither is wrong. Only one other document compared on this site names its methods this way, and it is federal rather than state.
This project does not perform delay analysis. It does not decide excusability, compensability or entitlement, and it does not determine the cause of a delay. What it does is compute a schedule's dates and float from the network as imported and report what the file states, which is the input such an analysis starts from. How the delay methods differ describes the distinction between the two families without applying either.
Float that expires, and float you are not allowed to hide
§1803.3A.5 describes float as available to the project rather than to either party, and adds a characterisation the other documents on this site mostly omit: that it is an expiring resource. Contingency identified under §1803.3D becomes available float as time passes and goes unused — so contingency and float are the same substance at different moments, a tidier account than most specifications give.
§1803.3A.4 then names three ways of suppressing float and prohibits each: relationships between activities with no real sequential connection, relationships forcing one activity to finish when it could have continued past its successor's start or finish, and durations stretched beyond what the work needs. It closes by denying compensation or time for delays that revised durations or logic would have avoided.
The first two are structural and a program can look for their signatures; the third is a judgement about the work, and this project does not make it. The engine reports what the network contains — relationships, lags, durations, calendars and the float that follows from them. Whether a duration is excessive is determined by the reviewing authority.
What this page does not tell you
- It does not tell you which clauses govern your project. The contract documents the contract incorporates — the edition of the standard specifications it names, plus every special provision — are what apply. An agency's name alone does not establish which clauses govern.
- It does not tell you which tier applies. §1803.2 and §1803.3 state different duration bands and different submission obligations. Which one binds turns on whether the contract specifies CPM, or the Contractor elects it.
- Section numbering should be confirmed. The copy read here shows a discrepancy between the volume's table of contents and the section heading in the body, described above.
- There is no rule pack behind this page. It rests on a reading of the specification text, with each requirement cited to the subsection it came from.
- This project computes and reports; it does not decide submissions. It states what the imported schedule contains and checks it against the clauses cited. Acceptance is determined by the reviewing authority.
Related pages
- How state DOT scheduling specifications compare.
- Neighbouring readings: ADOT · NJDOT · SCDOT.
- UFGS scheduling requirements, the other document that names its delay-analysis methods.
- Calendars in an XER file and the XER format.
- Comparing delay methods · glossary.
- What the engine does and its limitations.
- The conformance rule catalogue and the standards map.
Source: web/pages/mndot-scheduling.md. Source commit date: 2026-09-11.