Programme baselining is the act of locking a project schedule at the point where scope, sequence, durations, and resource assignments are agreed and contractually defensible. On traffic signal projects, it's one of the most consequential steps in the delivery process. It's also one of the most consistently done poorly. The consequences don't appear immediately. They surface three months into construction when progress claims can't be verified, when variation disputes have no reference point, and when no one can explain how a programme that looked achievable at award became six weeks behind before site works were half-complete.
What a programme baseline actually is
A baseline isn't a plan. That distinction matters. A plan is a working document that changes as conditions change. A baseline is a frozen snapshot of that plan taken at a defined point, typically after contract execution and before mobilisation. Every subsequent update to the live programme is measured against the baseline. Without that frozen reference, there's no objective way to determine whether the project is ahead or behind, or whether a claimed delay arose from a scope change or from poor sequencing in the original plan.
On traffic signal projects, the baseline must capture more than milestone dates. It needs to show the full sequence of dependent activities: design submissions, authority approvals, civil works, cabling, controller installation, detection loop installation, commissioning, and the sign-off stages that sit between each. A baseline that shows only high-level milestones gives the project team no early warning of drift at the activity level, which is where slippage actually begins.
The five most common baselining mistakes
Bob Panich Traffic Signals has seen the same errors repeated across projects of varying scale and complexity. They tend to cluster around five failure modes.
Durations copied from a template without site-specific adjustment. Traffic signal projects differ meaningfully in site conditions, authority jurisdiction, and site access constraints. A duration that is realistic for a simple intersection upgrade in an industrial area may be wildly optimistic for a complex urban intersection requiring night works and lane occupancy permits. Site access planning directly shapes how long many activities take, yet baseline durations often ignore it entirely.
Approval durations treated as fixed. Design approval from the relevant transport authority is not a fixed-duration activity. It depends on submission quality, the reviewer's workload, and whether the authority requests amendments. Baselining a seven-day approval period when the authority's own service level agreement states fifteen working days is an error that propagates into every downstream activity.
Float allocated to milestones, not activities. Many practitioners add float to major milestones as a buffer and treat the activities leading to those milestones as fixed-duration. This inverts the purpose of float. Free float belongs at the activity level, where it can absorb small slippages before they reach the critical path. Total float at a milestone gives the impression of schedule resilience without providing any.
Resource constraints ignored at baseline. A programme that shows 12 activities occurring in parallel is only credible if the site has the resources to support them. Resource levelling must happen before the baseline is locked, not after the first progress review. Baselining an over-resourced programme means the first month of delivery will inevitably force a resequencing that invalidates the original baseline.
No agreed baseline change process. Even a correctly constructed baseline becomes useless if it can be informally revised whenever the programme falls behind. The baseline must be version-controlled, and any change to it must go through a formal variation process linked to project change control. Without that discipline, the baseline becomes the target that gets quietly moved to match actuals.
What the baseline must include on a traffic signal project
Beyond the standard scheduling requirements, traffic signal project baselines need to explicitly capture the following.
- All authority interface milestones: submission dates, review periods, approval receipt, and re-submission windows for each relevant authority.
- Construction activity windows constrained by traffic management approvals, including any night-work-only periods and public event blackouts.
- Factory acceptance testing and site acceptance testing as discrete activities with clear predecessor links to equipment delivery.
- Commissioning phases broken into sub-activities: controller configuration, loop tuning, timing plan upload, and functional testing.
- Hold points and witness points required under the project quality plan, with realistic durations for inspection scheduling and sign-off.
The relationship between the baseline and cost control
Programme baselines and cost baselines are interdependent. Time-related costs, including plant hire, temporary traffic control, and subcontractor attendance, can't be tracked accurately without a programme baseline that shows planned resource deployment periods. When the programme baseline is weak, cost forecasting becomes speculative. Project managers end up estimating completion costs based on percentage progress rather than earned value, which produces forecasts that are consistently optimistic until it's too late to act.
The baseline is also the reference document for assessing delay-related claims. If a subcontractor claims an authority approval delay pushed their work programme out by three weeks, that claim can only be assessed against a baseline that shows the original approval duration and its links to downstream activities. Without a credible baseline, the project manager has no position from which to accept or reject the claim.
When to re-baseline, and when not to
Re-baselining is sometimes necessary. If the project scope changes substantially through a formally approved variation, the baseline should be updated to reflect the new scope. If a force majeure event genuinely alters the delivery environment, re-baselining with appropriate documentation is defensible.
Re-baselining to hide accumulated delay is not a schedule management technique. It's a way of losing the ability to understand what went wrong, which makes the same mistakes more likely on the next project. The correct response to a programme falling behind is a recovery plan against the original baseline, not a revised baseline that resets the reference point.
Bob Panich Traffic Signals treats the programme baseline as a contract document, not a scheduling tool. That framing changes how it's built, what level of detail it carries, and how seriously the change process is applied. Projects that share that view finish with accurate records. Those that don't finish with disputes.