What Owners Should Check in a Baseline Schedule Submittal

The baseline schedule is the yardstick every later delay, time extension, and recovery argument gets measured against. Accepting a weak one is easy and expensive: the problems don't show up until month eight, when they're attached to a claim. This post is a review checklist for owners and owners' reps. It covers what to check for contract compliance, how to test the logic, how to judge the critical path and durations, and how to write the response. You don't have to be a scheduler to do most of it, but you do need the native file.

Start with what was submitted

Before reviewing the content, confirm the package is complete. A baseline submission should usually include:

The native schedule file (for P6, an .xer export), not just a PDF.
A narrative explaining the approach, sequence, critical path, assumptions, calendars, and anything unusual.
Standard reports or layouts the spec requires: a Gantt sorted by WBS or area, a critical path report, a list of milestones.
Cost or resource loading reports, if the spec requires loading.

If the native file is missing, stop and ask for it. A PDF Gantt can't be tested; it can only be looked at.

Contract compliance

Read the schedule against the contract, not against your sense of the project. Your spec is the rulebook; see Reading a Schedule Spec: Section 01 32 16.

The data date and start match notice to proceed, or the spec's instruction.
The substantial completion date matches the contract, or the narrative explains an early finish. If it finishes early, settle what happens to the gap now. See Who Owns the Float?.
Every contract milestone is present: phase turnovers, owner move-in dates, interim completions, utility cutovers.
Milestones are driven by logic, not just pinned with a constraint.
Owner-furnished items and owner contractor work are shown, with dates you can actually meet.
Owner review periods for submittals and RFIs match the contract. A baseline that gives the architect 5 days to review a shop drawing when the contract allows 14 is setting up a delay claim.
Required activity types are present: submittals, procurement, fabrication, deliveries, inspections, testing, commissioning, punch list, closeout.
Calendars include holidays and the anticipated weather days the spec requires.
Activity codes required by the spec are populated.

Logic and structural quality

This is where the native file earns its keep. The DCMA 14-Point Assessment is a common, well-understood set of checks for this. It was written for government programs, so treat its thresholds as screening guides rather than rules, but it catches most structural problems quickly. Details in The DCMA 14-Point Assessment, Explained for Construction.

Check	Commonly used threshold	What a failure usually means
Missing logic	5% or fewer incomplete activities	Open ends; work that can slip without moving anything
Leads (negative lags)	None	Logic that's hard to follow and easy to manipulate
Lags	5% or fewer relationships	Hidden durations between activities
Relationship types	90% or more finish-to-start	Heavy SS/FF use that may hide sequence
Hard constraints	5% or fewer activities	Dates forced instead of driven by logic
High float (over 44 working days)	5% or fewer activities	Missing successors or loose logic
Negative float	None in a baseline	The schedule can't meet its own dates
High duration (over 44 working days)	5% or fewer activities	Activities too coarse to status or analyze
Invalid dates	None	Actuals in the future or forecasts in the past
Critical path test	Passes	The critical path isn't actually continuous

The other DCMA checks (resources, missed tasks, CPLI, BEI) are about progress or loading and matter more in updates than in a baseline.

Things to look at by eye, because the counts don't catch them:

Open ends hidden by a single tie. Dozens of activities that all flow to the completion milestone directly, with no real successors. Technically logic, practically none.
Constraints on milestones the contractor controls. A finish-on constraint on "Building dry-in" makes the path to it look critical regardless of its logic.
Preferential logic. Independent areas linked in a strict sequence for no stated reason, producing a critical path through work that could run in parallel.

Run the critical path test yourself

Pick an activity on the reported critical path early in the job. In a copy of the file, add a large number of days to its duration, say 100, and recalculate. The completion date should move by exactly 100 days. If it moves less, something downstream is constrained or the path is broken. If it doesn't move at all, that activity wasn't really critical. Do this on two or three activities across the job.

The critical path makes sense

A logically valid schedule can still have an implausible critical path. Read it start to finish and ask whether it matches how this building gets built.

For a typical commercial building, you'd expect the critical path to run through something like site prep and foundations, structure, dry-in or enclosure, then interior rough-in and finishes or a long-lead system like elevators or switchgear, then inspections, commissioning, and TCO. If the critical path runs through landscaping or signage, the logic is probably wrong somewhere. If it runs through a submittal you've never heard of, ask.

Also look at the near-critical paths, those with a small amount of float. A baseline where four or five paths are all within a few days of critical is a risky plan, even if it's technically valid.

Durations are believable

You don't have to be an estimator. Spot-check the activities that matter most:

Long-lead procurement: switchgear, generators, elevators, curtain wall, rooftop units. Compare against what the design team and recent projects suggest, and ask for supplier quotes on the critical ones.
Inspections and utility work: permanent power energization, fire alarm acceptance, elevator inspection, final building inspection. These depend on third parties and are often shown too short.
Commissioning and closeout: often compressed in a baseline to make the end date work.
Any activity on the critical path with a suspiciously round long duration.

Cost loading, if required

If the schedule is cost loaded, check that the total equals the contract sum, that costs are on the activities where the work happens (not loaded early into mobilization or the first activities), and that the cash flow curve is plausible. Front-loading shows up as a steep early curve.

Writing the response

Use the spec's review categories, usually some version of accepted, accepted with comments, or rejected and resubmit. Then:

Number each comment and tie it to a specific activity ID or spec requirement.
Separate required corrections (spec non-compliance) from questions and suggestions.
Don't rewrite the contractor's means and methods. Ask about sequence that looks wrong; don't dictate a new one.
Respond within the contract's review period. A late review weakens your position on the schedule you later rely on.
Keep the submitted file and every resubmittal. The accepted one becomes the baseline; see Baselines: When to Set Them and When to Re-Baseline.

If you're reviewing in schedule.construction, you can import the contractor's .xer and run the DCMA-style quality checks against it before reading the narrative, which gives you a list of where to look first.

Checklist

Native file, narrative, and required reports are all included.
Start, completion, and every contract milestone match the contract and are logic-driven.
Owner activities and owner review periods match what you can actually deliver.
DCMA-style checks run; failures explained or corrected.
Critical path test passes on several activities.
Critical path reads like the way this building gets built.
Long-lead, inspection, and commissioning durations spot-checked.
Cost loading totals and distribution checked, if required.
Numbered, specific comments returned within the review period.