Construction programme baselines: what clients should challenge
Admin · 22 October 2026
Illustrative image. Photo by Jonathan Borba on Unsplash. Unsplash License.
A programme baseline gives a project a reference against which to understand progress and change. Its value depends on whether the underlying plan is credible. A polished chart can show an attractive completion date while concealing missing approvals, unsupported durations and incompatible resource assumptions. For clients, reviewing the baseline should mean testing the delivery story behind the bars, with help from people who understand the work and the scheduling method.
The review is not an invitation to dictate every construction activity. It is an opportunity to establish what the proposed dates depend on, which commitments the client must make and how the team will recognise emerging delay. The approved plan should provide a shared basis for discussion. Where the contract specifies programme requirements or acceptance procedures, those provisions need to be addressed through the appropriate project roles.
Ask what scope the programme represents
Begin by comparing the programme boundaries with the project scope. Confirm that design, procurement, enabling work, construction, testing and transition into use are represented at an appropriate level. Client-supplied equipment and third-party activities can determine completion even when they sit outside the main contractor’s package. A programme that excludes them may be useful for one organisation but incomplete as a view of the whole project.
Identify the scope and information assumptions used when the baseline was prepared. Record the relevant revisions of key inputs and any exclusions. If the design is still developing, explain how the remaining decisions are represented. A baseline can be established with uncertainty, but that uncertainty should be visible. Otherwise later teams may interpret an assumption as an agreed commitment and struggle to explain why the plan has changed.
Follow the dependencies
Select a few important completion milestones and work backwards through the activities that enable them. Ask what must finish before the next activity can start, and why. Include information releases, decisions and inspections where they genuinely constrain the work. The purpose is to test whether the sequence reflects how the project will be delivered rather than simply arranging activities between a required start and finish date.
Challenge unexplained gaps, overlaps and fixed dates. Some may be justified by access windows, business restrictions or an external commitment. Others may be artefacts of the scheduling process. Ask the planner to distinguish them and explain their effect on the forecast. A date imposed to match a reporting target should not be confused with a result calculated from a fully developed delivery sequence.
Examine the basis of durations
Important activity durations need an understandable basis. Depending on the work, this might involve quantities, production assumptions, available crews, working calendars or supplier advice. Ask what evidence supports the estimate and what conditions it assumes. A duration taken from a previous project may be a useful starting point, but differences in access, complexity and working restrictions still need consideration.
Use focused questions rather than asking for exhaustive detail on every activity. Which durations are most uncertain? Which have the greatest influence on the completion forecast? Where is supplier input still provisional? This directs review effort towards assumptions that could materially change the plan. It also helps the client identify investigations or decisions that could improve confidence before a major commitment is made.
Test resource and space assumptions
Activities can be logically linked and still be impractical when they demand the same people, equipment or working area at the same time. Ask how the programme accounts for significant shared resources and congested work fronts. The appropriate level of detail will vary, but the delivery team should be able to explain how the proposed sequence can be resourced and coordinated.
A hypothetical fit-out programme might show several floors progressing simultaneously. That arrangement could be credible if supervision, access, deliveries and trade resources support it. If the plan assumes one specialist crew moving between those floors, the overlap needs explanation. The client does not need to invent the crew allocation; it needs evidence that the delivery organisation has considered the constraints behind its proposed dates.
Make client decisions visible
The baseline should identify the information and decisions required from the client, with enough time for a realistic review. Include the work needed to prepare a decision, not just the final approval milestone. A committee meeting may occur on a fixed date, while the papers need to be ready earlier. The programme should expose that dependency so the project team can organise its submissions accordingly.
Confirm that the named decision owners understand their commitments. A date placed in a programme does not establish that an external party has accepted it. Record which dates are agreed, which are requested and which remain assumptions. Where the project depends on a third party, identify the engagement and evidence needed to improve confidence. Escalate the uncertainty while there is still time to consider alternatives.
Understand the path to completion
Ask the planner to explain the sequence currently controlling completion and the activities close enough to it to warrant attention. The explanation should be understandable to decision makers without requiring them to interpret every software field. The APM overview of scheduling provides background on arranging project activities and scheduling approaches. A project review should apply the chosen method consistently and make its assumptions clear.
Explore plausible changes in key assumptions. What happens if a design release moves, a supplier revises its delivery date or an access window is lost? These discussions should use the actual programme logic and informed input, rather than arbitrary adjustments to the final milestone. Their purpose is to identify decisions and contingency options while avoiding unsupported claims that every uncertainty can be absorbed.
Agree how progress will be measured
Before reporting starts, define the status date, progress evidence and update responsibilities. Completion percentages should mean something consistent for the activity being measured. For some work, installed quantities may be useful; for other activities, defined deliverables or milestones provide better evidence. Avoid allowing a subjective percentage to substitute for an explanation of what is complete and what remains.
Keep the approved baseline available alongside the current forecast. The baseline explains the agreed reference, while the forecast reflects the team’s latest assessment. Changes to the baseline should follow the established controls and preserve an audit trail. Replacing it casually to remove visible variance weakens the project’s ability to learn from what happened and to understand the effect of approved changes.
Record the review outcome
Conclude the review with specific findings. Identify the assumptions accepted, the corrections required and the outstanding information, with owners and dates. Distinguish matters that prevent the next commitment from those that can be resolved through ordinary planning development. Where contractual acceptance is involved, use the applicable procedure and terminology rather than treating a general management discussion as a substitute.
At subsequent reviews, return to the assumptions that mattered most. Confirm whether they still hold and explain what has changed. A baseline should support active management rather than remain a static approval document. Its practical value is the ability to connect a forecast movement to a recognisable cause, identify a decision within somebody’s authority and assess the options using a coherent view of the work.
Keep the review record concise enough for incoming team members to use. They should be able to identify the baseline version, its scope, the principal dependencies and the unresolved issues without searching through months of correspondence. That continuity is particularly useful when responsibility passes from preconstruction staff to the site delivery team.
Include the calendars used for significant activities in that explanation. Different working weeks, shutdown periods or access restrictions can affect the interpretation of a duration. A reviewer should not need to discover these assumptions only after comparing dates that appear inconsistent.
