The dates get argued. The structure doesn't.

Built while everything else is being built

The method isn't this track's subject and it is thoroughly covered elsewhere — Schedule Week 7 runs the development process, Week 10 the breakdown and the baseline, Week 11 the logic.

What none of them describes is the conditions. This fortnight runs at the same time as mobilisation, the execution plan, the access requests and the first submissions. The people who hold the inputs are the same people setting up the site. A question that would take ten minutes in month six takes three days now, because everybody it could be asked of is unpacking a container or interviewing a subcontractor.

So the programme isn't built from information gathered. It is built from information reachable within the fortnight, and the difference between those two sets is where every later argument lives.

That constraint is worth stating without apology, because the alternative framing does damage. A planner who believes the first baseline was a planning exercise will defend it as one. A planner who knows it was a two-week reachability exercise will revise it early and say why, which is the same document handled two entirely different ways.

Three sources for a duration, recorded identically

Open any first baseline and the durations in it came from three places.

Some are from the tender build-up: a quantity divided by an output rate, produced by an estimator, defensible and traceable. Some are a subcontractor's answer to a phone call, which is a commercial position rather than a plan. And some are precedent — the last job did it in five weeks, so five weeks.

Those three have entirely different reliability. The programme records them in the same field, in the same font, with no mark distinguishing them.

Which is the defect this track keeps meeting, arriving for the fifth time. Week 4 watched an assumption lose its label on the way into a tender pack. Week 5 watched an estimate lose its accuracy class. This is the same loss, on your own document, and it is the one instance you are holding the pen for.

What hardens, and what stays soft

Approval doesn't freeze a programme. It freezes part of it, and the part it freezes isn't the part anybody was looking at.

Soft, and revisable for the life of the job: durations, dates, resource assignments, most logic. These get revised monthly and nobody objects, because revising them is what a programme is for.

Hard, and effectively permanent from the first progress update: the activity identifier scheme, the calendars, the assignment of activities to the breakdown structure, and the level of detail. Not because a tool forbids changing them — because progress history attaches to activities. Change the identifiers and the record of what was achieved detaches from the thing that achieved it.

So the same expiry-date argument last week made about coding applies here, on a different object. The difference is that a coding structure at least gets discussed. Level of detail is chosen by whoever opens the file.

The decision nobody revisits

Level of detail deserves its own paragraph because it determines, permanently, what questions the programme can answer.

Too coarse, and progress can't be measured against it: an activity spanning four months and three work faces is never anything but partly done, and the percentage against it is a judgement rather than a measurement. Too fine, and it can't be maintained: a programme with an activity per pour is accurate for six weeks and then diverges, because updating it costs more than anybody has.

Both failures take months to become visible, by which point the history is attached and the choice is made. And the decision itself takes about a minute, in a fortnight where a hundred things take longer.

There is a test that helps and costs nothing. For each activity, ask who will report progress against it and what they will physically count. Where the answer is a number somebody reads off a measure or a ticket, the detail is right. Where the answer is that somebody will judge a percentage, the activity is too coarse to be measured and will produce an opinion every month for three years.

The inputs that don't exist yet

There is a harder version of this, and a planning engineer's account of a nuclear project describes it.

He had to build the structures for daily manpower, equipment and production quantities himself, in spreadsheets, because nothing existed that produced them. At one point roughly two hundred rows a day were being processed by hand, with weighbridge and delivery-note records cross-checked against daily production reports and equipment records.

That is what feeding a baseline looks like when the systems that should feed it aren't there. And it sets up a circular problem worth naming: the baseline needs data at a certain shape, the data systems that would produce that shape are designed around the baseline, and both are due in the same fortnight.

There is no clean answer to it. There is a practical one, which is to design the structure around what can actually be collected daily by somebody who isn't you, and accept that this constrains the level of detail more than any planning consideration does.

System design

Row three asks for one extra field on a table that already exists, and it is the cheapest correction available to any of the five losses this track has catalogued. A code letter against each duration costs nothing while the durations are being typed and can't be reconstructed afterwards.

Record	Produced by	Required quality	Verified against	Feeds
Baseline as submitted	Planning, inside the fortnight	Dated and kept as issued, separate from every later revision	The contract requirement	Every delay argument for years
Permanence list	You, before submitting	Names what can't change after the first update, and why	What progress will attach to	Whether the structure survives review
Source of each duration	Planning, as it builds	Marked build-up, subcontractor, or precedent — three reliabilities, one field	The estimate or the call it came from	Where to look first when one slips
Calendars	The same fortnight	Each one states what it assumes about working days and shutdowns	The contract and the site’s actual pattern	Every date the network calculates
Daily collection formats	You, with whoever will fill them	Collectable by somebody other than you, in the time they actually have	One week of real use	Whether the level of detail is sustainable

Row five is the one that decides whether the rest survives. A collection format that only works when you personally chase it is a format that stops working the first week you are somewhere else.

Practical insight

Before you submit, write your permanence list. One page, and it is the only page of the baseline anybody thanks you for two years later.

List the decisions you won't be able to change after your first progress update: the activity identifier scheme and its logic, the calendars and what each assumes about working days, which activities sit where in the breakdown structure, and the level of detail with the reason you chose it. Four headings, a few lines each.

Then get one hour of somebody senior on your page, and specifically not on your dates. The dates will get hours from everybody for the next three years. This page gets one hour, once, and only because you asked for it.

Ask the question directly rather than circulating the page and hoping: if I have these four things wrong, when do we find out? The answer will be the first progress update, which is what makes the hour worth requesting.

Attach it to your submission alongside the basis of the programme from week 8. Between them they say what your programme rests on and what it can never be asked to do — which is the whole of what a reader needs and the whole of what nobody writes down.

Key takeaways

• Almost all the scrutiny a first baseline receives goes on the dates, and the dates are the part that can be changed.
• The fortnight runs at the same time as mobilisation, so the programme is built from information reachable in two weeks rather than information gathered.
• Durations come from three sources — a tender build-up, a subcontractor’s phone answer, and precedent — with entirely different reliability.
• The programme records all three in the same field with nothing marking which is which, which is the fifth time this track has met that loss.
• Approval freezes only part of a programme: durations, dates and resources stay revisable for the life of the job.
• The identifier scheme, the calendars, the breakdown assignment and the level of detail harden from the first progress update, because history attaches to activities.
• Too coarse a level of detail makes progress a judgement; too fine makes the programme unmaintainable and it diverges within weeks.
• Both failures take months to surface, and by then the choice is fixed by the history hanging off it.
• Where the data systems don't exist yet, the baseline and the systems that feed it are due in the same fortnight and each is designed around the other.
• The practical resolution is to set the level of detail by what somebody other than you can collect daily.
• The permanence list takes a page and is the only part of the baseline that will never be revisited unless you force it.

Records born here. The baseline as submitted, with its date · the permanence list · the source of each duration, marked · the calendars and what each assumes · the level of detail and the reason for it · the daily collection formats the structure was designed around · the approval, and what it did and didn't approve.

What is coming next

The plan exists. What happens to it from here is decided in rooms, on a cycle, week after week.

Every project runs a set of recurring meetings and nothing in the process designs the set. It accumulates: one because the contract requires it, one because a manager wants visibility, one that started as a workaround for a problem now solved. Some of them decide things. Some of them exist so that the decision can be attributed elsewhere afterwards, and telling those apart is worth doing early.