PennDOT CPM scheduling requirements: Publication 408 Section 689 and 108.03(b)
The Pennsylvania Department of Transportation splits its scheduling requirement across two clauses of one book. Section 108.03(b), Construction Project Scheduling, of Publication 408, Specifications, 2026 Edition, Initial Edition — effective 10 April 2026 — carries the general obligation, the project control meetings, the submittal lead time and the recovery trigger. Section 689, Construction Scheduling, carries the software standard, the three schedule tiers, the format rules and the payment schedule. Section 689 opens by cross-referencing 108.03(b), so the two are read together rather than in the alternative. A third document, Publication 615, Scheduling Manual, 2026 Edition — transmitted 18 June 2026 — defines the template that 689 requires the schedule to be converted through.
One requirement on this page breaks an assumption that holds for every other agency compared on this site. The Department's declared standard — for scheduling, and for project management alongside it — is Asta Powerproject, a product of Elecosoft, rather than Primavera. The sixteen documents read for this site otherwise divide into those that name Primavera and those that name no product at all. Pennsylvania names a third thing.
What Section 689 and 108.03(b) require
| Requirement | What the 2026 Publication 408 states | Clause |
|---|---|---|
| Scheduling software | Asta Powerproject by Elecosoft is the Department's software standard. A commercial package may produce the schedule and reports, but the CPM Schedule is built in Asta Powerproject itself, or in one of six listed compatible formats: .mpp, .xml, .xer, .p3b, .dir and .stx. The Contractor verifies compatibility against the Department's version. A compatible native file is converted to .pp through the PennDOT Construction template defined in Publication 615 and checked one-to-one against the native file first |
689.2, 689.3(b)3 |
| Submission route | Uploaded through the PennDOT Project Collaboration Center, so authorised parties can view the current baseline. Once accepted, the .pp file is the governing schedule of record and is loaded into Asta Vision; every later update, revision or recovery schedule goes the same route, keeping a version record |
689.2 |
| Schedule tiers | Three, set by the contract designation: Narrative Schedule, CPM Schedule, or Resource Loaded CPM Schedule. The Representative may require the Contractor to attend a scheduling conference covering this specification and the portions of 689 that apply to the designated format | 689.1, 108.03(b) |
| First schedule due | CPM tier: a 60 Calendar Day Work Plan as a PDF from Asta Powerproject at the preconstruction conference, with a generalised schedule for the balance of the work, maintained and resubmitted bi-weekly until the CPM Schedule is accepted. A Bid Preparation Schedule — the schedule used to prepare the bid — within 30 calendar days after contract execution | 689.3(b)1, (b)2 |
| Baseline deadline | The CPM Schedule within 30 calendar days after the actual Notice to Proceed date, submitted through PPCC as .pp on the Publication 615 template, plus a PDF generated from Asta Powerproject at 11 by 17 inches with no more than 25 activities per sheet. Narrative tier: within 15 calendar days after the actual NTP date |
689.3(a), (b)3 |
| Agency review | 14 calendar days for the Representative to review and respond, on the Narrative Schedule, the CPM Schedule and each update alike. Where the Department does not accept it, a revised schedule follows within 10 days of the comments | 689.3(a), (b)3, (c) |
| Consequence of missing the deadline | Where the CPM Schedule does not arrive within the 30 calendar days, the Contractor is required to attend a scheduling workshop to prepare an acceptable one. The same applies to a Narrative Schedule missing its 15 days. Current estimate payments may be withheld in both cases | 689.3(a), (b)3 |
| Update frequency | Monthly at a minimum, against the accepted baseline as the basis | 108.03(b), 689.3(c) |
| Narrative | Required with each update, and itemised: why the update was made; which activities progressed; every logic change, naming its relationship type and any imposed dates; calendar changes including which activities and which workdays; duration changes; critical path changes; and any schedule concerns | 689.3(c) |
| Recovery trigger | Where the latest completion time for any work on the current schedule leaves a controlling activity delayed 14 days or more beyond the Required Completion Date or a specified Milestone Date as adjusted, the Representative may require a written plan to recover the lost time, covering the affected activities with explanations for the delays or for any duration variance from the accepted baseline. Due within 7 calendar days of notification | 108.03(b)5 |
| Time impact analysis | No named method, but a prescribed pair of schedules. A time extension request under 108.06(a) carries Supporting Schedules: whichever accepted schedule stood immediately before the impact, and a post-impact one showing its effect on the Required Completion Date or a Milestone Date. Due no later than 30 calendar days after the event ends, through ECMS, with .pp files sent separately via PPCC; the Representative responds in 14 calendar days |
108.06(a) |
| Float ownership | A shared commodity, stated in the definitions rather than in an ownership clause. Float is defined as how long an activity may slip, at either end, before the project's Required Completion Date is affected | 689.1 |
| Activity durations | Activities with durations over 15 working days are limited to a minimum, and the fineness of detail is limited where possible to a minimum 5-day activity duration. Enough activities to demonstrate the necessary interdependencies | 689.3(b)3 |
| Relationships | All relationships are finish-to-start. A single start activity and a single finish activity for the whole schedule; every other activity carries at least one predecessor and one successor. Lag and lead times are incorporated as a separate activity. Redundant relationships are not to exceed 5 percent of the total number of relationships | 689.3(b)3 |
| Constraints | Notice to Proceed takes a "Start on" or "Start on or After" constraint; Project Completion takes a "Finish on" or "Finish on or Before" one. Interim milestones in the contract use soft constraints — "Start on or After" or "Finish on or Before" — and a seven-day no-holiday calendar | 689.3(b)3 |
| Standardised activities | A standardised activity list used verbatim where applicable, with descriptions unmodified: Project Award and Notice to Proceed, then Physical Work Start, Implement Detour, Remove Detour, Open to Traffic, and Physical Work Complete, Project Completion. Activity IDs and descriptions stay constant for the project; a major change is handled by removing the activity and substituting a new one with a new ID | 689.3(b)3, (c) |
| Per-activity data | Activity ID, description, duration in working days, early and late start and finish, total float, predecessor, successor, calendar, and resource allocation and effort where applicable. Updates add the original baseline duration, actual dates, and remaining duration or percent complete | 689.3(b)3, (c) |
| Payment | Lump sum, released in staged payments against submittal and against percentages of contract work completed | 689.4 |
A finish-to-start-only network, with lag as an activity
689.3(b)3 states the format rules as a short list, and two of them together change what the network looks like. All relationships are finish-to-start. Lag and lead times are incorporated as a separate activity.
Most specifications compared on this site restrict relationship types by banning one — usually start-to-finish — and leave lags to a review threshold or to an explanation requirement. Pennsylvania goes further in both directions at once: it permits one relationship type rather than prohibiting one, and it removes lag from the relationship entirely by making it a thing with a duration, an ID and a calendar.
The delay between two activities becomes an object in the schedule rather than a property of a link. A ten-day lag is a number in the relationship table; a ten-day activity named for what happens during those ten days appears in the activity list, carries a calendar, and can be progressed — and, unlike a lag, a reviewer reading the activity list will see it.
Both rules are checkable against an imported file: relationship types and lag values are recorded per relationship. What a file cannot settle is whether a separate activity correctly represents the delay it stands for. Lags and leads covers what a lag does to a calculation.
Redundant relationships capped at five percent
689.1 defines a redundant relationship as a link between activities that is also represented by a parallel path or relationship — one that can be removed without affecting the schedule's logic or its calculations, and that may add unnecessary complexity and hinder review and analysis. 689.3(b)3 then caps them at five percent of the total number of relationships in the schedule.
This is a ratio against the network's own size, which makes it unusual among the thresholds on this site. Most numeric rules in these specifications are absolute: a duration cap in days, a review period in calendar days, a delay threshold. A percentage of total relationships scales with the schedule, so the same rule binds a 300-activity network and a 3,000-activity one at the same proportion.
Its inputs are also entirely inside the file. The denominator is the relationship count; the numerator is the set of relationships whose removal leaves the calculated dates unchanged because a longer parallel path already imposes the same order. That is a graph computation, not a judgement.
This project reports relationship counts and types from the imported file. Whether a particular link is redundant in the sense 689.1 defines, and whether a schedule meets the cap, are determined by the reviewing authority.
Two constraint rules, pulling in opposite directions on one field
689.3(b)3 requires constraints in two named places and restricts their form elsewhere: Notice to Proceed takes a "Start on" or "Start on or After" constraint, Project Completion a "Finish on" or "Finish on or Before" one, and interim milestones stated in the contract take soft constraints — the "or After" and "or Before" variants — with a seven-day no-holiday calendar.
The hard and soft forms differ in what happens when the calculation disagrees with the constraint: a soft constraint bounds the calculation in one direction and leaves the other free, a hard one fixes the date in both. Applying the soft form to interim milestones while permitting either on the two project-level anchors is a difference in kind, not of degree.
The no-holiday calendar is the other half of the same thought. A milestone on a working calendar moves when the calendar's non-work days move; one on a calendar with no non-work days sits on the contract date regardless. Both facts — an activity's constraint type and its calendar — are carried in the export. Schedule constraints covers the types.
What this page does not tell you
- It does not tell you which clauses govern your project. Which of the three tiers applies follows from the contract's designation, and the incorporated contract documents — the edition of Publication 408 the contract names, plus every special provision — are what apply. An agency's name alone does not establish which clauses bind.
- Publication 615 was read only as the document Section 689 points to. The PennDOT Construction template it defines, and its schedule review checklists, set out how the software is to be used; any requirement carried only there — template settings, code libraries, view definitions — is not established on this page. Publication 615 states in its own foreword that it provides guidance to Department staff, consultants and contractors.
- Section 689's payment provisions were read but are not reproduced. No prices appear on this site.
- 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, and this
project does not read the
.ppformat. - 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 · WSDOT · CDOT.
- Schedule file formats — what travels between tools and what does not.
- Schedule constraints · lags and leads · float ownership.
- Glossary — redundant relationship, soft constraint, controlling activity.
- What the engine does and its limitations.
- The conformance rule catalogue and the standards map.
Source: web/pages/penndot-scheduling.md. Source commit date: 2026-09-11.