A key costs nothing until records exist.

What this week isn't

Four other weeks on this site own the techniques and this one borrows none of them. Schedule Week 10 builds a work breakdown structure. Cost & Cash Week 6 takes apart the cost breakdown structure and the code of accounts. Reporting Week 2 designs a data table backwards from the output it has to produce. Reporting Week 3 builds the mapping from drawings to activities.

What none of them asks is when any of it can be done. That question has a hard answer, and the answer is the reason a project that skipped this in month one is still paying for it in month thirty.

It is worth being clear that skipping it is the normal outcome rather than an oversight. In week one there is no report anybody is waiting for, no argument the structure would settle, and nothing yet visibly broken. The work has no deadline, no requester and no symptom — which is exactly the profile of work that doesn't get done.

Every arrow is a join

A planning engineer whose account runs through this phase sets out the chain a project controls system actually is:

BOQ → WBS → Activity → Planned Quantity → Daily Production → Actual Quantity → Progress → Schedule Update → Reporting

On the project he describes, some of the links in that chain were missing or disconnected from each other. Codes, quantities, dates and work items had to be brought into correspondence before anything could be produced, and understanding how the existing arrangement worked meant taking it apart to find out.

Read the chain as a data structure and each arrow is a join between two record sets. A join needs something in common: a key that exists in both, spelled the same way, meaning the same thing.

Two of those three conditions get attention and the third has no natural moment at which anybody checks it. Everybody notices when a code is absent. Fewer notice when the same code means a slightly different extent of work on each side — the bill item covering material the activity excludes, or the activity spanning two structures the report counts separately. That join runs, produces a number, and the number is wrong in a way no check catches.

What a broken link actually is

This is the reframing the week turns on, and it changes what you go looking for.

When a link in that chain is broken, the visible symptom is a report that can't be produced, or a number that has to be estimated, or two figures that disagree. So the instinct is to work on the report.

But the report is downstream of the problem. A broken link is a missing key — two record sets describing the same work with nothing in common that a machine could match on. No amount of work on the output fixes it, because the output is being asked to recover a relationship that was never recorded.

Which is the same defect this track has met at every stage, in its purest form. The relationship existed in somebody's head when the records were created. It was never written into the records themselves. Everything downstream then has to reconstruct it.

The link a person is holding

Where a key is missing, the join still happens, because reports still go out. Somebody is doing it.

They know that the bill item for the pump house slab is the one the site calls the west pad, that the activity covering it is the one with the wrong description from the tender programme, and that the batching plant tickets for it are coded to a delivery point rather than to a structure. They hold three mappings in their head and they apply them every month without noticing.

The system works. It works at the speed of one person, it can't be checked by anybody else, and it stops the day they leave — not gradually, but at once, because the mappings were never anywhere else.

That is the whole of what last week called responsibility without access, seen from the other side: here the access exists and the meaning is missing.

Registers you can open late, and registers you can't

The same timing question applies to registers, and it splits them into two kinds that are worth telling apart on day one.

Some can be started whenever somebody gets round to it. A lessons log, a photographic record, a stakeholder list — opened in month eight, they are eight months of value rather than none, and nobody is misled.

Others are only meaningful complete from the first record. A transmittal register, a register of instructions, a log of access given against contractual dates. Started late, these are worse than absent, because a register looks complete. Anybody reading it assumes the entries before the first one don't exist, rather than that they were never written down — and the assumption is invisible.

So the question to ask of every register in the first fortnight isn't whether it is useful. It is whether a gap in it will be visible later. Where the answer is no, it has to start now or not at all.

System design

Row one carries the requirement that distinguishes a coding structure from a list of codes: the rule joining each scheme to the next. Three well-designed schemes with no stated relationship between them produce exactly the problem this week describes.

Record	Produced by	Required quality	Verified against	Feeds
Coding structure	The project, in week one	States the rule joining each scheme to the next, not just the schemes	One work item traced end to end	Every join in the chain
Identifier map	You, in an afternoon	One work item, every document, every identifier it carries	The documents themselves	Which joins are real and which are human
Naming convention	Whoever opens the first folder	Carries the reason, so the next person extends it rather than replacing it	The structure it serves	Every file created afterwards
Registers that must start at record one	Day one, or never	Complete from the first entry, because a gap won't be visible	The first transaction of each kind	Any later question about sequence
List of human-held joins	You, from the identifier map	Names the person and the mapping they are holding	What breaks when they are absent	What has to be written down first

Row five is uncomfortable to write and worth writing anyway. It names colleagues as single points of failure, which isn't a judgement on them — they are holding the project together. It is a list of what has to be written down before somebody takes annual leave.

Practical insight

Take one piece of work — a slab, a run of pipe, something you can point at — and walk it through every document that touches it. You need an hour and nobody's permission.

Write down the identifier it carries in each. Its bill item reference. Its WBS code. Its activity ID. What the daily report calls it. What the delivery notes are coded to. What the surveyor's measure is filed under. Six or seven rows on one page.

Then read down the column of identifiers and mark every place two of them differ with no rule connecting them. Each mark is a join somebody is currently performing in their head, and the set of marks maps exactly how much of your reporting depends on one person's memory.

Do it in your first month and the marks are a design problem: a shared field can still be added to a sheet with forty rows in it. Do it in month twenty and the same marks are a description of the situation, because the sheet has thousands of rows and nobody is going back through them.

The exercise costs you an afternoon either way. Only one of your two afternoons changes anything, and you are the one choosing which of them you spend.

Key takeaways

• The same piece of work carries three unrelated identifiers across the bill, the programme and the daily report.
• Relating them costs an hour on day one and a retrospective re-code of three systems by month twenty, which is why it stops being done.
• So coding isn't a technique applied when convenient. It is a decision with an expiry date measured in weeks.
• Read the chain from bill to report as a data structure and every arrow is a join between two record sets.
• A join needs a key that exists in both sets, spelled the same and meaning the same.
• A broken link is therefore a missing key rather than a bad report, and no work on the output recovers it.
• Where a key is missing the join still happens, because a person is holding the mapping in their head and applying it every month.
• That system runs at the speed of one person, can't be checked, and stops at once when they leave.
• Registers divide into those that can be opened late and those that are only meaningful complete from the first record.
• A register started late is worse than absent, because it looks complete and the missing entries read as entries that never existed.
• The test for any register is whether a gap in it will be visible later. Where it won't, it starts now or not at all.

Records born here. The coding structure and the rule relating each scheme to the next · the identifier map for one work item, proving the joins exist · the registers that must be complete from record one, opened · the list of joins currently held by a person · the naming convention, with the reason it was chosen.

What is coming next

With the structures in place there is a programme to build, and a fixed period in which to build it.

The method belongs to another track and has done since week one of this site. What has never been described is the fortnight itself: what gets decided under that much time pressure, which of those decisions are permanent, and why the document that comes out of it is treated for the next three years as though it had been produced with information nobody had.