Baseline Schedule Review: The Complete Checklist for Reviewing Contractor Programmes

The contractor has submitted their baseline programme. It lands in your inbox as an XER file with 1,200 activities and a cover email saying “please approve.” What do you actually check, and what passes or fails?

A baseline schedule review is one of the most important quality gates on a construction project. Approving a flawed baseline means you inherit every problem it contains: hidden risks, unrealistic durations, and a programme that will not support you when delays happen, and they will. Flyvbjerg’s database of 16,000 projects shows 91.5% finish over budget, over schedule, or both; many of those projects were set up to fail at the baseline stage. The Holyrood Parliament Building in Scotland, which opened three years later than originally programmed with a final outturn of approximately £431 million against an initial estimate of around £40 million at the start of construction (Auditor General for Scotland, 2004), ran into problems that a more rigorous baseline review could have surfaced before construction began.

This guide gives you a structured, checklist-driven approach to reviewing a contractor’s baseline schedule, explains how to use the DCMA 14-Point Assessment as part of your review, and shows what to check at each periodic update. It complements a complete construction schedule analysis by focusing on the gate before progress reporting begins.

What Is a Baseline Schedule Review?

A baseline schedule review is the systematic evaluation of a contractor’s submitted baseline programme before it is formally approved. It happens after contract award but before the first progress update. This is your one chance to set the standard for schedule quality on the project.

The review is typically performed by:

Owner representatives responsible for approving the programme
Construction managers assessing whether the schedule is realistic and buildable
Project controllers checking schedule quality, logic, and compliance
Claims consultants reviewing schedules that were approved without proper assessment

A baseline review is different from a periodic update review. The baseline review establishes whether the schedule is sound before work begins. Update reviews track whether the schedule remains sound as the project progresses. Both matter, but the baseline review is the foundation; get this wrong, and every subsequent review is compromised.

Why Baseline Schedule Review Matters

Approving a bad baseline schedule is not a victimless act. It has real consequences that surface later in the project, usually when it is too late to fix them.

A flawed baseline undermines EOT claims. If the schedule logic was broken from the start, proving cause becomes hard. Was it the employer-caused event, or was it the missing logic tie that was never flagged? Expert witnesses in delay disputes routinely identify baseline defects that should have been caught at approval. Our guide to the extension of time claim process covers the contractual machinery that sits on top of the baseline.

It entrenches unrealistic expectations. Once a baseline is approved, it becomes the benchmark. If the benchmark is too optimistic, every variance analysis will show the project as behind, even if actual progress is reasonable for the work being done.

It gives away float. A baseline with excessive constraints or missing logic often inflates float on non-critical paths. Once approved, that float belongs to the project. You cannot get it back when you discover the logic was wrong.

Retrospective correction is expensive. Fixing a broken schedule mid-project is far harder than getting it right at the start. Logic changes, constraint removal, and resequencing all require contractor cooperation, which may not be forthcoming once the programme is approved.

What to Submit: Contractor Baseline Requirements

Before you can review a baseline, the contractor needs to provide the right material. As a minimum, a baseline submission should include:

The schedule file: typically an XER (Primavera P6) or MPP (Microsoft Project) file
Basis of Schedule narrative: a document explaining the planning assumptions, methodology, and constraints used to build the programme
Bar chart or Gantt chart: a visual representation of the schedule
Resource and cost loading: if contractually required
Contract compliance statement: confirmation that the schedule meets contractual requirements and milestones

If the contractor submits a schedule file with no supporting narrative, that is your first red flag. The Basis of Schedule is essential; it tells you the story behind the numbers.

The Baseline Schedule Review Checklist

1. Contract Compliance

Before diving into the schedule mechanics, check the contractual basics:

Are all contractual milestones represented with the correct dates?
Is the contract completion date achievable given the schedule logic?
Are required deliverables included (look-ahead programmes, resource histograms, cash flow forecasts)?
Are contractual notice periods reflected in the schedule logic?
Does the schedule comply with the specification’s requirements for activity detail level and update frequency?

Pass: All milestones present and achievable. Fail: Missing milestones or completion date contradicts the contract. Flag: Milestones present but achieved only through constraints, not logic.

2. Schedule Structure and WBS

The work breakdown structure (WBS) determines how the schedule is organised:

Does the WBS align with the contract scope of works?
Are work packages logically grouped (by trade, area, or phase)?
Is the activity coding consistent and meaningful?
Is the level of detail appropriate? Too few activities means insufficient detail; too many means the schedule is unmanageable

Pass: WBS mirrors the scope, coding is consistent, detail is appropriate. Fail: WBS does not reflect the contract scope or is missing major work packages. Flag: Detail is inconsistent; some areas are heavily detailed, others are summarised.

3. Logic and Dependencies

Logic is the backbone of any CPM schedule. Without sound logic, the critical path and float values are meaningless.

Open ends: activities with no predecessor (other than the project start) or no successor (other than the project finish). Every activity should connect to the network. A common threshold is that open ends should not exceed 5% of total activities.
Relationship types: are finish-to-start relationships used as the default? Start-to-start and finish-to-finish relationships are appropriate in some cases (overlapping activities) but should be justified. Too many non-FS relationships can indicate logic shortcuts.
Circular logic: a loop where an activity is both predecessor and successor of the same activity. Most scheduling tools flag these, but they can appear after data entry.
Redundant dependencies: duplicate ties that do not change the schedule calculation.
Hard constraints: fixed-date constraints that override logic. These should be limited to contractually required milestones (e.g., access dates, contractual milestones). A schedule with numerous hard constraints is a schedule where logic has been overridden to force dates.
Lag: lag should represent a physical or contractual delay between activities (e.g., concrete curing). Excessive lag, or lag hiding work that should be an activity, is a common schedule problem.

Pass: Logic is complete with no open ends (beyond start/finish), constraints are limited to contractual milestones, lag is justified. Fail: Excessive open ends, hard constraints overriding logic, or circular logic detected. Flag: Multiple start-to-start relationships or lag above 5 days; review the Basis of Schedule for justification.

4. Activity Durations

Are durations realistic for the scope and resources assigned?
Are there excessively long activities? The DCMA 14-Point threshold is 44 working days; activities longer than this should be broken into smaller components.
Are there unreasonably short activities (less than 1 day) that may be milestones or constraints masquerading as tasks?
Are durations consistent with the resource assignments? A 5-day activity with 50 workers assigned may not reflect the actual work content.

Pass: Durations fall within reasonable ranges, no activities exceed the long-duration threshold. Fail: Durations are clearly unrealistic or multiple activities exceed the threshold without justification. Flag: Activities under one day or over the 44-working-day threshold need a closer look.

5. Critical Path Analysis

The critical path drives the project. If it is wrong, nothing else matters.

Is the critical path clearly identifiable and does it pass through activities that make engineering sense?
Does it match the construction logic; does it follow the actual sequence of work?
Are there near-critical paths with less than 5 days of total float? Paths this close to critical represent significant risk.
Is there artificial float? Hard constraints and missing logic can make activities appear to have float when they should be critical.
Does the total float distribution make sense? A schedule where most activities have float well above 44 working days (the DCMA High Float threshold) may be missing logic ties.

Pass: Critical path is logical, near-critical paths are identified, no artificial float. Fail: Critical path does not reflect construction logic or passes through non-physical activities only. Flag: Multiple near-critical paths; the project has more schedule risk than the critical path alone suggests.

6. Calendars

Calendar assignments affect every duration calculation:

Are appropriate calendars assigned (5-day, 6-day, 7-day, weather-affected)?
Are public holidays and shutdown periods reflected?
Are calendar assignments consistent with the scope; does a 7-day calendar make sense for activities that require inspection or approvals typically done on weekdays?

Pass: Calendars are appropriate and justified in the Basis of Schedule. Fail: All activities on a default calendar with no consideration of working patterns. Flag: 7-day calendars assigned to activities that logically require weekday inspections.

7. Float and Constraints

Is total float within acceptable ranges? Negative total float on a baseline schedule means the programme cannot meet the contractual completion date. This is a hard fail.
Are constraints used sparingly? Most specifications limit hard constraints to contractual milestones.
Is float ownership addressed in your contract? The SCL Protocol §8.1 frames float ownership as a contested issue: a Contractor may claim it owns the float (because it built the float into its plan), while an Employer may say the project owns it (so an EOT only flows when contract completion is missed). §8.2 doesn’t pick a winner; it says the parties must address the issue in their contracts. Check the EOT clause: if an EOT only triggers when contract completion is missed, total float gets used up first; if an EOT triggers whenever Employer Delay slips the contractor’s planned completion, the float typically isn’t available to the Employer. Silent or ambiguous contracts produce disputes.

Pass: No negative float, constraints limited to contractual milestones, float distribution is reasonable. Fail: Negative float on baseline (unachievable programme), excessive hard constraints. Flag: Most activities sitting above the DCMA High Float threshold (44 working days), which may indicate missing logic.

8. Resources and Cost Loading

Are resources logically assigned to activities that require them?
Is there obvious over-allocation; a single team scheduled across multiple activities simultaneously?
Is the schedule cost-loaded where contractually required?
Is an earned value baseline established?

Pass: Resources assigned, no obvious over-allocation, cost loading meets contractual requirements. Fail: No resources assigned on a contractually resource-loaded schedule, or gross over-allocation. Flag: Resources assigned but not levelled; indicates potential scheduling conflict.

Running the DCMA 14-Point Assessment on a Baseline Schedule

The DCMA 14-Point Assessment is the most widely recognised framework for evaluating schedule quality. It was developed by the US Defence Contract Management Agency and provides 14 checks that any CPM schedule should pass.

In the context of baseline review, the DCMA 14-Point gives you an objective, repeatable standard. Instead of debating whether a schedule is “good enough,” you can point to specific metrics.

The 14 checks are:

Logic: activities without predecessors or successors. Target: ≤5% of activities have missing logic.
Leads: relationships with negative lag. Target: zero leads.
Lags: relationships with positive lag. Target: ≤5% of relationships use lags.
Relationship Types: distribution across FS / SS / FF / SF. Target: ≥90% Finish-to-Start.
Hard Constraints: fixed-date constraints (MSO, MFO) that prevent activities from being moved by the scheduler. Target: ≤5% of activities have hard constraints.
High Float: activities with total float greater than 44 working days. Target: ≤5%.
Negative Float: total float less than zero. Target: zero activities.
High Duration: activities with a duration greater than 44 working days. Target: ≤5%.
Invalid Dates: actual start / actual finish dates after the data date, or forecast dates before it. Target: zero invalid dates.
Resources: activities that should be resourced but lack cost or labour estimates. Target: every applicable activity is resourced.
Missed Tasks: activities that finished later than their baseline finish date. Target: ≤5% of completed activities missed their baseline.
Critical Path Test: insert a 600-day delay on a single critical-path activity and confirm the project finish moves by the same amount. If it doesn’t, the critical path isn’t really driving the finish.
Critical Path Length Index (CPLI): ratio of critical-path duration to (critical-path duration + total float). Target: ≥0.95.
Baseline Execution Index (BEI): ratio of tasks actually completed to tasks that should have been completed by the data date. Target: ≥0.95.

As a working rule of thumb, a baseline failing more than three or four of these points should be returned to the contractor for correction; a schedule failing six or more has fundamental quality problems that no amount of narrative can fix. (DCMA itself doesn’t publish a pass/fail count threshold; that judgement is yours, supported by the metric results.)

What we found: Three of the fourteen DCMA checks carry most of the structural weight on a baseline review: missing logic (check 1), hard constraints (check 5), and CPLI (check 13). The first two carry a five per cent threshold; CPLI’s pass threshold sits at 0.95. These are the checks the rest of the network calculation depends on.

What it means: A baseline that fails any one of these checks reveals a network the rest of the calculation can’t trust. A baseline that fails several at once isn’t asking for “approve subject to improvements”; it’s a programme that needs to be returned and resubmitted before the clock starts.

Running the DCMA 14-Point in Primavera P6 requires manual configuration. Tools like ScheduleLens automate the entire assessment: upload an XER file and get immediate results against all 14 points, with no manual setup required.

Periodic Schedule Update Reviews

Approving the baseline is not the end of your review responsibility. Schedule quality can degrade rapidly through updates; logic changes, scope additions, and constraint manipulation can transform a sound baseline into an unreliable programme within a few update cycles. The mechanics of comparing each update against the approved baseline are covered in our guide to baseline vs current schedule comparison.

At each periodic update, check:

Activity changes: have activities been added, deleted, or had their durations changed? Were these changes agreed?
Logic changes: have dependencies been added, removed, or modified? Logic changes can shift the critical path and alter float distribution.
Out-of-sequence progress: activities reporting progress before their predecessors are complete. This indicates either a logic error or that the work is being performed out of sequence.
Schedule drift: is the forecast completion date moving later compared to the baseline? How fast is it drifting?
Float consumption: which paths are consuming float fastest? A path that had 20 days of float last month and 5 days this month is a priority risk.

Red flags in schedule updates include:

Unexplained logic changes that remove delay from the critical path
Activities deleted and re-added with different logic
Scope quietly removed from the programme
Constraints added to force dates

How Baseline Review Quality Affects EOT Claims

This is the connection most people miss. The quality of your baseline review directly affects your position when extension of time claims arise.

A well-reviewed baseline gives you a defensible starting point. When a delay event occurs, the starting point for analysis is the schedule as it stood before the event. If that schedule had undetected logic gaps, the other side can argue the delay existed before the event.

Common baseline defects that undermine claims:

Missing logic ties that created artificial float; when the “float” is consumed, who is responsible?
Hard constraints that masked the true critical path; when the constraint is removed, the critical path shifts, changing which activities are time-critical
Unrealistic durations that were never queried at baseline approval; the contractor can argue the delay was inherent in the schedule you approved

The owner’s position is weakened by approving a schedule that a reasonable review would have rejected. Tribunals and courts increasingly expect that parties have met their obligations to review and challenge defective schedules.

Document your review findings contemporaneously. If you identify issues at baseline review, document them in writing, even if you approve the schedule subject to conditions. That contemporaneous record can be critical evidence in a dispute.

Tools for Baseline Schedule Review

Tool	Best For	Limitations
Oracle Primavera P6	Full schedule analysis, built-in DCMA scheduling checks	DCMA checks require manual setup; expensive licence
Microsoft Project	Smaller projects, basic review	No built-in DCMA assessment; limited analysis tools
ScheduleReader	Viewing and analysing XER files without a P6 licence	Read-only; no scheduling or editing capability
ScheduleLens	Automated DCMA 14-Point assessment, critical path validation, baseline comparison, float analysis; upload an XER file and get immediate results	Focused on analysis rather than scheduling
Excel checklists	Manual checklist tracking for small projects	No automated checking; relies entirely on the reviewer’s expertise

For most projects, a combination works best: use your scheduling tool (P6 or MS Project) to create and maintain the schedule, and use ScheduleLens to independently verify schedule quality without the manual setup overhead.

Key Takeaways

Review the baseline before you approve it. Once approved, the baseline becomes the project’s benchmark; fix problems now, not after the first delay event.
Use the checklist. Contract compliance, WBS, logic, durations, critical path, calendars, float, and resources; covering all eight areas ensures nothing is missed.
Apply the DCMA 14-Point Assessment. It gives you an objective quality standard and specific pass/fail criteria, removing subjectivity from the review.
Negative float on a baseline is a hard fail. A schedule that cannot meet the contractual completion date before work starts is not a valid baseline.
Update reviews are not optional. Schedule quality degrades through updates. Check for logic changes, scope changes, out-of-sequence progress, and float consumption at every cycle.
Baseline quality affects EOT outcomes. A well-reviewed baseline gives you a defensible starting point for delay analysis. A poorly reviewed one gives the other side arguments to undermine your position.
Document everything contemporaneously. Your review findings, conditions, and concerns should be recorded in writing at the time of the review; not reconstructed months later for a claim.

Need to run an automated baseline schedule review? Try ScheduleLens for instant DCMA 14-Point assessment, critical path validation, float analysis, and baseline comparison, all from a single XER file upload.