Schedule quality vs schedule realism

Last reviewed 9 September 20262,855 words13 min read

Passing every check is not the same as being achievable

🟩 In one line Quality is whether the schedule is built correctly. Realism is whether it describes something that can actually happen. Software tests quality. Only judgement tests realism. The industry has become very good at the first and is quietly losing the second — and most late projects had a schedule that passed every metric.

👤 Who this is for Mid-level planners who've noticed the gap between "the schedule scores 94%" and "we're two months late." Reviewers who suspect they're checking the wrong things. Senior planners and PMs who need a language for saying "this is a good file and a bad plan" — or the reverse.

e / c

First, let's be honest about why this page exists

Somewhere around 2010, the DCMA checks became universal, schedule-checking software became affordable, and a strange thing happened: schedules got structurally better and no more accurate.

You can see it on any large programme. The baseline scores 92% in Fuse. No open ends, no leads, FS at 93%, three declared constraints. It's a beautiful piece of network engineering. And it assumes a 6-day cycle on a floor that's never been built faster than 8, a supplier lead time from a quotation nobody confirmed, and a client approval turnaround that the client has never once met. The project is late from the day the baseline is signed. The schedule never says so, because none of those things is a metric.

This page is about naming the two things separately — so that when someone says "the schedule's fine, it passed," you can say which fine they mean, and so that reviews, basis memos and recovery plans deal with both.

🟨 The standard — what "good" looks like

The distinction runs through the standards, though rarely under these names:

GAO Schedule Assessment Guide — four characteristics: comprehensive and well-constructed (quality), credible and controlled (realism and maintenance). GAO is explicit that a schedule can be well-constructed and not credible. Best Practice 6 (schedule risk analysis) and BP 7 (horizontal and vertical traceability) sit squarely on the realism side.
AACE RP 48R-06 (Schedule Constructability Review) — an entire recommended practice devoted to realism: does the schedule reflect a practicable construction approach, given the site, the method, the resources and the sequence a competent contractor would follow?
AACE RP 57R-09 (Integrated Cost and Schedule Risk Analysis) and RP 64R-11 (CPM Schedule Risk Modelling) — realism assessed statistically: given uncertainty in the durations, what's the probability of the finish?
NEC4 Cl. 31.3 — two of the four grounds for rejection are realism grounds: "the Contractor's plans which it shows are not practicable" and "it does not represent the Contractor's plans realistically." Neither can be tested with software.
SCL Protocol, 2nd ed., Guidance Part B §1 — the accepted programme should be "a realistic representation of the contractor's intentions." The Protocol goes on to caution that a programme that is structurally sound but unrealistic is a poor baseline for delay analysis, because it will attribute to events delay that was always going to happen.
DCMA 14-point — quality metrics only, by design. The DCMA's own guidance describes them as a first screen before substantive review. The metrics were never intended to certify achievability.

🟢 The way to think about it: quality checks answer "if the assumptions are right, will the schedule calculate correctly?" Realism checks answer "are the assumptions right?" You need both. Neither substitutes for the other.

How it actually works

What quality measures

Everything on the DCMA list and its relatives. Whether the network is closed. Whether relationships are the sensible types. Whether constraints are few and declared. Whether durations are short enough to status. Whether the data date is respected. Whether the critical path is connected to the finish.

These are properties of the file. They can be tested without knowing anything about the project. A reviewer in London can check the logic density of a schedule for a site in Jubail they've never seen, and be right.

Why they matter: a schedule that fails quality checks produces wrong arithmetic. Its float is fake, its critical path is disconnected, its updates won't behave. Nothing built on it — forecasts, EVM, delay analysis — can be trusted. Quality is a precondition.

What realism measures

Whether the durations correspond to quantities, crews and rates that exist. Whether the sequence is one a builder would follow on this site with this access and this crane. Whether the calendars reflect this location's working year. Whether the scope is all there — including the client's obligations, the authorities, the utilities, the commissioning. Whether the procurement lead times are confirmed or hoped. Whether the resource peak is a number the site can house and feed. Whether there is any float at all for the things that always go wrong.

These are properties of the project, expressed through the file. They cannot be tested without knowing the job. The London reviewer needs the drawings, the method, the site, and someone who's built one of these before.

Why they matter: a schedule that fails realism produces correct arithmetic on wrong inputs. Every date is precisely calculated and precisely wrong. And because it's structurally sound, nothing flags it. It passes review. It becomes the baseline. Every update is measured against it, every slip is attributed to an event, and the fact that the plan was never achievable disappears into the record.

Where they interact

Quality failures usually hide realism problems. A schedule with open ends and 60-day activities is so obviously rough that nobody trusts its dates. The realism question doesn't arise because nobody's taken the dates seriously yet.

It's the high-quality unrealistic schedule that does damage — because it looks trustworthy. The bars are clean, the metrics are green, the critical path tells a story. People believe it. Money gets committed against it. And the first the project knows about the problem is month six.

There's a subtler interaction too. Gaming quality metrics degrades realism. Split a 60-day fabrication into two 30-day halves to pass Metric 8 — now the halves have to be statused separately and there's no physical boundary between them, so the progress data is fiction. Delete a contractual constraint to pass Metric 5 — now the schedule doesn't know about a date the contract cares about. Every shortcut taken to green a metric makes the schedule slightly less like the project.

How to test realism

There's no software for it. What there is:

1. Duration basis. Every duration on or near the critical path should trace to quantity ÷ (crew × rate). If it doesn't, ask. If the rate is outside the range in the benchmarks section for that trade and region, ask why. (Full method: justify-a-duration.)

2. Sequence against method. Read the method statement, then read the logic. Where they disagree, one of them is wrong. Walk three chains in detail — a repeating floor, a system from procurement to commissioning, the envelope.

3. Scope walk. Drawing register, BOQ, contract obligations, authority processes. Tick each one against the schedule. What's missing is usually procurement, approvals, utilities, commissioning, and the client's own actions.

4. Calendar check. Location, season, festivals, statutory hours. A Gulf schedule with one flat calendar across two summers and two Ramadans is optimistic by 4–8 weeks before anything happens.

5. Resource sanity. Peak headcount versus camp capacity. Concrete rate versus plant and pump capacity. Crane hours versus lifts required. Simple arithmetic, done once, catches most of it.

6. Float distribution. Where's the room? None anywhere means a plan that fails on the first event. Lots everywhere means missing logic. Some, in known places, deliberately — that's a plan.

7. History. What did this contractor, this client, this trade actually achieve last time? Cycle times, approval turnarounds, mobilisation periods. The past is the best realism check there is, and it's usually ignored because the tender needed a number.

8. Risk analysis, if the stakes justify it. A QSRA puts numbers on the gap: the deterministic date is 30 September; the P50 is 3 November; the P80 is 12 December. That's the realism problem quantified. (Section 13.)

🟥 Where people go wrong

1. Treating the metric score as the review. "Scores 91%, accept." The score measures build quality. It says nothing about the DEWA connection that isn't in the schedule.

2. Baselining a tender schedule without a realism pass. The tender programme was built to win — compressed to the contract period, with durations from the estimator's rates and lead times from quotations. It was never a plan. Converting it to a baseline by adding logic and passing DCMA produces a high-quality file describing the bid, not the build.

3. Confusing "tight" with "unrealistic." A tight schedule can be entirely realistic — short durations with a basis, a thin critical path with a plan for it, minimal float because the contract period is genuinely short. Realism isn't about generosity. It's about whether the numbers correspond to anything.

4. Fixing quality problems in ways that damage realism. Splitting activities arbitrarily. Deleting contractual constraints. Adding links to the finish milestone to clear open ends. Each greens a metric and makes the file a little less like the project.

5. Assuming the client's approval times are the ones in the contract. The contract says 14 days. The client's actual median, from the submittal log, is 31. A realistic schedule uses 31 and notes the contract says 14 — that gap is a future claim, documented in advance. A "quality" schedule uses 14, passes, and generates a delay event every submittal.

6. Never revisiting realism after baseline. Realism decays. The supplier lead time that was confirmed in month one changes in month eight. The productivity assumed for summer turns out to be 40% lower. A schedule that was realistic at baseline and structurally perfect at every update can still be describing a project that no longer exists. The monthly trend — slippage-and-trend-analysis — is the realism check for live schedules.

7. Not saying which one you mean. "The schedule's good." Built well, or achievable? "The schedule's rubbish." Broken network, or fantasy durations? The two need different fixes — an afternoon of logic surgery versus a re-plan with the site team — and conflating them wastes the wrong person's time.

⚖️ When you're challenged

"It passed every check. What's the problem?" "It's built correctly. The problem is what it's built from. The structure cycle is 6 days and we've never done better than 8 on this slab type. The façade approval is 3 weeks and the consultant's log shows 9. Those aren't metric failures; they're inputs. Fix the inputs and the finish moves 6 weeks — which is the real finish, and better to know now."

"So you want us to pad it?" "No. I want the durations to trace to something. If the 6-day cycle has a basis — extra crane, precast, night shift — show me and I'll accept 6. If it's the tender number, then 8 isn't padding, it's the plan."

"The client rejected it for realism. Isn't that subjective?" Partly, and that's why the rejection has to be specific. "Ask them which activities and on what basis. If they say 'A2140, 1,800 m² blockwork in 10 days with one crew, implies 30 m²/man-day against a typical 10–12,' that's not subjective — that's arithmetic, and we either show our basis or revise. If they just say 'durations appear aggressive,' that isn't a valid ground and we can say so."

"We've got a realistic schedule but it fails DCMA. Which matters?" "Both, but fix quality first — it's quicker and it's a precondition. A realistic plan in a broken network still gives wrong float and a disconnected critical path. Clean the structure, then the realism is visible and defensible."

"The PM wants the baseline to show the contract date. It doesn't fit." The oldest problem in the discipline. "Then we have three honest options. Show what fits and flag the gap now — that's a contract conversation, and it's easier before we start than after. Show the contract date with an explicit recovery plan — extra resource, re-sequencing — costed and owned. Or show the contract date with durations that have no basis, and spend three years explaining monthly slippage against a plan that was never real. I'd recommend the first two. I won't do the third."

📄 Related pages

DCMA 14-point assessment — the quality checks, in full
How to review a schedule — Part 1 is quality; Part 2 is realism
Justify a Duration — the realism check for individual activities
Crew and Manhour Formulas — the arithmetic durations should trace to
Productivity Adjustment Factors — summer, Ramadan, height, congestion
Calendar Setup and Holidays — the calendars a Gulf schedule actually needs
Tender Programme — why tender schedules aren't baselines
Baseline Approval and Control — the conversation before signing
Schedule risk analysis basics — realism quantified
Benchmarks — the rates to check durations against
Gao schedule assessment guide — the framework that separates the two properly

✏️ Worked example

Two baselines for the same eight-storey car park in Riyadh. Post-tensioned flat slabs, 1,600 m² per floor, one tower crane. Contract period 14 months. 6-day calendar.

Baseline A — the tender schedule, tidied.

Aspect	Value	Quality check	Realism check
Open ends	2	Pass	—
Leads / lags	0 / 3.1%	Pass	—
FS share	94%	Pass	—
Constraints	2, both contractual	Pass	—
Slab cycle	6 days/floor	(not a metric)	Contractor's last three PT car parks: 8, 9, 8 days. No change in method. Unsupported.
PT stressing	Included in cycle	—	Stressing at 3 days requires 70% strength; mix design achieves it at 4. Physically impossible at 6-day cycle.
Summer calendar	None; 6-day 8-hr throughout	(not a metric)	Structure runs June–September. Midday break rule reduces external hours ~25%. Not reflected.
Ramadan	Not calendared	—	Falls in month 5, mid-structure. Not reflected.
Authority (Civil Defence, Municipality) approvals	Not in schedule	—	~10 weeks combined before handover. Scope missing.
Float	Structure and finishes both within 2 days of critical	(not a metric)	No capacity for any event.
Fuse score	93%	—	—
Finish	On contract date	—	—

Baseline B — rebuilt with the site team, two weeks later.

Aspect	Value	Quality check	Realism check
Structural metrics	All pass	Pass	—
Slab cycle	8 days/floor; 9 in summer months	—	Matches history; stressing at day 4
Summer calendar	Separate calendar, reduced hours June–Sept, applied to structure and external	—	Reflects statutory rule
Ramadan	Reduced-hours calendar, month 5	—	Reflected
Authority approvals	6 activities, 10 weeks, linked to handover	—	Scope present
Float	3 weeks terminal float; finishes path ~8 days behind structure	—	Deliberate, documented
Fuse score	94%	—	—
Finish	6 weeks after contract date	—	—

Baseline A passed every quality check and was six weeks wrong before mobilisation. Baseline B passed the same checks and told the truth — which was that the contract period didn't fit the method, and that either the method changed (second crane, precast stair cores, extra PT crew — all costed) or the date did.

That conversation happened in week two, on paper, with numbers. Under Baseline A it would have happened in month seven, on site, as an argument about whose fault the slippage was — with a "compliant" baseline as the yardstick, and every week of the six attributed to something other than the plan.

The Fuse scores were one point apart. That's the whole page.

📖 References

US GAO, Schedule Assessment Guide (GAO-16-89G) — the four characteristics; Best Practices 3, 6, 7
AACE International, RP 48R-06, Schedule Constructability Review
AACE International, RP 57R-09, Integrated Cost and Schedule Risk Analysis Using Monte Carlo Simulation
AACE International, RP 64R-11, CPM Schedule Risk Modelling and Analysis
NEC4 ECC — Cl. 31.3
SCL, Delay and Disruption Protocol, 2nd ed. (2017) — Guidance Part B §1, Core Principle 1
DCMA, 14-Point Schedule Assessment — introductory guidance on the purpose of the metrics

From the field

Experience from working planners. Unreviewed — read it as experience, not guidance.

Add what you know about schedule quality vs schedule realism. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.

Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.

Add your experience