Seven red flags in a Primavera P6 schedule · and what they cost you

You can tell a lot about a programme before you ever look at the dates. Structural defects appear first, and they are the earliest, cheapest warning that a schedule has stopped telling the truth. Here are seven to check on any Primavera P6 XER.

• 1. Open ends. Activities with no predecessor or successor. Any significant number means the network does not calculate the way it appears to, the critical path is unreliable.
• 2. Hard constraints. "Must finish on" / "start on" dates that override logic. Each one is a place where the schedule stops calculating and starts asserting a date.
• 3. Negative float. The programme already knows it is late but has not been re-planned, often masked by constraints elsewhere.
• 4. Excessive lags and leads. Large lags used instead of real activities, or negative lags (leads) hiding missing logic.
• 5. High-duration activities. Multi-month activities that hide progress and defeat meaningful measurement.
• 6. No usable baseline. Without a baseline there is nothing to measure against. And no basis for a delay analysis later.
• 7. A Baseline Execution Index below 0.95. The team is completing fewer activities than the plan required by the data date, the clearest early signal of slippage, before the headline dates move.

None of these are about the dates. They are about whether the model is built well enough to be trusted. And they are visible months before a dispute.

When should you check a P6 schedule for these red flags?

Every one of these is a mechanical test, part of the full DCMA 14-point and GAO checks we run on any P6 programme. Run them monthly, not at claim time, and structural problems get fixed while they are still management problems. On live mandates, our planning team reads the output the way a tribunal will.