What Makes a CPM Schedule Defensible — and Why Most Are Not

Most CPM schedules submitted on public works and federal projects share one characteristic: they are technically adequate and practically useless when something goes wrong. The baseline gets approved, monthly updates get submitted, the project gets delayed — but when it is time to quantify that delay, the schedule offers nothing to work with.

This is not because CPM scheduling is a flawed methodology. It is because most schedules are built to pass review, not to tell the story of a project.

The Difference Between Submitted and Defensible

A submitted schedule meets the contract specification well enough to get approved. A defensible schedule can clearly show — when a change event occurs six months in — what the plan was at that moment, how the event affected it, and what the resulting delay to completion looks like. That is a fundamentally different standard.

Five Things That Make a Schedule Defensible

1. Logic Reflects the Actual Sequence

Activity relationships should come from subcontractor input, site constraints, and contract requirements — not from a template. When logic is generic, it cannot support delay analysis because it does not represent the real plan.

2. Float Is Honest

Artificially constrained float through hard constraints or mandatory dates distorts the critical path and makes the schedule unusable for delay analysis. Constraints should only appear where the contract requires them.

3. Resources Match the Real Plan

Cost and resource loading reconciled to contract value and crew plans establishes the basis for showing how a delay impacted productivity. A schedule with nominal resource loading cannot support a lost productivity claim.

4. Updates Tell a Clear Story

Each monthly update should document what happened — what progressed, what was delayed, what changed in sequence, and why. A narrative letter accompanying each submission creates the contemporaneous record essential for any retrospective delay analysis.

5. Change Events Are Documented in Real Time

When an RFI response is late or a differing site condition is encountered, reflect that event in the schedule update for that period — not reconstructed months later. Real-time documentation is the foundation of any Time Impact Analysis (TIA) or Extension of Time (EOT) claim.

Why the Standard Used to Judge Your Schedule Isn't the Contract Spec

Most scheduling specifications set a relatively low bar: a network of activities with logic ties, reasonable durations, and a critical path. That bar exists to get a schedule accepted, not to determine whether it will hold up when someone challenges a delay claim years later. The standard that actually gets applied at that point comes from forensic delay analysis practice — most commonly the framework in AACE International's Recommended Practice 29R-03, Forensic Schedule Analysis, which is the closest thing the industry has to a consensus standard for what a defensible schedule record needs to contain. A schedule can satisfy every line item in a contract's scheduling specification and still fail this standard, because the specification was never designed to test defensibility in the first place.

What Happens When the Record Is Not There

When a schedule cannot support a clean TIA or windows analysis, the fallback methodology is almost always collapsed as-built — reconstructing what should have happened from what actually happened, after the fact. That approach works, but it is inherently more vulnerable to challenge, because it depends on assumptions about a hypothetical sequence rather than a contemporaneous record. Claims built on a thin schedule record settle for less, take longer to negotiate, and are more likely to end up in a dispute review board or litigation than claims built on a schedule that was defensible from the baseline forward. The cost of fixing this problem is far higher after the delay has already occurred than it is at baseline submission.

Expanding on the Five Fundamentals

Logic Density Is Measurable

Reviewers on federal and public agency work commonly check logic density directly — the ratio of activities with only a single predecessor or successor relationship, and the count of open-ended activities. A schedule where twenty percent or more of activities have only one logic tie is a schedule where the network is not really constraining the sequence; durations are effectively floating independent of each other, which defeats the purpose of CPM analysis entirely.

Float Ownership Should Be Explicit

Beyond avoiding artificial constraints, a defensible schedule should make clear who owns float on shared paths — this becomes directly relevant when a delay consumes float that both parties were relying on. Contracts increasingly address float ownership explicitly; if yours does not, documenting your position on it in the schedule narrative from the start avoids a dispute over an assumption no one wrote down.

Getting these fundamentals right at baseline costs a few additional hours of schedule development. Reconstructing them after a delay has already occurred, from incomplete records, costs considerably more — in consultant time, in negotiating leverage, and in the outcome of the claim itself.

Before Your Next Baseline Submission

Ask these questions: Can someone unfamiliar with the project read the schedule and understand the construction sequence? Can you insert a two-week delay event and immediately see the impact on completion? Does resource loading match what you actually plan to put on site? If the answer to any of these is no, the schedule needs more work — not because the owner will reject it, but because you will need it to protect yourself later.

None of this requires a different scheduling software or a more complex methodology than what most contracts already specify. It requires treating the baseline as a record you will need to defend, not a submittal you need to clear. That shift in how the schedule is built — not a new tool — is what separates a submission that merely gets approved from one that still protects you a year later. The additional hours it takes at baseline are a fraction of what a reconstructed delay analysis costs later, built from a fragmented, incomplete record that was never actually designed to support that kind of retrospective analysis in the first place.