A system is what survives the person.

Seven things one person knew

On that project a substantial part of the planning and control arrangement lived in one individual's knowledge. When they left, the continuity broke.

What that person knew, and what was written down nowhere, was this: where each file came from; what each spreadsheet was for; who each piece of data came from; how each report was prepared; how progress was tracked; which activity related to which physical work; and which data could be trusted.

Read it as a list of failures and it's depressing. Read it backwards and it is a specification. A project controls system is the written form of those seven answers. Everything else — the tool, the templates, the report layouts — is the surface it is delivered on.

And notice what is absent from the list. Nothing on it is about method. There is no item about which technique to use for progress measurement or which software to standardise on. All seven are about where things come from and whether they can be relied on, which isn't the subject most project controls training covers.

Which is a test you can apply on any project in an afternoon, including one that appears to be running well.

Reverse engineering is the first job

Understanding what already existed meant working backwards from the spreadsheets, the reports and the data, and then working out how they related to each other.

That's worth naming as the first task rather than as evidence that something has gone wrong. Arriving at a running project, you aren't building on empty ground; you are surveying a structure whose drawings were never made, and every hour spent on that survey is the only way the seven answers get recovered while anybody is still around to confirm them.

It's also got a natural output. The by-product of reverse engineering a system is the documentation that system never had — which nobody will ever fund as a task in its own right, and which you produce for free by doing the work you have to do anyway.

That only happens if you write the survey down as you go. Done in your head, it produces the same situation you arrived into, with a different person at the centre of it.

The system isn't the tool

The most compressed thing in that account is what a control system actually consists of.

Not the planning file. Not the report. The system is where the data comes from, how it is validated, how it is measured, how it connects to the programme, and how it finally reaches management.

Five links, and a project can have an excellent tool with three of them missing. That is the situation this track has met repeatedly under different names: the join with no key in week 12, the figure that arrived without its basis, the register that recorded issue rather than outcome. Each was one of those five links, absent.

Which explains a pattern worth recognising when you arrive somewhere. A project with a well-maintained planning file and unreliable reporting hasn't got a planning problem. It has a provenance problem, three links upstream, and no amount of work on the file will reach it.

Build the chain, not the report

The same account sets out the chain the whole arrangement is meant to be: from the bill, to the breakdown structure, to activities, to planned quantities, to daily production, to actual quantities, to progress, to the schedule update, to reporting.

On the live project some of those links were missing or disconnected from each other, and codes, quantities, dates and work items had to be brought into correspondence before anything could be produced at all.

Which gives the ordering principle for somebody arriving with nothing. The temptation is to fix the report, because the report is what is late and what people are asking for. The report's the last link. Fixing it produces a document that looks better and is fed by the same broken chain, and you will fix it again next month.

There is also a diagnostic in the order things break. A chain that fails at the reporting end produces arguments about presentation. A chain that fails at the provenance end produces arguments about whether the numbers are right, and both symptoms get blamed on the same function.

What to build first

Given a finite first month, the order that follows from all of the above isn't the order of urgency.

Establish provenance first — for each number you have to publish, where does it come from and who produces it. That is the first of the seven answers and nothing downstream is worth building without it.

It's also the only step that can be done entirely by asking. No access, no tool licence, no permission from anybody: a fortnight of conversations and a page of notes, which is what makes it the right thing to do in a first month where you may have none of the other three.

Then the joins: whether the identifiers on either side of each handover actually match, and where a person is currently doing the matching. Then validation: what check would reveal that a figure is wrong, and does anybody perform it. Then the routine, which is week 14's finding — what survives is what attaches to a weekly rhythm.

The report comes last, and by the time you get there much of it writes itself, because a report is a view of a chain that works.

None of that arrives as a plan anybody asked for, which is why it needs stating to somebody. A month spent on provenance looks, from outside, like a month in which no report improved. Saying at the start what you are doing and in what order converts that into a sequence people can wait through.

System design

Row one is the whole week and it is the only record in this dictionary whose required quality is that a stranger could use it. Which is also the test, since a document that needs its author present is the thing it was written to replace.

Record	Produced by	Required quality	Verified against	Feeds
The seven answers	You, in your first month	Written so a stranger could follow them without asking anybody	Handing them to somebody new	Whether a system exists at all
Provenance map	You, per published number	Source and producer named for every figure you issue	Tracing one number to its origin	Everything downstream of it
Human-held joins	You, from the map	Names who is currently matching what, and against which fields	What breaks when they are away	What has to be written down first
Validation check per figure	You, one line each	The check that would reveal the figure is wrong, and who runs it	One month of it actually running	Whether a number is usable
Reverse-engineering notes	You, while surveying	Kept rather than discarded, since they are the missing documentation	The system they describe	The next person to arrive

Row five asks you to keep working notes that get thrown away by default. They are a survey of a structure whose drawings were never made, and nobody will ever fund making them again.

Practical insight

Take the seven questions to your own project this week, whatever state you think it is in.

For each one, ask where the answer is written down. Where each file comes from. What each spreadsheet is for. Who supplies each piece of data. How each report is prepared. How progress is tracked. Which activity relates to which physical work. Which data can be trusted.

Seven questions, and the only answer that counts is a document somebody who has never met you could read. Being told to ask a particular colleague isn't an answer to any of them. It is the diagnosis.

Then write down whichever ones failed. That page is the specification for the system you don't have, it took you an afternoon, and it is the single most useful thing you can produce in your first month on any project — including one where everything appears to be working, because everything appears to be working right up until the person leaves.

Key takeaways

• Arriving at a running project with no system, no reliable baseline and a report due on Friday is the ordinary posting rather than the unusual one.
• If the system is in one person’s head, there is no system — there is a person.
• Seven things that person knew were written down nowhere: file origins, spreadsheet purposes, data sources, report methods, how progress is tracked, activity-to-work relationships, and which data can be trusted.
• Read backwards, that list is a specification: a control system is the written form of those seven answers.
• Reverse engineering what exists is the first task, not evidence that something has gone wrong.
• Its by-product is documentation the system never had, produced free by work you had to do anyway.
• The system isn't the planning file or the report. It is where data comes from, how it is validated, how it is measured, how it connects to the programme, and how it reaches management.
• A project can have an excellent tool with three of those five links missing.
• The chain runs from bill to breakdown to activity to planned quantity to daily production to actual quantity to progress to schedule update to reporting.
• Fixing the report first produces a better-looking document fed by the same broken chain, and you fix it again next month.
• The build order is provenance, then joins, then validation, then the routine, and the report last.
• The only answer that counts to any of the seven questions is a document a stranger could read.

Records born here. The seven answers, written down · the provenance map for every published number · the joins, with the ones a person is currently making · the validation check for each figure, and who performs it · the routine each output attaches to · the reverse-engineering notes, kept as the documentation the system never had.

What is coming next

That is what to build. The last week is about the order and the calendar — what actually fits into ninety days, what has to wait, and what you will be judged on before any of it is finished.

Because arriving with nothing isn't only a design problem. It is a sequencing problem, conducted while producing the outputs the job was hired for, in front of people forming a view of you in the first fortnight.