After reviewing contractor-submitted Primavera P6 schedules on behalf of public agencies and owners across dozens of projects, the same errors appear repeatedly. Most of them are not the result of inexperience with P6 — they are the result of building schedules quickly without checking them against the standards that experienced reviewers apply.
Here is what to check before your next baseline or monthly update submission.
Open-Ended Activities
Every activity in the schedule — with the exception of the project start milestone — should have at least one predecessor relationship. Every activity — with the exception of the project completion milestone — should have at least one successor. Open-ended activities create false float, distort the critical path, and are immediately flagged by any reviewer using the standard P6 schedule check report.
Run a schedule check before every submission. P6 identifies open-ended activities directly. There should be zero.
Excessive Lags on Relationships
Lags inserted on finish-to-start relationships are often used as a substitute for missing activities or to represent durations that should be modeled as separate work items. Reviewers flag lags over five to ten days as potential logic manipulation. If a lag represents real work — a concrete cure period, a permit review window, a material lead time — model it as an activity. If it does not represent real work, remove it.
Hard Constraints on Non-Milestone Activities
Must-Start-On, Must-Finish-On, and Finish-No-Later-Than constraints imposed on regular construction activities artificially restrict float and distort the critical path. Constraints should be used only where the contract requires them — typically on interim milestones and the project completion date. Every hard constraint on a non-milestone activity requires justification.
Resource Loading That Does Not Match the Contract Value
When a schedule is cost- and resource-loaded, the total budgeted cost should reconcile to the contract value. Schedules where the loaded cost is significantly below the contract value — a common occurrence when only selected activities are loaded — signal that the resource loading is nominal rather than real. Reviewers on USACE and Port Authority projects check this directly.
Out-of-Sequence Progress
In monthly updates, out-of-sequence progress — where an activity is reported as progressing before its predecessor is complete — should be identified and the schedule logic corrected to reflect actual execution. Retained logic versus progress override settings in P6 affect how out-of-sequence progress is calculated. Most agency specifications require retained logic. Check your project settings before every update.
Activity Descriptions That Do Not Identify Location
Activity names like Structural Steel Erection or MEP Rough-In are not useful in a schedule with hundreds of activities performing similar work in different areas. Activity descriptions should identify the location, level, zone, or building that the work is occurring in. This is essential both for schedule clarity and for delay analysis, where the location context of each activity is critical.
Missing or Incorrectly Assigned Calendars
P6 schedules built with a single default calendar applied to every activity — regardless of whether the work is exterior sitework subject to weather shutdowns, interior work that can proceed year-round, or concrete placement with curing durations governed by ambient temperature — will misrepresent duration and float on any activity where the actual working pattern differs from the default. Reviewers check calendar assignment against activity type specifically because a miscalendared activity can shift the calculated critical path without any real change in the underlying work plan. Every project should define distinct calendars for standard construction work, weather-sensitive exterior work, and any activity with a fixed non-working period such as agency-mandated inspection holds, and each activity should carry the calendar that actually governs it.
Data Date Discipline
The data date — the point in time the schedule update represents — should move forward exactly to the actual update period and should never be set to a future date to make an update appear more current than the underlying progress data supports. Schedules where the data date does not match the actual reporting period, or where progress has been recorded past the data date, produce internally inconsistent status reports that reviewers flag immediately and that undermine confidence in every other number in the update. This matters beyond simple compliance: a data date manipulated to obscure how far behind a project actually is will eventually be discovered, and at that point it damages the credibility of every prior submission, not just the one in question.
Total Float Versus Free Float Confusion
Total float — the amount an activity can be delayed without affecting project completion — and free float — the amount an activity can be delayed without affecting its immediate successor — are frequently conflated in schedule narratives, and the distinction matters when a delay claim is being evaluated. An activity can have substantial total float while having zero free float, meaning a delay to it will immediately push its successor even though the overall project completion date is unaffected. Schedule narratives and delay analyses that report only total float, without distinguishing near-term successor impacts from ultimate completion impacts, miss information a sophisticated reviewer will ask for directly. Understanding both figures, and reporting the one relevant to the question being asked, is a basic competency that separates schedules built by someone who understands CPM mechanics from one assembled by filling in a template.
Most of these errors share a common source: a schedule built under deadline pressure and never checked against a standard schedule quality report before submission. Running that check — open-ended activities, excessive lags, hard constraints, logic density, calendar assignment — takes a fraction of the time a rejected submission costs in resubmission cycles. Building it into the workflow before every baseline and monthly update, rather than treating it as optional quality control, is the difference between schedules that clear review the first time and schedules that generate a running list of reviewer comments.
Keep a standing checklist of these items — open-ended activities, lag review, constraint justification, cost loading reconciliation, calendar assignment, retained logic settings, and activity location coding — and run it against every schedule before it leaves your office. It takes less time than a single round of reviewer comments and rework, and it is the difference between a scheduler your reviewers trust and one whose submissions get extra scrutiny by default.
