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 TIA or EOT claim.

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.