NJDOT CPM scheduling requirements: 2019 Standard Specifications Section 153
The New Jersey Department of Transportation gives progress scheduling a section of its own. Section 153, Progress Schedule, of the 2019 Standard Specifications for Road and Bridge Construction — the copy read here carries a file date of 5 October 2022 — is built in three parts: 153.03.01, CPM Progress Schedule; 153.03.02, CPM Progress Schedule Updates; and 153.03.03, Bar Chart Progress Schedule and Updates. Delay analysis is handled elsewhere, at 108.11.01.C, which requires a Time Impact Evaluation.
Section 153 states its own purpose in one line: the schedule exists to monitor contract progress and to evaluate impacts on contract time. Everything in it follows from those two jobs, and the second is why the section is unusually specific about relationship types and about where constraints may appear.
Two features set this specification apart from the others compared on this site. It requires the schedule as an XER file built on the Department's own coding manual and template, which pushes standardisation down to activity codes. And it ties the baseline submission clock to project construction cost bands — four of them — so the same clause gives a small contract and a large one different deadlines.
What Section 153 requires
| Requirement | What the 2019 Standard Specifications state | Clause |
|---|---|---|
| Scheduling software | No product named. The schedule is provided in XER format, built using the Department's construction scheduling standard coding and procedures manual for designers and contractors, and the Department's scheduling template — both published on the agency's website. | 153.03.01 |
| Baseline deadline | Two stages. A preliminary schedule within 15 days after the Contract is executed, covering at least the first 90 days of the project (120 days where total contract value is above $40 million), with a summary network for the remainder. The baseline follows, by Table 153.03.01-1: 14, 21, 28 or 35 days after the preliminary schedule is approved, by project construction cost band. | 153.03.01 |
| Update frequency | Approximately every two months. The Resident Engineer sets the first update's due date on approving the baseline and sets the data date for each update; a progress review meeting is held about 14 days before the update is due, and the update follows within 14 days of that meeting. | 153.03.02 |
| Narrative | Required with each update — a progress narrative covering schedule status, current and anticipated problem areas with their estimated effect, intermediate milestones running late, slippage and progress along the critical path in days, a list of logic changes with reasons, and revisions to activities not worked on. | 153.03.02 |
| Recovery or revised schedule trigger | Where the project falls behind for delays that are not excusable, such that the schedule shows the work finishing after the Completion date, the Contractor takes steps to improve progress; the Resident Engineer may direct more shifts, overtime, extra days or additional plant, and may require a recovery schedule showing how the directed acceleration is to be met. | 153.03.02, 153.03.03 |
| Time impact analysis | Yes — a Time Impact Evaluation. On an excusable delay, the Contractor gives notice, and when the extent of the impact can be determined submits a request for a time extension with a Time Impact Evaluation Form and a CPM fragnet, showing logic revisions, duration changes and new activities with their predecessors and successors. Failing to give notice or to provide the evaluation waives the claim to more contract time. | 108.11.01.C |
| Float ownership | Belongs to the Project. Section 153 defines float as the slack an activity holds against its early start before Completion itself moves, and denies either party exclusive use of it. | 153.03.01 |
| Activity durations | No activity shorter than one workday; no construction activity longer than 30 days without the Resident Engineer's agreement. The same 30-day cap applies in the bar chart tier. | 153.03.01, 153.03.03 |
| Relationships | Every activity except the project start and project completion milestones carries predecessors and successors. An activity's start relates to what precedes it start-to-start or finish-to-start; its completion relates to what follows finish-to-start or finish-to-finish. Start-to-finish relationships are not used. | 153.03.01 |
| Constraints | Constraint dates only on Completion and interim completion milestones, unless the Resident Engineer agrees otherwise. Those milestones are finish milestones carrying a late finish constraint, and the dates come from 108.10. | 153.03.01 |
| Activity coding and naming | Codes identify responsibility, class, type and work breakdown structure, with area codes for location such as stationing and structure number. Descriptions must make start, completion and intermediate status identifiable; "Start", "Continue", "Complete" or a bare percentage are not used. | 153.03.01 |
| Calculation basis | Calculated in working days, with the working-day-to-calendar-date relationship following the proposed work week, weekends, legal holidays and any special contract requirements. Each activity indicates its calendar. Resource loading is not used. | 153.03.01 |
A relationship rule written as a grammar
Most specifications that address relationship types do it by banning one — usually start-to-finish — and leaving the rest alone. Section 153 bans that one too, but it arrives there by a different route, and the route is what makes it checkable.
It states the rule twice, from each end of an activity: what may precede a start, and what may follow a completion. A start takes a start-to-start or finish-to-start predecessor. A completion takes a finish-to-start or finish-to-finish successor. Together those two sentences describe every relationship in a well-formed network and exclude exactly one type, which is then named and excluded explicitly as well.
The practical difference is in what a reviewer can say when a relationship is wrong. A ban on one type tells you only that a code is absent; a rule written from both ends says which end of which activity the fault attaches to — and a finding that names the predecessor side of an activity start is easier to act on than one that names a relationship code.
This project reports relationship types and lags as the imported file states them. Whether a relationship reflects the work is determined by the reviewing authority.
Constraints allowed in exactly two places
Section 153 restricts constraint dates to Completion and interim completion milestones, and requires those milestones to exist as finish milestones with a late finish constraint, drawn from the contract dates at 108.10. Stage starts and finishes are identified with finish milestones too, but the constraint permission does not extend to them.
That is stricter than it first appears, because it is two rules pulling in opposite directions on one field. One says a constraint must be present, on named milestones. The other says a constraint must not be present anywhere else without permission. A schedule can breach this specification by carrying too few constraints or too many, and the same field decides both.
It is also a point where agencies genuinely disagree. Several specifications compared on this site require a project-level completion constraint; another agency's review guidance directs that one be removed. Nothing in the schedule file settles that — the contract does.
Cost bands that move a deadline, not a requirement
Table 153.03.01-1 sets four project construction cost bands — below $5 million, $5 million to $15 million, $15 million to $40 million, and $40 million and above — and gives each a different number of days to submit the baseline after the preliminary schedule is approved: 14, 21, 28 and 35. A separate threshold at $40 million decides whether the preliminary schedule covers the first 90 or the first 120 days.
It is worth being precise about what these bands do, because tiering by contract value usually means something else. In several other agencies' specifications, a value band decides which kind of schedule is required — a look-ahead, a bar chart, or a CPM network. Here it decides only how long you have. The requirements of 153.03.01 are the same at every band; a larger project simply gets more time to build the schedule that all of them require. The bar chart tier at 153.03.03 exists, but nothing read in Section 153 selects it by cost.
What this page does not tell you
- It does not tell you which clauses govern your project. The incorporated contract documents — the edition of the standard specifications the contract names, plus every special provision — are what apply. An agency's name alone does not establish which clauses govern, and whether the CPM tier or the bar chart tier binds is a fact about the contract.
- The coding manual and template were not read. Section 153 incorporates a Department scheduling manual and a schedule template by reference. Neither was obtained for this page, so any requirement carried only in those documents — activity code values, layout conventions, template settings — is not established here.
- 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.
- This project computes and reports; it does not decide submissions. It states what the imported schedule contains and checks it against the clauses cited. Excusability, entitlement and whether a schedule is acceptable are determined by the reviewing authority.
Related pages
- How state DOT scheduling specifications compare.
- Neighbouring readings: ADOT · MnDOT · SCDOT.
- UFGS scheduling requirements.
- The XER format and calendars in an XER file.
- Glossary — float, fragnet, constraint, relationship types.
- What the engine does and its limitations.
- The conformance rule catalogue and the standards map.
Source: web/pages/njdot-scheduling.md. Source commit date: 2026-09-11.