How to review a schedule

Last reviewed 9 September 20263,302 words15 min read

The order to check things in, and what to say

🟩 In one line A schedule review isn't a DCMA run with commentary. It's three questions in a fixed order: is it built properly, does it describe this job, and can it be done? Most reviews stop after the first. The value is in the second and third — and in writing comments the other side can actually act on.

👤 Who this is for Client-side and consultant planners reviewing contractor submissions. Contractor planners reviewing subcontractor programmes. Anyone about to be handed a 3,000-activity XER and asked "is this any good?" Also the contractor's planner, because knowing how you'll be reviewed is the best way to prepare.

e / c

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

Most schedule reviews are bad. Not because the reviewer is careless, but because nobody was ever shown how to do one. The usual pattern: open the XER, run a checker, print the metric failures, add a few comments about milestones, send it back. Three days later the contractor has fixed the leads and the open ends and resubmitted, and the review starts again — on a schedule that still doesn't reflect the method, still has a six-week logistics hole in the tower crane sequence, and still assumes the client will approve shop drawings in five days.

The mechanics matter. But they're the first pass, not the review. A schedule can be structurally perfect and describe a project that doesn't exist. Catching that requires reading the schedule against the drawings, the method statement, the site, and the contract — which takes longer, and which is the actual job.

This page is the sequence. Part 1 is fast and mechanical. Part 2 is where you earn your fee. Part 3 is what you write.

🟨 The standard — what "good" looks like

The standards describe what a schedule should contain far more than how to review one. What there is:

AACE RP 53R-06 (Schedule Update Review) — the closest thing to a review procedure. Sequence: verify data date and progress; check for changes from the prior schedule; check logic and constraints; assess the critical path and float; assess the forecast. Update-focused, but the structure transfers.
AACE RP 48R-06 (Schedule Constructability Review) — the standard for the realism half: does the schedule reflect the means and methods, the site conditions, the sequence a builder would actually follow?
GAO Schedule Assessment Guide — ten best practices grouped into four characteristics: comprehensive, well-constructed, credible, controlled. That grouping is a better review framework than the DCMA list, because it separates structure from substance.
NEC4 Cl. 31.3 — the Project Manager has two weeks to accept or reject a programme, and may only reject for four stated reasons: the Contractor's plans aren't practicable; it doesn't show the information the contract requires; it doesn't represent the Contractor's plans realistically; or it doesn't comply with the Works Information. Note that "fails DCMA" is not one of the four. Practicable and realistic are.
FIDIC 2017 Cl. 8.3 — the Engineer has 21 days to give notice that the programme doesn't comply with the contract or is inconsistent with actual progress. Silence is deemed acceptance.
Gulf client specs — typically prescribe the DCMA checks plus a list of required content (WBS, coding, calendars, milestones, resource loading, narrative). Rarely say anything about realism. That gap is yours to fill.

🟢 The contractual point most reviewers miss: under NEC and FIDIC, the reviewer has a deadline and a limited set of grounds. A review that's late or that rejects on grounds the contract doesn't recognise can itself become a problem — deemed acceptance under FIDIC, or a compensation event under NEC if the rejection was unjustified. Review properly, on time, on the right grounds.

How it actually works

Before you start — thirty minutes

Get the whole package, not just the XER. Narrative, basis memo, method statement, milestone schedule, resource histograms, any drawings or phasing plans referenced. If the submission is XER-only, that's your first comment.

Read the narrative first. It tells you what the contractor thinks the schedule shows. Then when you open the file, you're checking whether it does.

Know the contract. The key dates, the sections, the access dates, the programme clause, the review period, the grounds for rejection. Have it open.

Import to a clean, isolated EPS node. Never into a shared database. Check the import log for calendar or code conflicts. If it won't import cleanly, that's a comment too — but see xer-file-wont-import before you blame the contractor.

Part 1 — Is it built properly? (half a day)

The mechanical pass. This is where DCMA lives, and it should be quick.

1. Data date and scheduling options. Project → Dates; Tools → Schedule → Options. Data date matches the cut-off. Retained Logic. Longest Path for criticality. Lag calendar stated and sensible. If any of these are off, the dates aren't comparable and you should say so before commenting on them.

2. Run the fourteen. Schedule log, filters, or a checker. Record the results in a table. For each trip-wire, look at which activities — don't just note the percentage.

3. Structure. WBS matches the contract breakdown and the drawings. Coding allows the views the spec requires (by zone, discipline, subcontractor). Calendars: how many, what they are, whether they match the working week and holidays for the location.

4. Milestones. Every contractual milestone present, correctly named, correctly constrained (or not), correctly dated. This is a table: milestone, contract date, schedule date, variance.

5. Critical path test and longest path. Run the 600-day push in a copy. Then filter Longest Path and read it end to end. Does it make sense as a story? Structure → envelope → MEP → commissioning is a story. Structure → external works → commissioning is a red flag.

6. Change from the previous submission (if there is one). Schedule Comparison. Every non-progress change listed. Cross-check against the change log in the narrative. Unexplained changes are a comment each.

At the end of Part 1 you have a table of mechanical findings. Don't send it yet. On its own it produces the fix-and-resubmit loop.

Part 2 — Does it describe this job, and can it be done? (one to three days)

This is the review. It needs the drawings, the method, and ideally a walk round the site or a conversation with someone who's been.

7. Scope completeness. Walk the drawing register and the BOQ against the schedule. Is every major element present — every building, every system, every external? Is procurement there, with submittals, approvals, fabrication, delivery, all linked? Is commissioning there in enough detail to be statused — by system, not one "testing & commissioning" bar? Are the client's own obligations there — approvals, free-issue materials, access, permits? Missing scope is the commonest realism failure, and no metric catches it.

8. Sequence and method. Does the logic match how a builder would do this? Read three or four chains in detail — a typical floor, a typical MEP system, the external envelope. Check the sequence against the method statement. Look for physically impossible overlaps (cladding on a floor whose slab isn't poured; ceilings closing before above-ceiling inspection). Check temporary works, crane and hoist logic, and access — the things that aren't in the drawings.

9. Durations. Sample twenty or thirty against quantities and typical rates. Not all of them; the ones on and near the critical path, and the ones that look short. A 10-day blockwork activity for 1,800 m² with one crew is a comment. So is a 5-day client approval. Ask for the duration basis where it isn't obvious.

10. Resources and logistics. If loaded: does the histogram peak at a number the site can accommodate — accommodation, transport, welfare? Does the concrete pour rate exceed what the batching plant and pump fleet can deliver? Does the crane schedule allow the steel and precast rates the schedule assumes? If not loaded, ask the questions anyway.

11. Calendars and seasons. Ramadan hours reflected? Summer midday break (Gulf, June–September) in the calendar for external work? Monsoon or rain allowance where relevant? Eid shutdowns? A schedule with one 6-day calendar and no seasonal adjustment on a two-year Gulf job is optimistic by a month or more before anything goes wrong.

12. Interfaces and dependencies on others. Utility connections, authority approvals, other contractors, client-supplied items. Each should be a milestone or activity with a source. A civil works schedule that assumes DEWA power on a date nobody has agreed is not a schedule.

13. Risk and float distribution. Where's the float? A schedule where every path is within 3 days of critical has no room for anything. One where the critical path is thin and everything else has 60 days has probably got missing logic. Is there any explicit allowance — weather, time risk, terminal float? Where is it, and is it sensible?

14. Read the forecast against your own judgement. After all that: would you bet on this finish date? If not, why not — and is the reason already in your comments? If it isn't, keep looking.

Part 3 — Writing it up

A comment sheet, one row per comment. Every comment needs:

Column	What goes in it
Ref	Sequential number, so it can be tracked to close-out
Category	Structural / Content / Realism / Contractual
Activity or area	Specific IDs, WBS node, or milestone name — never "various"
Observation	What you found, stated as fact, with the number
Basis	Why it matters — spec clause, contract clause, DCMA metric, physical reason
Required action	What would close the comment
Severity	Must fix before acceptance / Fix in next update / Note

Then a cover page: overall recommendation (accept / accept with comments / reject, with the contractual ground), the milestone variance table, the longest path in ten lines, and the three or four things that matter most.

What to say and what not to say:

Facts, with numbers. "41 incomplete activities have no successor (Metric 1: 3.1%). List attached." Not "there are open ends."
Specific to the activity. "A2140 Blockwork L4 — 1,800 m² in 10 wd with one crew of 6 implies 30 m²/man-day; typical is 10–12. Please provide basis or revise." Not "some durations appear optimistic."
The action that closes it. "Link the 22 submittal activities to their respective PO activities." Not "address the logic."
The contractual ground, when rejecting. Under NEC, one of the four in Cl. 31.3. Under FIDIC, non-compliance with Cl. 8.3 or inconsistency with actual progress.
Nothing about the contractor's competence, intent, or honesty. Ever. It's a document review.

🟢 One habit that transforms reviews: before sending, sort the comments by severity and count the "must fix" ones. If there are more than about fifteen, the schedule should probably be rejected and rebuilt rather than patched. If there are fewer than five, it should probably be accepted with comments — don't hold a good schedule hostage to Metric 3.

🟥 Where people go wrong

1. Stopping at Part 1. The mechanical checks are twenty percent of the review and eighty percent of what most reviewers send. The result is a clean schedule for a project that can't be built.

2. Rejecting without a contractual ground. "Fails DCMA" is not a ground under NEC or FIDIC. If the schedule shows the information the contract requires, is practicable, and represents the contractor's plan realistically, it should be accepted — with comments — even if the lag count is 7%. Rejecting it anyway creates risk for the client.

3. Missing the review deadline. FIDIC: 21 days, then deemed accepted. NEC: 2 weeks, or a longer agreed period. A late review can be worse than no review. Diarise it on receipt.

4. Commenting on style rather than substance. Activity naming conventions, colour schemes, WBS depth. Unless the spec mandates them, these are notes, not findings. Spending three comments on naming and none on the missing commissioning scope tells the contractor what you didn't look at.

5. Vague comments. "Logic to be reviewed." "Durations appear aggressive." "Consider resource loading." None of these can be closed, because none of them says what closed looks like. The contractor guesses, resubmits, and you're back in the loop.

6. Reviewing the XER without the narrative. Half the questions you'd raise are answered in the basis memo — if you read it. Comments that are already addressed in the narrative waste everyone's time and undermine the rest of the review.

7. Reviewing in isolation from the site. A desk review can find structural faults. It can't tell you the tower crane can't reach the east wing, or that the access road floods, or that the client's approval process takes six weeks not two. Talk to the RE, the site team, the design manager. Twenty minutes each.

8. Accepting a baseline that fails the critical path test. Of all the mechanical checks, this is the one that should never be waived. If pushing the critical path doesn't push the finish, the float on the whole schedule is fiction, and every subsequent update and delay analysis inherits the problem.

⚖️ When you're challenged

"You've had it three weeks. Where's the review?" If you're over the contractual period, you may already have deemed acceptance. Don't pretend otherwise. "The 21 days under 8.3 expired on Date. The programme is deemed accepted as the Cl. 8.3 programme. I'll issue my comments as observations for the next revision; they don't affect acceptance." Then make sure it doesn't happen again.

"We fixed everything on your list. Why is it rejected again?" Usually because the list was Part 1 and the second review did Part 2. That's the reviewer's fault for splitting it. "The first review was structural and you've closed it, thank you. The second pass against the method statement and drawings raised the scope and sequence items in Section B. I should have issued both together — apologies. The Section B items are the ones that affect acceptance."

"The contractor says our comments are outside the contract." Check. If you've rejected an NEC programme because durations "seem aggressive" without showing they're impracticable, they're right. Restate the comment with its basis — quantity, rate, crew, the number that doesn't work — or withdraw it.

"The schedule passes every metric. Why won't you accept it?" "Because it doesn't include the authority approvals for the substation, the tower crane can't reach Zone D as sequenced, and the summer calendar has no midday break on external works. Those are realism failures, not metric failures. They're in comments 4, 11 and 15 with the basis for each. Passing DCMA means it's well built. It doesn't mean it's buildable."

📄 Related pages

DCMA 14-point assessment — Part 1, in full
Schedule quality vs schedule realism — why Part 2 exists
Schedule review comment sheet — the comment format, as a template
Client schedule specifications — what to check the submission against
What the contract says about the programme — the review periods and grounds, by contract form
Construction Sequencing and Method — reading the logic against the method statement
Calendar Setup and Holidays — Ramadan, summer break, Eid
Commissioning and Handover Planning — what the end of the schedule should contain
Worked example schedule review — a full review, comment sheet and cover page

✏️ Worked example

A consultant's first review of a contractor's baseline for a mid-rise commercial building in Dubai. 2,100 activities. Contract: FIDIC 1999-based, 21-day review period.

Part 1 findings (four hours):

Ref	Category	Finding	Severity
1	Structural	27 open ends beyond the two milestones; 19 are submittals with no successor	Must fix
2	Structural	6 leads (FS−2 to FS−5) on internal finishes	Must fix
3	Structural	Lags 6.8%; 88 of 102 are cure lags, remainder are FF+10 on MEP second-fix — work	Fix in next
4	Structural	8 Finish On constraints on non-contractual dates	Must fix
5	Structural	Critical path test: 600d push moved finish 600d. Pass	—
6	Structural	Longest path: piling → raft → structure → cladding → lift installation → T&C → TOC. Coherent	—
7	Contractual	All 6 contract milestones present, dates match Appendix to Tender	—

Seven comments, four must-fix, all fixable in a day. On its own, this would be "reject, resubmit." The reviewer kept going.

Part 2 findings (two days, including a site visit and an hour with the design manager):

Ref	Category	Finding	Basis	Severity
8	Content	No activities for DEWA power connection application, inspection or energisation. Building T&C depends on permanent power	Cl. 4.x / DEWA process ~16 weeks	Must fix
9	Content	Façade shop drawing approval shown as one 15-day activity. Design manager confirms 3-cycle process typical, ~9 weeks	Consultant's own history	Must fix
10	Realism	Structure cycle 7 days/floor for 1,100 m² PT slab with one crane. Method statement says 2 crane lifts per pour; crane schedule allows ~5 cycles per floor per day. Cycle unachievable below ~9 days	Method statement §4; crane data	Must fix
11	Realism	Single calendar, 6-day, 8 hrs. No summer midday-break calendar on external works (June–Sept). Cladding runs through July–August at full rate	UAE MoHRE midday break rule	Must fix
12	Realism	Ramadan 2026 falls in structure phase; no reduced-hours calendar	Calendar review	Fix in next
13	Content	Commissioning shown as 4 activities totalling 45 days. No system-level breakdown; cannot be statused	Spec §7.4 requires system-level T&C	Must fix
14	Realism	Tower crane dismantle shown 3 weeks before final lift commissioning; lift motor room requires crane for hoisting. Sequence conflict	Method statement §9; lift contractor drawings	Must fix
15	Realism	Float: 62% of activities within 5 days of critical. No time risk allowance, no terminal float. Programme has no capacity to absorb any event	Float distribution analysis	Note — raise at meeting

The write-up: rejected under Cl. 8.3 as not compliant — missing required scope (comments 8, 13), inconsistent with the method statement (10, 14). Cover page led with those four, then the calendar issue, then the structural fixes. Total review: two and a half days. Issued on day 12 of 21.

What happened next: the contractor's resubmission moved Taking Over by 7 weeks. The PM was unhappy; the contractor was unhappy; the reviewer had a difficult meeting. But the seven weeks were real — the DEWA process alone was four months nobody had planned — and they were found before construction started rather than in month fourteen. A Part 1 review would have accepted a schedule that was seven weeks wrong on day one, and every EOT argument for the next two years would have started from there.

📖 References

AACE International, RP 53R-06, Schedule Update Review
AACE International, RP 48R-06, Schedule Constructability Review
US GAO, Schedule Assessment Guide (GAO-16-89G) — Best Practices 1–10; four characteristics
NEC4 ECC — Cl. 31.2, 31.3, 32.1
FIDIC Red Book 1999 — Cl. 8.3; FIDIC Red Book 2017 — Cl. 8.3
SCL, Delay and Disruption Protocol, 2nd ed. (2017) — Guidance Part B §1

From the field

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

Add what you know about how to review a schedule. 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