How to Review a Contractor's Programme: Step-by-Step Guide with Checklist

You’ve just received the contractor’s baseline programme. It’s 800 activities, fully logic-linked, resource-loaded, and shows the project finishing on time. Looks fine. You approve it. Six months later, the project is three weeks behind, the critical path has shifted to a completely different trade sequence, and the contractor’s EOT claim references a programme that bears no resemblance to what’s actually happening on site. You’re now in a dispute about a programme you approved without understanding what was in it.

That scenario plays out on construction projects constantly. The baseline programme is the contractual reference point for measuring delay, assessing float, and determining EOT entitlement. If you accept it without a proper review, you’re accepting the foundation for every future claim and counter-claim on your project. This article gives you a structured process for reviewing a contractor’s programme so you know exactly what you’re approving and what you’re not. It sits alongside our wider guide to a structured construction schedule analysis and applies the same first principles at the baseline stage.

Why Reviewing the Contractor’s Programme Matters

The baseline programme sets the standard against which all future performance is measured. Per the Society of Construction Law Delay and Disruption Protocol, paragraph 4.1, the accepted programme becomes the reference for delay analysis. If the baseline contains errors, omissions, or manipulations, every delay analysis based on it will inherit those problems. Comparing each monthly update against that baseline is itself a discipline: see our guide to baseline vs current schedule comparison for the techniques.

Berlin Brandenburg Airport opened nine years late and billions of euros over budget. The inquiry revealed that the programme was fundamentally unreliable: fire protection systems were modelled with incomplete sequences, key milestones were constraint-driven rather than logic-driven, and the relationship between building completion and systems commissioning was inadequately linked. The baseline programme looked plausible on paper but didn’t represent how the building would actually be constructed. Accepting a programme like that means building your project controls on a foundation that won’t hold.

Callout box: Accepting the baseline programme without review doesn’t just mean accepting the schedule. It means accepting the basis for every future delay claim, every float argument, and every liquidated damages calculation on your project.

Before You Start: What You Need

Gather these items before you begin the review:

• The submitted programme in its native format (XER for Oracle Primavera P6, MPP for Microsoft Project). PDF exports aren’t sufficient; they don’t show logic, constraints, or float calculations. Our guide to XER file analysis covers what’s actually inside the file and how to interrogate it.
• The contract requirements for the programme: format, level of detail, submission timing, required milestones, and any scheduling specification
• The employer’s milestone requirements and any contractually imposed constraints
• The scheduling specification or project execution plan requirements
• Previous correspondence about the programme submission

Don’t review a PDF. Don’t review a programme you can’t recalculate. If you don’t have the native file, request it.

The 7-Step Programme Review Process

Work through these steps in order. Each step builds on the previous one. Steps 1 and 2 are about content completeness. Steps 3, 4, and 5 are about technical quality. Step 6 is about schedule health. Step 7 is about resource and cost integrity.

Step 1: Verify Contractual Compliance

First, confirm the programme meets the contract’s procedural requirements. This isn’t a technical check; it’s a contractual one.

Check:

• Was the programme submitted within the time frame required by the contract? Late submission may be a breach.
• Is it in the required format? Most construction contracts specify a scheduling tool and format.
• Does it include the required content: milestones, Work Breakdown Structure (WBS), calendars, narratives, and any specified reporting?
• Are the contractually specified milestones present and correctly dated? If a contract requires practical completion by 15 March 2027, that milestone must be in the programme.

Why it matters: If the programme doesn’t meet contractual requirements, you can reject it on procedural grounds before spending time on technical review. The contract usually allows a specified period for review and acceptance or rejection.

Step 2: Check Work Breakdown Structure and Scope

Verify that the programme covers all contract scope. Every major deliverable should be represented as activities or activity groups.

Check:

• Are all contract sections represented in the WBS?
• Are there activities for scope not in the contract? The contractor may have included self-performed work that isn’t contractually required.
• Are any scope items missing? A programme that omits a major package (like commissioning or handover activities) is incomplete.
• Does the level of detail match the scheduling specification?

Why it matters: Missing scope means missing activities means missing logic links. Activities that don’t exist can’t be on the critical path, and delays to unmodelled work won’t appear in the programme.

Step 3: Review Activity Durations and Calendars

Durations and calendars determine the programme’s time baseline. If they’re unrealistic, the programme is unreliable.

Check:

• Are any durations unusually long? The Defense Contract Management Agency 14-Point Assessment, metric 8, flags activities exceeding 44 working days. These are often summary-level tasks that should be broken down.
• Are any durations unusually short? A one-day activity for “install mechanical systems” is too coarse.
• Are the calendars appropriate? A five-day calendar for a project with weekend work is wrong. A seven-day calendar for office fitting works is also wrong if the site operating hours are five days.
• Do calendars account for weather delays, public holidays, and shutdown periods?

Practical step: In P6, review the calendar assignments for all activities. Check that the calendar used for each activity matches the actual working pattern for that trade.

What we found: A single global calendar applied to every activity, regardless of trade, will calculate durations using whichever working pattern the calendar carries. A seven-day calendar applied to trades that only work five days produces an apparent duration shorter than reality, because the calculation treats every Saturday and Sunday as a working day. The error is invisible from the Gantt bars.

What it means: Calendar assignment is one of the few quality checks that the eye won’t catch. The right calendar must be assigned per activity or per trade, not per project. Approving a programme without checking the calendars commits the project to a schedule built on the wrong working pattern from day one.

Step 4: Analyse Logic and Dependencies

This is the most important step. Logic determines the critical path, float values, and the programme’s ability to model how the project is built.

Check:

• Open ends: Activities with no predecessor or no successor break the network logic. The DCMA 14-Point Assessment, metric 1, requires fewer than 5% of activities with missing logic. Flag every open end.
• Hard constraints: Must Finish On (MFO) and Must Start On (MSO) constraints override logic. Metric 8 flags schedules with hard constraints exceeding 5% of constrained activities. Count them.
• Lags: Positive lags represent waiting time embedded in the logic. Excessive lags (more than 5% of relationships, per industry practice) suggest the program is using delays instead of proper activity sequences. Negative lags (lags with a negative value) should be zero. The DCMA 14-Point Assessment, metric 2 (Leads) prohibits negative lags; metric 7 (Negative Float) requires zero negative float in the schedule.
• Logic type: Most relationships should be Finish-to-Start (FS). Start-to-Start (SS) and Finish-to-Finish (FF) relationships are acceptable but require scrutiny. Start-to-Finish (SF) relationships are almost always errors.

Practical step: In P6, run the schedule log (Tools > Schedule > View Log). The log lists open ends, circular logic, and out-of-sequence activities. This is your starting point for the logic review.

Step 5: Validate the Critical Path

The critical path identifies the activities that determine the project completion date. If the critical path doesn’t make sense, neither does the programme. Our deeper guide to the critical path method in construction explains how the longest-path calculation works and how constraints can hide it.

Check:

• Does the critical path follow the expected construction sequence? On a building project, it should generally run through structure, envelope, and MEP.
• Are there multiple critical paths? More than one continuous zero-float chain indicates a compressed schedule with little recovery margin.
• Is the float distribution realistic? If every activity has zero float, the schedule is over-constrained. If most activities have very high float, logic may be incomplete.
• Are near-critical paths (float less than 10 working days) identified?

Practical step: In P6, filter for Total Float less than or equal to zero. Review the resulting activity list: does this sequence represent the dominant trade flow? If the critical path runs through landscaping on a high-rise, there’s a logic problem.

Step 6: Run Schedule Quality Checks

Apply the DCMA 14-Point Assessment to quantify the programme’s quality. You don’t need to run all 14 checks on every submission, but the core metrics should be reviewed for every baseline. Our reference guide to the DCMA 14-Point Assessment sets out each metric, the threshold, and the rationale.

This isn’t the full 14-point assessment. For the complete methodology, see the linked guide above. But these nine checks will catch most quality issues in a baseline submission.

Step 7: Review Resources and Cost Loading

If the contract requires resource and cost loading, verify the data.

Check:

• Is the programme resource-loaded? If the contract requires it and it isn’t, that’s a compliance issue.
• Do the total costs match the contract value? A programme that loads $120M of cost on a $100M contract has a budgeting error.
• Are resources assigned at rates that make sense? A crew of 50 welders on a small pipe spool activity is over-allocated.
• Are cost profiles distributed logically, or are they front-loaded or back-loaded in ways that don’t match the activity durations?

Why it matters: Resource and cost loading feeds into earned value analysis and progress payment verification. If the loading is inaccurate, the earned value data will be wrong.

How to Document Your Review Findings

Your review needs to produce a document that records what you found and what you require. Structure the review report as follows:

Classification System

Report Structure

1. Executive summary: overall assessment and recommendation (accept, accept with conditions, reject)
2. Contractual compliance findings
3. Technical quality findings (logic, durations, critical path)
4. Schedule quality metrics (DCMA results)
5. Action items classified as critical, advisory, or informational
6. Required response date for the contractor
7. Appendices with supporting extracts from the programme

Common Programme Review Findings: Real Examples

These are the recurring issues that turn up when contractor programmes are reviewed against the DCMA thresholds and the SCL Protocol’s programme expectations:

Missing scope activities. The contractor’s programme covers the civil and structural works but omits the commissioning sequence. Without commissioning activities, the critical path ends at practical completion of construction rather than the operational readiness date. This compresses the apparent programme by excluding the final phase.

Excessive constraints hiding float. A programme with 40 hard constraints across 800 activities shows roughly 5% constraint usage. Some of these constraints may be legitimate (statutory milestones), but many are date overrides that make non-critical activities appear critical. The float being hidden belongs to the project.

Unrealistic durations not benchmarked. A long-duration activity that isn’t challenged at programme review sits as embedded float that only the contractor sees. The activity has built-in slack that the network calculation doesn’t recognise as float, so it can’t be allocated, contested, or released. Any activity over the DCMA forty-four-working-day threshold (metric 8) should be benchmarked against industry or in-house norms, and the contractor should be required to justify durations that sit at the upper end of the range.

Open ends on critical activities. A critical path activity with no predecessor. Its start date is driven by nothing. It could move anywhere in the programme, and no logic would prevent it. This breaks the network integrity for any delay analysis.

Calendar errors affecting the critical path. A critical activity on a five-day calendar when the subcontractor works six days. The activity’s duration in calendar days is shorter than modelled, which means the critical path is longer than it needs to be. Or the reverse: a five-day activity on a seven-day calendar that will actually take longer than the programme shows.

From Review to Monitoring: What Happens Next

Reviewing the baseline is the first step, not the last. Once the programme is accepted:

1. Set up update review protocols. Every monthly update should be reviewed against the accepted baseline. Key checks: has the critical path shifted? Is float being consumed at an expected rate? Have logic changes been made without approval?

2. Link review findings to future delay analysis. Issues identified during baseline review (excessive constraints, missing logic) will appear again in delay claims. If you flagged them at baseline, you have a documented basis for challenging analyses based on the same programme.

3. Ongoing schedule quality monitoring. The DCMA 14-Point metrics should be tracked between updates, not just at baseline. A programme that passes at baseline can degrade after several updates as the contractor adds constraints or modifies logic.

4. Contemporaneous records. From day one, ensure site diaries, daily logs, and progress photographs are being maintained. These records are what verify or contradict what the programme claims.

The California High-Speed Rail project was approved in 2008 with a $33B budget. By 2024, the estimate had risen above $100B, and the project’s programme had been re-baselined multiple times. Each time, the new baseline incorporated lessons from the previous programme’s failures, but the fundamental issues, such as incomplete scope definition and optimistic durations, kept recurring. Programme review isn’t a one-time event. It’s a continuous process that starts at baseline and doesn’t end until the project is complete.

Tools for Programme Review

Oracle Primavera P6 is the primary tool for reviewing submitted XER files. Open the XER in P6, run the schedule (F9) to verify calculations, and use the schedule log to identify open ends and circular logic.

ScheduleReader is a standalone application that allows XER review without a P6 licence. It’s useful for client-side teams who don’t have P6 but need to review programme submissions.

ScheduleLens automates the review process: it runs the DCMA 14-Point Assessment, identifies open ends, flags constraint abuse, validates the critical path, and generates a downloadable review report. For the client-side PM who receives a programme and needs a structured assessment without spending days manually auditing an XER file, ScheduleLens does the heavy lifting.

Standards and References

Programme Review Checklist

Use this checklist on every baseline submission:

• Programme submitted in native format (not PDF only)
• Submission timing complies with contract
• Contractual milestones present and correctly dated
• All contract scope represented in WBS
• No missing scope activities
• Durations realistic and benchmarked
• Calendars appropriate for each trade
• Open ends below 5% (DCMA metric 1)
• Hard constraints below 5% (DCMA metric 5)
• No negative lags (DCMA metric 2)
• No negative float (DCMA metric 7, pass threshold is 0%)
• Critical path makes logical sense for the project type
• Near-critical paths identified (float < 10 working days)
• Float distribution is realistic
• Resources loaded if contractually required
• Costs match contract value
• Review report prepared with classified findings

What to Do Next

Don’t approve the next programme that lands on your desk without running through the seven steps above. Start with the checklist. If the programme has open ends on the critical path or excessive hard constraints, flag it immediately. If the critical path doesn’t follow the expected construction sequence, ask the contractor to explain why.

A properly reviewed programme protects you. It gives you a defensible baseline for measuring progress and assessing delays. It gives you evidence if a dispute arises. And it means you know what’s actually in the document you’re signing off on.

This article is for educational purposes and does not constitute legal or professional advice. Programme review requirements should be considered in the context of your specific contractual provisions and project conditions.