On a live programme the work has already started. Drawings are late, a package has moved, and the last report still shows a finish date nobody on site believes. Project controls is often described as reporting. That is the visible part. What it actually protects is smaller and more useful: the right to make a decision from a record that still matches the job.
If that record is wrong, the meeting can still be confident. Confidence is not protection. The sections below are the things a controls function is there to keep intact once the programme is live.
The decision, not the slide
A steering group needs one question answered: what changed, and what do we do before the next period? A pack that restates percent complete does not answer it. Controls protects the decision by separating three facts that get blended in conversation.
- What was supposed to be done by the data date, taken from the approved baseline.
- What is actually done, taken from progress the site will stand behind.
- What the remaining network now says about key dates, after logic is recalculated.
Those three are not the same number. Planned value, physical progress and a forecast finish can point in different directions. The protection is in showing all three, with the critical path that produced the forecast. A single green status removes that protection.
The baseline as a benchmark, not a souvenir
Once the job is live, people treat the baseline as the picture from award, useful for nostalgia and awkward in a claim. It is the benchmark. Schedule variance, float loss and a later extension all depend on being able to say what was agreed.
Controls protects the baseline by not quietly rewriting it. Out-of-sequence work, a new constraint and a changed method belong in the update, or in a revised programme if change control says so. They do not belong in a silent edit of the original file. A baseline that is edited to match the site protects nobody. It only makes the variance disappear.
The critical path as a route, not a colour
On a live programme the critical path moves. A late design release, a missed possession or a crew pulled onto another package can put a new chain in front of the finish. The protection is a path the team can walk: named activities, real relationships, and a reason the float is what the software says.
Colouring a bar red is not that walk. If the path runs through a constraint that was typed in to hold a date, or through an open end that was never closed, the finish date is an instruction, not a calculation. Controls protects the path by testing it after every update, not by publishing the date the room prefers.
The record you will need later
Live programmes generate arguments. A variation, a late access date, a weather window, a notice under the contract. Months later, the only honest evidence is the schedule as it stood at each data date: progress, remaining duration, logic changes and the narrative that went with them.
That record is what forensic delay analysis uses. It is also what a project director uses in the week the event happens, which is the better time. Controls protects it by saving the update, not by keeping a single file that is overwritten every Friday.
What it does not protect
It does not protect an optimistic finish. If remaining durations are still the tender allowances and the site has half the labour, the forecast is a wish. Controls can show that. It cannot make the wish true.
It does not protect a commercial position that the logic does not support. A notice that says the critical path moved, when the file shows the path held by a mandatory finish, will not survive a review. The protection runs the other way: do not file a position the schedule cannot explain.
It does not replace the people who know the work. Planners do not invent progress. Site, engineering, procurement and commercial teams owe the update the facts. Controls protects the programme only when those facts arrive before the report, not after the slides are printed.
What to check on a live programme this period
| Check | What it protects |
|---|---|
| Data date and remaining duration | The forecast is calculated from unfinished work, not from a moved bar |
| Out-of-sequence progress | Started work is not hiding a broken predecessor |
| Float on near-critical paths | Pressure is visible before the path becomes the finish |
| Change since last period | The narrative matches the file |
| Baseline left intact | Variance still means something |
Do that before the report cycle, not as a tidy-up afterwards. A health review of the file is cheaper than a month of decisions taken from a path nobody can defend.
The practical standard
Project controls on a live programme is working when a person who was not in the update meeting can open the file and see why the date moved. The decision is protected because the facts are separable. The baseline is protected because it was not edited to hide the variance. The path is protected because it can be walked. The record is protected because this period still exists next year.
That is the job. The report is only how the job is shown.
