What Makes a Baseline Schedule Usable?

Article

A baseline schedule is the reference against which progress, change, and delay will later be judged. Usability is therefore a practical test: can a competent planner update this model next month and explain variance without first rebuilding the logic? If the answer is no, the file may still look complete. It is not yet a baseline.

Scope that can be progressed

Usable baselines cover the contracted remaining work at a level of detail that matches how the work will be reported. Too coarse, and a month of site activity disappears into a single bar. Too fine, and the update becomes theatre — hundreds of activities that nobody actually status. The right density is the one a project can maintain with the records it already keeps: quantities, inspection lots, deliverable packages, or crew areas.

Milestones should mark events that have meaning in the contract or the control process: access, design freeze, start of a separable part, sectional completion. Decorative milestones that do not constrain remaining work add noise when dates later move.

Logic that drives, rather than decorates

Open ends, negative lag used to force dates, and start-to-start chains with no real overlap are common ways a programme can calculate a completion date that nobody on site would recognise. A usable baseline can be interrogated: why is this activity critical, what is its driving predecessor, and what happens to completion if that predecessor slips by a week?

• Every remaining activity except project start and finish has a logical driver and a successor, unless a documented exception exists.
• Constraints are sparse and explained. A “Must Finish On” date is a management instruction, not a substitute for logic.
• Lags represent a real waiting or overlap condition, not a hidden duration.

Calendars, resources, and the basis of schedule

Working calendars should match how the project will actually be staffed: shutdowns, weather windows, shift patterns. A 7-day calendar on a 5-day site will later manufacture delay that is only a calendar artefact. Resource loading is not mandatory for every baseline, but where production rates are the real constraint, a labour-free logic network will mislead.

The basis of schedule is the written companion to the file: data date, planning units, treatment of weather, allowances, interfaces with other contractors, and known exclusions. Without it, later arguments collapse into “that is not what we meant.” With it, an update can be compared like-for-like.

What a usable baseline is not

It is not a guarantee of on-time completion. It is not a claim narrative. It is not a replacement for a cost baseline or a risk register. Those instruments answer other questions. A programme that cannot survive first contact with progress reporting will not become more useful because it was formally “approved.”