Schedule quality: what it is, and why it decides disputes

Everyone agrees schedules should be "good". Far fewer people can say what that means, which is how programmes that look superb in a progress meeting turn out to be worthless in adjudication. Schedule quality is a measurable property — and on contested projects, it is frequently the deciding one.

The three jobs of a schedule

A construction or engineering programme is asked to do three quite different jobs at once, and schedule quality is simply its fitness to do all three.

First, it predicts. The CPM engine takes durations, calendars and logic and calculates when things will happen — most importantly, when the project will finish and which activities control that date. If the prediction machinery is broken, every date the schedule produces is decoration.

Second, it coordinates. The schedule is the shared model that tells the steel fabricator when the foundations will be ready, tells procurement when the switchgear must land, and tells the client when to mobilise their own fit-out contractor. A schedule nobody can rely on forces everyone back to phone calls and guesswork.

Third, it serves as evidence. When the project is two years in and the parties disagree about who caused the delay, the contemporaneous programmes — baseline, updates, revisions — become the primary record of what was planned, what happened, and what each event did to completion. This third job is the one nobody thinks about until they need it, at which point it is the only one that matters.

A high-quality schedule does all three. A poor one typically fails the third job silently for years before failing the first two visibly.

Why a pretty Gantt can be a terrible schedule

The most dangerous schedules we see are the attractive ones. The bars are neatly grouped, the colours follow the WBS, the milestones line up with the contract dates, and the whole thing prints beautifully onto A1. None of that tells you anything about quality, because quality lives in the parts you cannot see on a Gantt chart: the logic, the constraints, the calendars, the float.

It is entirely possible — common, in fact — to build a "schedule" by drawing bars where you want them and pinning them in place with constraints. The output looks identical to a properly networked programme. The difference only appears when something changes: a real schedule recalculates and shows you the consequence; a drawn one shrugs and keeps showing you the same comforting picture. One is a model. The other is a poster.

This is why structural quality checks like the DCMA 14-point assessment exist. They interrogate the machinery underneath the bars — missing logic, leads, lags, hard constraints, implausible float — precisely because the bars themselves can be made to say anything.

What poor quality actually costs

The costs arrive in two waves. The first wave is operational and quiet. Float is the schedule's measure of how much an activity can slip before it hurts; managers use it constantly, often without realising, every time they decide what to chase this week. If the logic is broken, the float is fiction — and so is every prioritisation decision built on it. Teams expedite activities that never mattered while genuinely critical work drifts, because the model told them it had six weeks of slack. We have written more about this in our article on float; the short version is that bad float does not announce itself. It just steers the project gently towards the rocks.

The second wave is contractual and loud. When delay turns into dispute, both parties reach for the programme record — and discover what state it is in. An unmaintained baseline means there is nothing credible to measure delay against. Updates that were never properly statused mean the as-built record has to be reconstructed from diaries and emails at eye-watering forensic cost. Logic that was broken at the time means the schedule cannot demonstrate what any event actually did to completion, however obvious it felt on site.

It is a general and well-worn observation among delay analysts and adjudicators that contested time claims tend to be decided substantially on which party's programme record is more credible — not on which party's site team worked harder. The tribunal was not there. All it has is the model, the updates, and the discipline (or lack of it) they reveal. A contractor with an honest, well-maintained programme and a genuine entitlement is in a strong position. A contractor with the same entitlement and a constraint-riddled, unstatused programme is asking the tribunal to take their word for it.

Quality is not accuracy

It is worth being precise about what quality is not. A high-quality schedule can be wrong. The estimator may have been optimistic, the ground conditions may surprise everyone, the logic may reflect a construction strategy that gets overtaken by events. That is fine — being wrong in a high-quality schedule is informative, because the model shows you exactly how wrong, where, and with what consequence. You can interrogate it, correct it, and learn from the variance.

A low-quality schedule cannot even be wrong honestly. When the dates come out of constraints rather than calculation, a variance between plan and actual tells you nothing, because the plan was never the output of a model in the first place. There is nothing to interrogate. The schedule is not a falsifiable statement about the project; it is a decorative assertion.

This distinction matters because teams routinely defend poor schedules by pointing at outcomes — "we hit the date, didn't we?" Hitting a date proves nothing about the schedule any more than arriving on time proves your watch works. Quality is about whether the instrument can be trusted, not whether this particular reading happened to coincide with reality.

How quality is measured

Schedule quality is assessed in three layers, and the order matters because each layer is meaningless without the one beneath it.

Structure asks whether the CPM engine can calculate honest dates at all: is the logic complete, are leads and lags within sensible limits, are hard constraints rare, is the critical path continuous and responsive? This is the territory of the DCMA 14-point check, with its familiar tripwires — missing logic at most 5% of activities, zero leads, lags on no more than 5% of relationships, at least 90% finish-to-start logic, hard constraints under 5%.

Maintenance asks whether the schedule is being kept honest over time: is it statused properly each period, with no forecast work behind the data date and no actuals ahead of it? Is the baseline preserved and controlled, or quietly re-saved whenever the news gets bad? Metrics like missed tasks and the Baseline Execution Index live here, and they are the ones that protect the evidential job of the schedule.

Realism asks whether anyone would actually build the project this way: are durations short enough to be statused honestly, is float distributed plausibly, are resources loaded where the contract demands it? A structurally perfect schedule full of six-month bars and ten-month float pockets passes the engine test and fails the sniff test.

The pyramid is also a repair sequence. There is no point arguing about whether a duration is realistic while the activity has no successor: fixing the logic will change its float, its dates and possibly its criticality, and the realism conversation will need to happen again anyway. Structure first, then maintenance, then realism — credibility is what you get when all three hold.

Quality decays, and so do the decisions built on it

Here is the part that single audits miss: schedule quality is not a property of a file, it is a property of a process. A programme that scored well at baseline can rot through a dozen updates — a few open ends introduced by hurried revisions, a constraint added to calm a nervous client, a fragment of out-of-sequence work never repaired. Each individually looks harmless. Cumulatively, the model drifts away from the project until the float is noise and the critical path is a rumour.

And decision quality follows it down, with a lag. For the first few updates after the rot sets in, people still trust the numbers — that is the most dangerous window, because confident decisions are being made on a model that has quietly stopped deserving confidence.

Quality is a habit, not an audit

The teams whose programmes survive contact with a dispute are not the ones who passed a single heroic audit before submission. They are the ones for whom checking is boring: the 14-point run on every update, the open ends repaired in the same revision that created them, the baseline treated as a controlled document rather than a suggestion. In our experience the difference between those teams and everyone else is not skill — it is cadence. Quality measured once is a snapshot of a moving object. Quality measured every period is a record, and records are what win arguments.

Define it simply, then: schedule quality is the demonstrated, ongoing fitness of the programme to predict, to coordinate, and to stand as evidence. Two of those jobs you feel every week. The third you feel exactly once — and by then it is far too late to start.