Why Most CPM Schedules Fail Their First Delay Claim

Most CPM schedules look fine until the day they have to defend themselves.

By then it’s too late. The project is in dispute, the delay narrative is drafted, and the schedule that’s been reported on every month for two years is about to be picked apart by a forensic analyst who doesn’t care how good the monthly status meetings were.

This is the part of project controls that gets the least attention and matters the most. A schedule built for reporting is not the same as a schedule built to be defensible. Most owners don’t learn the difference until a claim is sitting on their desk.

The reporting schedule and the defensible schedule are different documents

A reporting schedule answers one question: where are we against the plan?

A defensible schedule answers a harder one. If we have to prove cause and effect months or years from now, will the logic hold up?

These two purposes pull in opposite directions. Reporting wants a clean look, a flat critical path, a status update that fits on one slide. Defense wants every activity tied to its real predecessor, every constraint justified, every assumption documented in the notes field.

When a schedule gets built for reporting only, the compromises show up later. Open-ended activities that never had a successor. Predecessors that were “close enough.” Constraints used to force a date the logic didn’t actually support. Float burned silently because nobody flagged it during the monthly update.

None of that matters in a status meeting. All of it matters in a deposition.

The five failures that show up in nearly every claim

After enough forensic reviews, the same patterns surface. None of these are exotic. They’re in schedules across every sector. Life sciences, data centers, federal infrastructure, healthcare. The problem isn’t that schedulers don’t know better. It’s that the pressure to publish a clean update beats the discipline of building defensible logic.

1. Open-ended activities

An activity with no successor is invisible to the critical path. It can slip 90 days and the schedule won’t react. This is the most common defect in fast-tracked schedules. Procurement activities, owner decisions, regulatory submissions, all sitting in the schedule with start dates and finish dates but no logical connection to the work they’re supposed to drive.

In a delay analysis, an open-ended activity is a hole in the argument. You can’t claim it caused a downstream impact if it wasn’t logically tied to anything downstream.

2. Predecessors that aren’t real

Logic gets built fast at the beginning of a project. Activities get FS relationships because FS is the default, not because that’s how the work actually sequences. The drywall doesn’t start when the framing finishes. It starts when the framing finishes in a specific area, after MEP rough-in passes inspection in that area, after the inspector signs off.

A real predecessor reflects the actual handoff. A nominal predecessor reflects the dropdown menu in P6. The gap between the two is where most delay arguments fall apart. The contractor’s analyst will demonstrate that the predecessor logic doesn’t match how the work was actually sequenced in the field, and the owner’s narrative collapses with it.

3. Soft constraints holding hard dates

The Start On or Finish On constraint is a tool that gets misused constantly. Owners want a milestone to land on a specific date, so a soft constraint goes in. Reporting looks clean. Six months later the constraint is still doing the work that logic should have been doing, and when the actual driving path tries to push the date later, the constraint hides the slip.

A schedule with constraints overriding logic is a wish list with a P6 file extension.

4. Lag abuse

Lag is supposed to represent a real, physical reason why one activity can’t start immediately after another. Concrete cure time. Equipment delivery windows. Inspection cycles.

In practice, lag gets used to absorb planning gaps. Five-day lag here, ten-day lag there, none of it justified in the basis of schedule, all of it untraceable a year later when someone asks why the activity sequence has an unexplained pause in it.

In a claim, undocumented lag is a vulnerability. The opposing analyst will argue the lag was schedule cushion that should have absorbed the delay being claimed. They’ll often win that argument.

5. No baseline preservation

The single most common reason a delay claim falls apart isn’t analytical. It’s evidentiary.

The baseline was never properly archived. The updates were overwritten. The comparison versions don’t exist. Every monthly update became the new baseline, and now there’s no defensible reference point to measure delay against.

This is administrative work. It’s also the work that makes everything else possible.

What a defensible schedule actually looks like

A schedule that holds up in dispute has a few characteristics that distinguish it immediately from a reporting schedule.

Every activity has a predecessor and a successor that reflects actual work handoffs, not menu defaults. Constraints are rare, justified in writing, and removed as soon as logic can carry the date. Lags are documented in the basis of schedule with a physical or contractual reason. The baseline is locked, archived, untouchable. Every monthly update is preserved as its own file, named consistently, stored where forensic analysts can find them two years later.

The basis of schedule document, the one nobody reads until they have to, is treated as the schedule’s legal foundation. It records why the logic looks the way it looks. It identifies which activities are owner-driven, which are contractor-driven, which depend on third parties. It captures the assumptions that aren’t visible in P6.

When that document exists and is current, a delay analyst has something to work with. When it doesn’t, the analyst is reconstructing intent from a schedule file alone, and the resulting narrative is weaker.

The cost of finding out late

Capital project disputes routinely turn on whether the schedule can carry the argument. A weak schedule doesn’t mean the underlying delay claim is wrong. It means the claim can’t be proven to the standard a tribunal or court requires.

Owners discover this at the worst possible time. When the claim is already filed. When the consultant has already spent three months reconstructing logic that should have been built in. When the deposition is on the calendar.

The cost of fixing a schedule retroactively is an order of magnitude higher than building it correctly the first time. Sometimes the schedule can’t be fixed at all, and the owner takes a settlement that’s substantially below what the actual exposure justified.

The fix isn’t complicated. It’s a different discipline applied at the beginning of the project and maintained through it. Treat the schedule as a legal document from day one. Build it to survive forensic review even if you never need to use it that way. Most projects won’t end up in dispute. The ones that do will be decided by whether the schedule was ready.

The owners who learn this lesson early stop treating project controls as overhead. They start treating it as the foundation of their position when something goes wrong. Which, on a capital project of any real size, eventually something will.