Most construction schedules are built to win a bid. Very few are built to survive a deposition.
That gap surfaces, usually two years later, when a delay turns into a claim and the schedule becomes evidence. By then the project is over, the team has rotated off, and the owner is sitting across from opposing counsel watching their own scheduler explain logic ties he didn’t write.
This is the predictable part of construction litigation. Not the dispute itself. The moment the schedule, which everyone treated as a planning artifact, gets reread as a legal document.
Four structural problems show up almost every time. None of them are exotic. All of them are fixable during construction. None of them get fixed on most projects.
1. Open-ended logic
Activities without successors. Activities without predecessors. Dangling milestones.
On a healthy schedule, every activity has at least one predecessor and one successor, with rare and documented exceptions. Project start. Project finish. Occasional level-of-effort work. Everything else flows.
Open-ended logic doesn’t always cause problems during construction. The scheduler updates progress. The float calculations look reasonable. The monthly report goes out. Nothing breaks.
The problem appears when a forensic analyst runs the schedule backward to identify the longest path through a delayed period. Open ends create ambiguity about which activities controlled the schedule and when. Ambiguity in a delay claim almost always resolves against the party making the claim, because the burden of proof sits on whoever is trying to recover damages.
The fix is unglamorous. Run a logic check on every monthly update. Most P6 implementations have one built in. Use it. Document the exceptions in the schedule narrative. A schedule with three documented open ends and a written explanation for each is defensible. A schedule with thirty undocumented open ends is not.
The reason this rarely gets done is that schedulers are pressed for time and logic checks surface inconvenient findings. A clean logic check requires real revisions. Skipping it is faster. The cost of skipping it shows up in deposition.
2. Soft constraints masquerading as hard ones
This is where most schedules quietly break.
A “Start On” constraint applied to a procurement milestone because the scheduler wanted the date to hold. A “Finish No Later Than” applied to a turnover because the owner asked for it in a meeting. A “Mandatory Start” applied to a long-lead delivery because the GC wanted to lock the date in.
Constraints override logic. That’s their function. Used correctly on a small number of activities with genuine external drivers, they make the schedule more accurate. Used as a substitute for logic, they make the schedule unanalyzable.
Three years later, when a forensic analyst pulls the .xer file, those constraints are the first things they flag. A constrained schedule can’t be analyzed for delay impact in any meaningful way. The constraint is doing the work the logic should be doing, which means the schedule’s response to a delay event is artificial. Time Impact Analysis depends on logic propagation. So does Windows Analysis. Both methods become indefensible when constraints are doing the heavy lifting.
The discipline is to use hard constraints only when there’s a genuine external driver. A permit issuance date. A contractually required milestone. A regulatory deadline. A long-lead equipment delivery with a confirmed ship date. Everything else flows from logic. If the date won’t hold without a constraint, the answer is to fix the logic. Pin the date through realistic durations and proper sequencing. Not through a constraint that overrides both.
A simple test for owners reviewing a schedule: count the hard constraints. A typical fast-track capital project should have somewhere between five and twenty. If the schedule has eighty constraints, somebody is using them as a substitute for thinking. If it has two hundred, the schedule is essentially a Gantt chart with dates pinned to it, and it will not survive analysis.
3. Undocumented re-baselining
Every project re-baselines. The question is whether anyone documented why.
A baseline schedule is a contract artifact. Updating it is a contract action. On most projects, the baseline gets revised quietly. A scheduler swaps in new durations after a change order. The logic shifts to accommodate new sequencing. The owner approves the monthly update without realizing the baseline they’re comparing against has moved.
Two years later, a forensic analyst lays the original baseline next to the as-built and finds three baselines in between, none of them formally adopted. At that point, the delay narrative is unprovable. Not because the delay didn’t happen. Because there’s no defensible reference point to measure it against.
This is the single most common reason a delay claim collapses in deposition. The contractor argues that the project was always operating against an updated schedule. The owner argues the original baseline was the contract. Without documentation, the judge or arbitrator picks whichever sounds more reasonable, which is usually neither one.
The fix is procedural. Treat every baseline change like a change order. Owner approval in writing. A narrative explaining what changed and why. A version archive. Most schedulers resist this because it slows them down. It also happens to be the only thing that holds up later.
A useful rule for owners: any change to logic, durations, or sequencing on more than five percent of activities triggers a formal baseline revision. Below that threshold, it’s a schedule update. Above it, it’s a new baseline that needs owner approval and a narrative. The exact percentage is less important than having a written threshold. Without one, every change is a judgment call, and judgment calls don’t get documented.
4. Missing baseline narratives
A baseline schedule without a narrative is a list of activities with dates next to them.
The narrative is what tells a forensic analyst, or a judge, what the schedule was meant to do. Why the mechanical rough-in was sequenced before the curtain wall. Why the procurement chain assumed a specific submittal review duration. Why the float on the long-lead equipment path was allocated where it was. Why the durations for concrete cure cycles assumed a specific weather pattern.
Without that document, every assumption is up for renegotiation in a dispute. The contractor argues one interpretation. The owner’s expert argues another. The judge picks whichever sounds more reasonable, again, which is again usually neither one.
A baseline narrative doesn’t need to be long. Five to ten pages on a typical capital project. It should capture the assumptions that aren’t visible in the logic itself. The risks the schedule is exposed to. The float allocation strategy. The procurement assumptions. The handoff assumptions between trades. The weather assumptions on weather-sensitive work.
The narrative does two things. It makes the schedule defensible by anchoring its assumptions in a written record. And it forces the scheduler to articulate the assumptions in the first place, which often surfaces problems the schedule itself doesn’t show. A scheduler who can’t write a narrative for the schedule they built probably hasn’t thought through it.
AACE International Recommended Practice 29R-03 covers the forensic standard and the documentation that makes a schedule analyzable. Owners who want their schedule to survive the project should look at it before the project starts, not after.
What this means for the owner
Owners don’t usually build schedules. They review them. The leverage point isn’t writing the schedule differently. It’s setting standards for what gets accepted.
Five things, written into the project execution plan from day one:
A logic check report attached to every monthly update, with exceptions explained. Most schedulers will resist this. Insist anyway.
A constraint log showing every hard constraint and the contractual or external basis for it. Update it monthly. Refuse to accept schedules where the constraint count grows without explanation.
A baseline change procedure that requires written owner approval and a narrative for any modification to the accepted baseline. Define the threshold that distinguishes an update from a re-baseline.
A schedule narrative delivered with the original baseline. Updated when the baseline changes. Reviewed by owner-side personnel who understand the work, not just the schedule.
Monthly schedule reviews by someone whose job is to read the schedule against the work, not just sign the update. This is where project controls and planning and scheduling engagements earn their keep on capital projects. The discipline is unglamorous. The cost of not having it shows up in litigation.
None of this is exotic. It’s all available in standard P6 implementations. What makes it rare on actual projects is that nobody requires it until it’s too late to add.
The pattern
The schedules that hold up in litigation are not the most sophisticated ones. They’re the ones that were treated as legal documents from the start.
Logic that resolves cleanly. Constraints that have a basis. Baselines that were changed deliberately and documented. Narratives that capture the reasoning. Boring discipline, applied early, is what makes a schedule defensible.
Most projects skip it because it doesn’t seem necessary while the work is going well. The work going well is the entire window for fixing this. Once a delay turns into a claim, the schedule is what it is. You can’t reconstruct discipline retroactively. You can only inherit the consequences of having skipped it.
This is the upstream version of dispute resolution work. The discipline that prevents claims from becoming losing claims happens during construction, not during litigation. By the time a project reaches deposition, the schedule’s defensibility is already determined.
For owners managing capital projects in the DC-Baltimore corridor and across the Mid-Atlantic, Stelic provides owner-side construction management, project controls, planning and scheduling, and dispute resolution support on complex projects in life sciences, data centers, federal infrastructure, and healthcare.