Construction Scheduling Specification: What an Owner Should Write into the Contract

The weakest programme clause is the one everyone finds only after the job slips. The contractor submits a PDF bar chart, the dates look orderly, and the contract administrator accepts it because the standard form says a programme has to be provided. Three months later, the same PDF can’t answer the important questions: what logic changed, which activity drove completion, whether float was consumed, and whether the update is still a reliable record.

A construction scheduling specification fixes that problem before tender. It tells bidders what programme evidence they must produce, in what format, how often, and against what acceptance criteria. If you need the wider review workflow after the file arrives, start with a structured construction schedule analysis. For what NEC4, FIDIC, JCT, AIA and the US federal forms already require, see the contract programme requirements comparison.

Why the Standard Form Is Not Enough

Standard forms usually set the obligation to submit a programme; they rarely give the owner a complete review instrument. What they leave out is the detail a reviewer needs later: native files, update narratives, activity coding, measurable quality thresholds, and as-built records.

Source example: Transport for NSW’s G2-C2 General Requirements for major contracts (clause 39) separates programme obligations into specific requirements: software, off-site activities, monthly update explanations, cash-flow forecasting, and an as-built programme.

Scheduling Specification Checklist for Owners

1. Require the native file, not just the PDF

A PDF Gantt chart is a report view. The native file is where the logic, calendars, float, constraints, critical path, activity IDs, and progress data live.

TfNSW G2-C2 clause 39.3 requires contract programmes as both paper and electronic documents, and states: “the software used must be either Primavera P6 or MS Project 2010.” That is old software wording, but the drafting principle is current: name the native file format the reviewer will receive.

The US federal schedule specification, UFGS 01 32 01.00 10 (August 2026), takes the same position more generally. Its clause 3.5.1 calls for “electronic scheduling data” in the format of the scheduling software, with .xer given as an example, and requires each file to identify the schedule type, contract number, data date, and file name.

2. Specify method, detail, calendars, and duration limits

The specification should require a Critical Path Method (CPM) programme with logic-linked activities, defined calendars, visible constraints, and a maximum activity duration unless a longer duration is justified. Without these rules, the first baseline can bury too much work inside long bars that no one can progress meaningfully.

3. Make quality thresholds measurable

A requirement that the programme be “reasonable” leaves the reviewer to argue the point with the contractor. Measurable thresholds give both parties a target before the first submission arrives.

TfNSW 5TP-FT-425 clause 2.8 (the 2015 version, the latest public one) is a useful worked example. It says the contractor’s programme “will be rejected by the Principal’s Representative if the quality does not meet the thresholds prescribed below”. Its table covers most of the DCMA 14-point items and is tighter than DCMA on logic, constraints, lags and activity duration:

Zero lags and zero soft constraints are strict limits, and TfNSW lets the Principal’s Representative approve deviations. Whatever numbers you choose, a threshold only works as an acceptance criterion if the contract states it.

4. Require a baseline, then measure progress against it

An update only shows slippage if there is an agreed plan to compare it with. Set a deadline for the baseline, say how it is approved, and require each update to report progress against it.

TfNSW 5TP-FT-425 clause 2.7 requires a “Cost Loaded Baseline Schedule within 10 days of the date of the Contract”, and clause 2.7.2 requires the programme to show earned value in accordance with AS 4817-2006. UFGS works in two steps: a Preliminary Project Schedule within 15 calendar days after notice to proceed is acknowledged, then an Initial Project Schedule submitted for approval within 42 calendar days.

State which approved baseline governs and that re-baselining needs the owner’s approval. Without a baseline, two DCMA tests (missed tasks and the baseline execution index) cannot be run at all.

5. Require coding that survives monthly updates

Programme comparison depends on stable identifiers. Require activity IDs, WBS, area, discipline, phase, subcontract package, and milestone coding where they matter to the job.

If the contractor renumbers activities every month, the reviewer loses continuity. The specification should say how IDs are to be maintained, when new IDs are allowed, and how deleted or replaced activities are to be explained.

6. Name the milestones and sectional dates

Sectional completion, handover areas, access dates, long-lead procurement, authority approvals, shutdown windows, commissioning, and client-supplied information dates can all drive the project.

Name the milestone activities that must appear in the programme and state the coding or naming convention for them. If the reviewer later has to ask which activity represents completion, the specification didn’t do enough work at tender stage.

7. State who owns float

Settle float ownership in the drafting, before anyone needs it in a progress meeting. If the contract says nothing, the parties may later disagree about whether float protects the contractor’s method, the employer’s changes, or the project as a whole.

Keep the specification plain: say how total float is to be treated, whether early completion float has a different rule, and how float consumption is to be reported. For the three common positions and the practical drafting issue, use the total float vs free float guide.

8. Define review, acceptance, and what acceptance means

The review period needs a clock, a response method, and a list of reasons for rejection. It should also say what acceptance does and doesn’t do. Otherwise, the first accepted programme becomes a source of argument rather than a record of the contractor’s plan.

Avoid casual wording that suggests every activity date becomes a contractual obligation just because a programme was accepted. Acceptance might mean the programme is suitable for progress management, payment assessment, or delay review, depending on the form and special conditions.

9. Require an update narrative with every update

The monthly update should explain what changed, not just replace last month’s file. A reviewer needs reasons for logic changes, progress shortfall, critical-path movement, and recovery steps.

TfNSW G2-C2 clause 39.2 requires monthly updated programmes to include “reasons for any divergence in activity logic” and “reasons for any shortfall in Scheduled Progress” with proposed steps to make good the shortfall. UFGS 3.5.2 requires a standalone Narrative Report with each schedule submission, covering the critical path, delaying factors, corrective actions, changes by activity, and any change to the longest path.

That is the level of explanation an owner should want. The file shows what changed; the narrative makes the contractor say why.

Figure: A practical update-review flow starts with the file, then tests the contractor’s narrative against it.

10. Include off-site, procurement, and cash-flow activities

The work that delays completion is not always on the site. Fabrication, equipment manufacture, design submissions, authority approvals, procurement, shipping, commissioning, and handover can all sit away from the visible works.

TfNSW G2-C2 clause 39.1 requires the Contract Program to show off-site activities “both in and outside Australia” and to include a monthly forecast Claimed Amount to Completion. UFGS ties the schedule to payment more directly: “The schedule is the basis for determining contract earnings during each update period and therefore the amount of each progress payment,” and says activity cost loading must be reasonable and without front-end loading.

11. Set recovery and as-built requirements

The specification should say when a recovery programme is required: for example, failure to meet an interim milestone, forecast delay to completion, or failure to maintain agreed progress. It should also say what the recovery submission must show, such as changed logic, added shifts or revised procurement.

Finally, require an as-built programme at completion. TfNSW G2-C2 clause 39.4 requires a detailed “as-built” Contract Program by the Actual Completion Date. That record matters because extension of time (EOT) assessments, defects disputes, and lessons learned often depend on what actually happened, not what the last accepted forecast said.

What to Do When the First Programme Arrives

The first programme should be checked against the specification before anyone treats it as the baseline. That means confirming the required native file arrived, testing the logic and float, checking the milestones, reviewing calendars and constraints, and recording any rejection against the specification wording.

For the review workflow after submission, use the baseline schedule review checklist or the wider guide to reviewing a contractor’s programme. The sample health report shows the kind of logic, float, critical-path and DCMA-style checks you can run on the native file once your specification requires it.

This checklist isn’t legal advice. The specification should be written from the project controls need, then checked by the client’s lawyer so the acceptance wording, payment linkage, float rule, and recovery triggers fit the contract.

Construction Scheduling Specification Close-Out Checklist

Use this table before the tender documents go out.

If the owner asks only for a bar chart, a bar chart is what they will get. If the owner asks for the file, the logic, the narrative, the thresholds, and the as-built record, the programme can become evidence.