P6 Check Schedule: What Each Test Is Actually For

Primavera P6 Professional ships with a schedule check that runs the DCMA 14-point assessment against your project and reports the results with configurable thresholds. Most planners discover it, run it once, see a wall of percentages, and never open it again.

That is a shame, because the checks are not arbitrary bureaucracy. Each one exists because a specific kind of schedule failure kept costing people money. This post is about what each test is actually looking for — and which ones deserve your attention on a given project.

Where it lives

In P6 Professional the check sits under the Tools menu; you pick the project, set thresholds, and it produces a report of passes and failures. The EPPM web client has historically lagged here, which is why plenty of teams keep a Professional client connected to the same database purely for this purpose.

Thresholds are editable. That matters: the defaults come from a US defence acquisition context, and blindly applying them to a two-month shutdown or a ten-year infrastructure programme produces noise rather than insight.

The fourteen checks, grouped by the question they answer

The list is easier to remember — and far easier to explain to management — if you stop treating it as fourteen items and start treating it as four questions.

1 — Is the network complete?

Logic counts activities missing a predecessor or successor. Target: 5% or fewer. This is the foundational check, because an activity with no successor is invisible to delay analysis — it can slip forever and the completion date will not move. (Project start and finish milestones are the legitimate exceptions.)

Relationship types expects at least 90% Finish-to-Start. FS is the relationship a human can reason about. Heavy SS/FF use is not forbidden — overlapping linear works genuinely need it — but every non-FS link is a place where the schedule behaves in ways people misread.

Leads — negative lag — should be zero. A negative lag says “start this before its predecessor finishes”, which is really a Start-to-Start relationship written badly, and it can produce dates nobody expects.

Lags should be under 5%. A lag is a duration with no owner, no resources and no progress: cure time modelled as a 7-day lag is indistinguishable from a 7-day mistake. Where the wait is real work or real time, an activity is the honest model.

2 — Is it honest?

Hard constraints should be zero, soft ones under 5% — for the reasons in the constraints post. A hard constraint stops delays propagating, which means every other number in the report becomes untrustworthy.

Negative float should be zero. Negative float is not a modelling error; it is the schedule shouting that the current plan cannot meet a date it has been given. The failure is not that it exists — it is leaving it unresolved for six months because “everyone knows about it”.

Invalid dates finds forecast dates in the past and actual dates in the future. Both mean the data date and the progress do not agree, and both make every calculated date downstream nonsense. This is a five-minute fix and the highest-value check in the list for a schedule that gets updated monthly.

High float flags activities with more than 44 working days of total float. It is usually not a float problem at all — it is a missing logic problem showing up somewhere else. Chase the high-float activities and you will find the dangling ends the Logic check missed.

3 — Is it realistic?

High duration flags remaining durations over 44 working days. Long bars are not wrong in principle, but they cannot be measured: an activity that runs two months reports the same “50%” for weeks regardless of what is happening. Break them where the work has natural stages.

Resources checks that activities with duration carry resources or costs. Only relevant if the schedule is genuinely resource-loaded — if it is not, this test is noise and should be turned off rather than explained away every month.

Critical path test is the cleverest one, and the least used. You inject a large delay into a critical activity and re-schedule: the project finish should move by roughly the same amount. If it does not, the critical path is broken somewhere — usually by a constraint or a missing link. It is the single best sanity check on whether your network is a real model, and it takes two minutes on a copy of the project.

4 — Are we on track?

Missed tasks counts activities that should have finished by the data date and did not — under 5% is the expectation.

CPLI (Critical Path Length Index) compares the length of the remaining critical path to the time available. 1.0 means you finish exactly on time; below 0.95 means the path no longer fits.

BEI (Baseline Execution Index) compares tasks actually completed to tasks the baseline said should have been completed. Below 0.95 means you are falling behind the plan, regardless of what the forecast dates claim.

CPLI and BEI are the two numbers worth putting in front of management, because they turn “the schedule looks fine” into two ratios that can be trended.

The fourteen, one by one — thresholds and remedies

The narrative above is the why. What follows is the working reference: the threshold, where to find it in P6, and what actually fixes it. Numbering follows the standard DCMA order.

1 · Logic — under 5% missing a predecessor or successor. Check: an Activities filter with Predecessors = 0 OR Successors = 0, excluding the genuine start and finish milestones. Fix: add the relationship that exists in reality. Do not bulk-apply SS/FF links to clear the count — if nothing depends on an activity and it depends on nothing, ask whether it belongs in the schedule at all.

2 · Leads — zero. Check: the Relationships tab, filtered to lag below zero. Fix: every lead has a legitimate logic alternative. Split the predecessor, or use Start-to-Start with positive lag.

3 · Lags — under 5% of relationships. Check: same view, lag above zero. Fix: where the wait is real — curing, drying, permit approval — model it as an activity with a duration you can track, not as a lag nobody owns.

4 · Relationship types — at least 90% Finish-to-Start. Check: group the Relationships view by type and count. Fix: keep the SS/FF pairs that model genuine overlap; unwind the ones that were reached for out of habit.

5 · Hard constraints — zero hard, under 5% soft. Check: add the Primary Constraint column and sort by it. Fix: replace hard with soft, or better, with logic. Schedules converted from Microsoft Project are the worst offenders — MSP’s automatic constraints do not translate cleanly, and I have inherited files where every activity carried a Start No Earlier Than pinned to its baseline date.

6 · High float — under 5% above 44 working days of total float. Check: filter Total Float > 44, excluding completed activities. Fix: trace each high-float activity forward; somewhere between it and the finish milestone there is a missing link. Procurement tied to a milestone but not to the installation it feeds is the classic case.

7 · Negative float — zero. Check: filter Total Float < 0. Fix: find the constraint or imposed date causing it. Either the date moves, the logic changes, or the team acknowledges a late delivery. Deleting the constraint to make the number go away destroys the one piece of information the schedule was trying to give you.

8 · High duration — under 5% with remaining duration above 44 working days. Check: filter Original Duration > 44 and status not complete. Fix: decompose. “Fabricate equipment” becomes submit drawings, fabricate phase 1, factory acceptance test — each independently measurable.

9 · Invalid dates — zero. Check: forecast dates earlier than the data date, actual dates later than it. Fix: five minutes of statusing discipline. This is the cheapest check in the list and the one that most often invalidates everything downstream of it.

10 · Resources — activities with duration carry resources or costs. Check: filter for Budgeted Units or Budgeted Cost equal to zero. Fix: not a quick one — load the major types first (craft labour, key equipment). If the schedule is deliberately not resource-loaded, turn the check off rather than explaining it away every month.

11 · Missed tasks — under 5%. Check: Baseline Finish earlier than the data date with status not complete. Fix: this is an execution or statusing problem, not a scheduling one. Rebaselining to clear it is dishonest unless the scope genuinely changed.

12 · Critical path test — the injected delay must propagate. Check: on a copy, add 20 working days to a critical activity’s remaining duration and reschedule; the finish should move by about 20 days. Fix: if it does not, debug along the critical path for constraints, open ends and calendar mismatches. Two minutes to run, and the single best sanity check in the list.

13 · CPLI — above 0.95. Critical Path Length Index = (critical path length + total float) / critical path length. Below 0.95 you would need to compress the remaining critical path by more than 5% to hold the date. Check: manual calculation from the longest path and the float on the completion milestone.

14 · BEI — above 0.95. Baseline Execution Index = tasks actually completed / tasks the baseline said should be complete by now. Below 0.95 means you are falling behind whatever the forecast dates claim.

How to use the results without drowning

Three habits from years of running these on other people’s projects:

1. Fix invalid dates and negative float first. Until those are clean, every other percentage is measuring a schedule that does not describe reality.
2. Treat the report as diagnosis, not a grade. Passing fourteen checks does not make a schedule good — I have audited immaculate-scoring programmes that modelled work in an order the site could never build. The checks find mechanical faults; they cannot tell you whether the sequence makes sense.
3. Set thresholds once, deliberately, and write down why. A schedule check that everyone has learned to ignore is worse than no check at all.

That second point is the honest limitation of any automated check, and it is why an independent system and schedule audit starts where the fourteen points stop: with whether the network describes how the work will actually be built.