MDOT (Michigan) CPM scheduling requirements: subsection 108.05.A and special provision 20SP-108B-01
Michigan splits its scheduling requirements across two documents, and reading only the first gives a badly incomplete picture — so the relationship comes first on this page.
The book. The 2020 Standard Specifications for Construction carries subsection 108.05, "Prosecution and Progress", with 108.05.A, "Progress Schedule", inside it. That clause governs a progress schedule, which may be produced by a diagramming method, as a bar chart, or on MDOT Form 1130. On the critical path method it says one thing only: where the contract requires it, the Contractor submits a critical path schedule using the critical path method, and on approval that schedule replaces the progress schedule. It attaches no content requirements to the CPM schedule at all — no software, no deadlines, no float clause, no analysis method.
The special provision. Every CPM requirement lives in the Special Provision for Critical Path Method Schedule, 20SP-108B-01, approved by the Michigan Review Board on 26 February 2020 and by FHWA on 2 March 2020. The Department applies it where the progress clause calls for CPM and on time-incentive projects. Six pages long, it names the software, sets a submittal timetable as a table, fixes the scheduling options, states the float rule, and prescribes two delay analysis methods.
A reader who finds 108.05 and stops will conclude Michigan has almost no CPM requirements. The opposite is true; the requirements are simply not in the book. That is a fact about how the agency organises its documents, and the practical consequence is that the governing text for any particular Michigan project is whichever documents that contract incorporates — the book alone, or the book plus the special provision.
No copyright notice was found on either document.
What 108.05.A requires of the progress schedule
| Requirement | What the 2020 Standard Specifications state | Clause |
|---|---|---|
| Form | A diagramming method, a bar chart, or MDOT Form 1130, unless the contract requires otherwise | 108.05.A.2 |
| Deadline | Within 7 calendar days of award and before starting work. Updates within 7 calendar days of the Engineer's request. The Engineer responds with approval, comments or rejection within 7 calendar days; the Contractor resolves responses within 7 calendar days | 108.05.A.1 |
| Payment consequence | Where 30 calendar days pass from the original submittal without approval of the progress schedule, or where the Contractor does not update it, the Engineer may withhold contract payments in whole or in part until that is put right | 108.05.A.1 |
| Content | Controlling operations identified; non-controlling operations and supporting activities including submittals, working and shop drawing preparation, Department review time, procurement, fabrication, delivery, and third-party operations; planned start and completion dates; and all contract-specified dates | 108.05.A.2 |
| Activity durations | 1 to 20 days for each construction activity, longer work broken into two or more activities distinguished by location or other description | 108.05.A.2.d |
| Narrative | A written narrative covering the planned work crews, the workdays in a week, the shifts in a day and the hours in a shift, and any non-work period — holiday suspensions and seasonal ones included | 108.05.A.2.e |
| Weather | The Contractor allows for normal weather delays in developing the schedule | 108.05.A.2 |
| Overlapping operations | Overlapping or concurrent controlling operations may be allowed where the Contractor supplies a written explanation for each occurrence, submitted with the schedule | 108.05.A.2 |
| Modification trigger | Three named events: the rate of progress falls behind the latest schedule; a contract revision or a delay reaches a controlling operation, or reaches the contract time or the completion dates; or the Contractor revises the sequence of operations or the plan | 108.05.A.3 |
| Critical path method | Required where the contract requires it, with no content requirements stated here. On approval the CPM schedule replaces the progress schedule | 108.05 |
What special provision 20SP-108B-01 requires of the CPM schedule
| Requirement | What 20SP-108B-01 states | Clause |
|---|---|---|
| Scheduling software | Primavera Project Management, with a Primavera XER file that imports directly into the Department's version without loss or modification of data and without conversion. The Contractor designates a Project Scheduler responsible for administering the schedule in that software | (a), (b)2.A |
| Submittal timetable | A four-row table. Interim Baseline 14 days after award, review 7, resubmission 7. Baseline 28 days after award, review 14, resubmission 7. Revised Baseline 10 days after the requirement or request, review 10, resubmission 7. Update 5 days after the data date, review 7, resubmission 7 | (b)1, Table 1 |
| Before construction | The Interim Baseline must be submitted and approved before construction activities start. It details the first 60 days of work and shows summary-level activities for the remainder; monthly updates to it continue until the Baseline is approved | (a), (d)1 |
| Timing rules | Where a submittal arrives past midday, or lands on a weekend day or a Department holiday, the review and resubmission clock starts on the following weekday that is not a holiday. A submittal is treated as approved where the Contractor met its deadline and the Engineer did not respond within the review window — and missing the submittal deadline waives the Engineer's obligation to meet it | (b)1.A, (b)1.B |
| Payment consequence | Contract payments may be withheld in whole or in part where no approved CPM schedule has been developed within 60 days of contract award, or where the required updates are not made | (a) |
| Update frequency | Monthly, with consistent data dates, due 5 days after the data date. Actual start and finish updated for completed activities; actual start, remaining duration and percent complete for activities in progress; out-of-sequence activities corrected from the scheduling log. The Engineer may request an update at any time. A final update is due within 14 days of completing all activities on the schedule | (e) |
| Narrative | A fixed ten-heading outline, for baselines and again for updates: milestone dates, work sequence, resources, work schedule, weather, critical path, delays, third-party interfaces, then lags (baseline) or activity changes (update), and additional information. See the section below | (d)4, (e)1 |
| Other submittals | A Gantt chart in PDF, grouped by work breakdown structure, sorted by start date, the longest path picked out in red, with a named set of columns and a title block carrying the data date, run date, contract ID, project name, contractor and submission date; plus the scheduling and levelling log for that submittal | (b)2 |
| Revised Baseline trigger | Four: a contract revision or change that significantly impacts the schedule; a plan to substantially alter future work sequences or operations; significant discrepancies between the latest approved schedule and actual operations or progress; or an update showing considerable negative float or making it apparent the work may not finish within contract time | (d)3 |
| Time impact analysis | Both a prospective and a retrospective method are prescribed. See the section below. Time extensions will not be considered without an approved current schedule | (f) |
| Float ownership | Float that the schedule carries, and float thrown off by either side's efficiencies, is a shared resource that the Department or the Contractor may draw on. A named float-suppression list is cause for rejection: preferential sequencing, lag logic restraints, artificial activity times, and unapproved constraint dates. A Baseline submitted with negative float is rejected; a Revised Baseline or update with negative float can be cause for rejection. Negative float is not a basis for requesting a time extension | (c)10 |
| Activity durations | 1 to 20 whole days for task-dependent construction activities; summary-level activities in an Interim Baseline may run longer. Original durations may not change without a Revised Baseline and an explanation accepted in the narrative | (c)5.E |
| Logic | Open logic activities are not allowed — every task-dependent activity except the first must have something tied to its start, and every one except the last must have something tied to its finish, deleted activities excepted. Negative lags are prohibited | (c)5.F |
| Constraints | Only "Finish on or Before" and "Start on or After", and only for contractual dates and timeframes. Where constraints would break a continuous critical path from project start to project completion, project-level calendars representing contractual dates are used instead | (c)7 |
| Scheduling options | Relationships to and from other projects ignored; open-ended activities not made critical; schedule calculated using retained logic; critical activities defined as longest path; total float computed as finish float | (c)9 |
| Activity types and identity | Resource Dependent is not used as an activity type; Level of Effort activities take a duration percent-complete type and all others take physical; milestones carry zero duration and a start or finish milestone type. The assigned unique activity ID runs for the life of the project, and once approved, activities are not removed. Names pair a work verb with an object, and Department activities carry "MDOT" in the name | (c)5.A–D, (c)6 |
| Calendars | Activities take a project-level calendar carrying holidays, weekends, seasonal restrictions, weather contingency and other contract non-work days. Calendars for non-field activities — submittals, reviews, procurement, fabrication, cure times, utility relocations by others — show no non-work days unless the contract says otherwise, and every activity calendar shares the same shift times | (c)8 |
| Payment | A separate pay item exists for the CPM schedule work, paid on Baseline approval, with no extra compensation for updates, revisions or delays | (g) |
Two delay analysis methods, one for each direction in time
Clause (f) is the most explicit treatment of delay analysis in the agency documents read for this site, because it prescribes a method for each direction rather than naming a document or leaving the choice open.
Prospective — a time impact analysis. The impact is modelled as a fragnet; the approved current schedule is selected as the unimpacted schedule; the fragnet is inserted and the schedule calculated to give the impacted schedule; and the finish dates of the two are compared. The duration of the impact is that difference, and any time extension is based on it.
Retrospective — a contemporaneous or windows analysis. The approved schedule before the delay is identified, as is the approved schedule after it and each approved update in effect during it; the critical path is identified and tracked each day from immediately before the delay to immediately after; and whether the delay affected the critical path decides whether any time is due. Where it did, the number of days the critical path was delayed is determined, and any extension rests on the allocation of responsibility for the delay.
Two conditions sit around both. Time extensions are not considered without an approved current schedule, and the standard specifications rather than this provision supply the excusable delays for which an extension may be granted — the analysis quantifies rather than establishes entitlement.
What this project does against that structure is narrow and worth stating. Given two schedules it reports what changed between them: activities added or removed, logic and duration changes, and date movement, including movement of the longest path. It computes its own forward and backward pass and states its own float alongside the float the file carries. It does not insert fragnets, does not run a windows analysis, does not allocate responsibility for a delay, and does not determine whether any time is due — those are determined by the reviewing authority. Time impact analysis, delay analysis methods compared, concurrent delay and extension of time set out the families of method.
A narrative with a fixed outline
Most narrative clauses read for this site list topics. 20SP-108B-01 supplies a lettered outline the narrative is to follow, twice over — ten headings for baselines and ten for updates, with eight shared between them.
The two that differ are the ninth heading. Baselines explain the use of lags, summarised by each sequence of work. Updates instead list activity changes other than status or progress, with an explanation for each, including activities added or deleted and changes in relationships.
The weather heading is the most specific of its kind in this set. A baseline narrative explains how the schedule accommodates adverse weather days, how impacts will be handled, and what is planned for winter months and seasonal suspension. An update narrative instead sets out each adverse weather date and the monthly total of days lost to that weather or to conditions it left behind, names the activities affected, and states the effect on the critical path.
A narrative is a document rather than a field in a schedule file, so whether one was submitted and whether it followed the outline are facts about the submission record. Part of what it must say — which activities changed, which relationships changed, how the longest path moved — is derivable from two schedule files, and that comparison is what this project reports. Schedule narrative and schedule calendars cover the overlap.
Deemed approval, and what it turns on
One rule in the submittal table has no counterpart in the other agency documents read here: where the Contractor meets its submittal deadline and the Engineer does not respond inside the review window, the submittal is treated as approved — and where the Contractor misses its deadline, the Engineer's obligation to meet the review window is waived.
Both halves turn on dates no schedule file records. A schedule carries a data date; it does not carry the date it was handed over, the hour it arrived, whether that day was a Department holiday, or the date a response came back — and the midday clock rule at (b)1.A makes the hour matter. So the whole timetable, the 60-day payment condition included, is a fact about the submission record rather than about the schedule. This project reports what an imported schedule contains, including its data date; it does not know when the file was sent, and its silence about a deadline is not a statement that the deadline was met.
What this page does not tell you
- It does not tell you which clauses govern your project. The incorporated contract documents govern — whether 20SP-108B-01 is among them is a project fact. The Department applies it where the progress clause calls for CPM and on time-incentive projects, but only the contract settles it. An agency name alone establishes nothing.
- Only subsection 108.05 and the special provision were read. Provisions elsewhere in the 2020 book bearing on excusable delay, contract time, acceleration, default or payment were not read clause by clause — including subsection 109.05.F and subsection 108.11, which 108.05 refers to. Clause (f) states that the excusable delays themselves come from the standard specifications, and this page does not establish what they are.
- 20SP-108B-01 carries a 2020 approval date. Whether a later version exists was not established here; the document read was the version approved on 26 February 2020 with FHWA approval on 2 March 2020.
- Every deadline on this page is a fact about a submission, and the deemed approval rule above is the clearest example. Nothing in a schedule file records submittal or response dates.
- There is no rule pack behind this page. It rests on a reading of the two documents, 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, whether a constraint type or a lag was permitted, and whether more contract time is due, are determined by the reviewing authority.
Related pages
- How state DOT scheduling specifications compare.
- Neighbouring readings: WisDOT · MnDOT · Iowa DOT.
- P6 schedule options — retained logic, longest path, and how total float is computed.
- XER format · schedule formats.
- Time impact analysis · delay analysis methods compared · concurrent delay · extension of time.
- Float ownership · total float and free float.
- Schedule constraints · lags and leads · activity durations and logic.
- Schedule narrative · baseline schedule submission · recovery schedules.
- Glossary — fragnet, longest path, retained logic, open logic.
- What the engine does and its limitations.
- The methods this project uses and the standards map.