The baseline is an intention, not a record.

The baseline is an intention, not a record.

This is the sentence to carry through the rest of the track. The as-planned programme is a model of how one party wanted to build the job. It was produced before anything was built, by somebody with a commercial interest in how it looked, and it records nothing that happened. It is the least factual document in the entire claim.

And nearly every delay method starts by trusting it.

Why this decides more than it should

The methods in the middle of this track are not equally dependent on the baseline, and the difference is not a detail.

A method that takes the baseline, inserts the delay events into it and re-runs the calculation is only as good as the model it re-runs. If the logic is wrong, the answer is wrong, and it is wrong with four decimal places of confidence.

That is the practical reason this phase comes before the phase on methods. By the time you choose a technique, the choice has largely been made for you by the quality of what you inherited.

What you are actually inheriting

On a real job you did not write this programme. The planner who did has gone to another project or another company. What you have is a PDF, possibly a printed copy in the contract documents, and if you're fortunate a native file that opens without warnings.

That is not a complaint, it is the normal condition. The question is what you do about it, and the answer is a short list of checks that has nothing to do with whether the bars look tidy.

Schedule Week 17 covered these as model health, which is what they are while a job is running. Here they are something else. A programme that fails them is not merely untidy — it cannot support a conclusion, and any conclusion drawn from it will be dismantled by the first person who opens the file.

The fifth question, which nobody asks

Those four checks test whether the model is coherent. They do not test whether it was ever going to work.

A baseline can pass every structural check and still be an aspiration. If it shows the forty-two piles finished inside a period that the rig on site could never have delivered, then the plan was already carrying delay on the day it was accepted — delay that belongs to whoever wrote it.

This matters because delay is measured as a departure from the plan. Measure against a programme that was never achievable and you get a number that includes the contractor's own optimism, dressed up as somebody else's fault. A reviewer who spots it does not argue about the rock at all. They argue about the durations, and they argue about them for free.

The test is not whether the plan was comfortable. It is whether the resources, the productivity and the access assumed in it were ones the job could actually have had. That question is far easier to answer in month two than in year three, and almost nobody asks it in month two.

One practical corollary: get the native file, not a printout. A PDF shows you the bars. It does not show you the logic, the constraints, the calendars or the float, which means it cannot answer a single one of the questions above.

Constraints, and how they lie

Of the four, the last is the one that changes numbers most quietly.

A constrained date does not describe a sequence. It overrides one. Put a fixed date on an activity and the arithmetic underneath rearranges itself: float appears where none was earned, or disappears where it existed, and the critical path is no longer a statement about how the work has to be built.

The awkward part is that constraints are often placed for good reasons — a sectional date, an access restriction, a possession window. Nobody is being dishonest. But an analysis that runs a delay through a constrained model and reports the answer as though it came from the logic has reported something other than what it thinks.

The programme was drafted by somebody with an interest

Now the uncomfortable part, and the literature is blunt about it: there is a recognised set of programming practices designed to improve one party's position in a later argument. Not errors — choices.

Compressing the periods allowed for the employer's design or drawing reviews is one. An early completion programme, showing the works finishing well before the contractual date, is another; it manufactures a stretch of time that any employer delay will appear to consume. Sequences arranged so that everything runs through activities the other side controls is a third.

None of this needs to be treated as an accusation. It needs to be treated as a reason to look. The baseline is the other side's document as much as your own, and the person reviewing your claim will be reading it with exactly this list in mind.

Which programme is the programme

There is usually more than one, and the difference is contractual rather than technical.

There is the one submitted under the contract, which under Contract Week 11 becomes the Programme once the review period passes without objection. And there is the one the team actually works to, which by month three has been resequenced twice and never went anywhere near the Engineer.

Analyse the second and you are describing the job. Analyse the first and you are describing your entitlement. They are different exercises, and the mistake is doing one while believing you are doing the other.

If you have to rebuild it, do it in daylight

Sometimes the baseline is unusable and there is no way forward except to correct or reconstruct it. That is permissible. What is not permissible is doing it quietly.

Every departure from what the contractor originally produced has to be visible: what was changed, why, and what it did to the answer. A reconstruction whose changes cannot be substantiated does not merely weaken that part of the analysis — it puts the whole conclusion in question, because the model has become the analyst's rather than the project's.

Practical insight

Open the accepted baseline on your current job and spend twenty minutes doing four things.

Count the activities with no successor. Count the constrained dates and write down what each one is for. Find the longest continuous chain from start to completion and check that it actually reaches both ends. Then compare the total scope in the programme against the bill or the activity schedule, at the level of major elements only.

You aren't looking for perfection and you won't find it. You're looking for the two or three findings that would change an answer, and for whether you would be comfortable if the other side found them first.

Write what you find in a dated note, now, while the job is running. If the baseline is weak, the most valuable thing you can do is know it in month four rather than in year three — because in month four you can still fix the record that a weak baseline will force you to rely on instead.

Key takeaways

✔ The as-planned programme records an intention, not a fact, and it was drafted by a party with an interest in how it looked.

✔ Methods that re-run the baseline die with it; methods built from what happened survive it, which is why the baseline quietly chooses your method.

✔ Four checks decide whether it can carry a conclusion: complete scope, a continuous chain, no open ends, and dates held by logic rather than by constraints.

✔ A constrained date overrides the sequence, creating or destroying float that no logic earned.

✔ A structurally sound baseline can still be unachievable, and delay measured against an unachievable plan silently includes your own optimism.

✔ Compressed review periods and early completion programmes are recognised tactics, and the reviewer of your claim knows them.

✔ The submitted programme and the working programme are different documents; one describes the job and the other describes your entitlement.

✔ Any correction to the baseline must be transparent, because unsubstantiated changes put the whole analysis in question rather than just that part.

What's coming next

If the plan is an intention, the facts have to come from somewhere else. Next week is the record the job produces every day without thinking about it — the daily reports, the allocation sheets, the diaries — what each one can actually prove, and why the document that looks most like evidence is usually the one that is not.