Nobody owns this number.

That is not a discipline problem and it is not a software problem. Every one of those five people did their job. What was missing was written down nowhere: which of them the number belonged to.

What project controls actually produces

Start from the output, because the inputs only make sense backwards from it.

A project controls function produces a small number of things. A schedule and its updates. A progress figure. A cost report and a forecast. A cash flow. A look-ahead. A set of registers. A monthly report, and the four or five slides somebody presents from it.

That is most of it. Everything else is an intermediate step on the way to one of those, and every one of them exists to answer a question somebody is going to act on. The schedule answers when. The forecast answers how much, in the end. The look-ahead answers what can start on Monday.

None of them are produced by project controls. All of them are assembled by project controls out of material that belongs to other people.

Working backwards from a deliverable

Take any one of those outputs and ask three questions about every field in it. What is this? Who produces it? In what unit, and on which day does it close?

Do that with a monthly progress figure and the answer is not one department. It is quantities from site, measured or estimated. Hours from the timesheets. Materials from the store and from delivery notes. Approved drawings from document control, because work can't be claimed on a drawing that was superseded. Inspection sign-off from QA/QC. Committed cost from the commercial team, on their own cut-off date rather than yours.

Six sources, six owners, six different closing dates. The report has one date on it.

This is the whole reason the first half of this track is organised by department rather than by document. You can't understand a monthly report by studying the monthly report. You understand it by knowing what each department can and can't give you, and when.

Why the ownership question is the one that matters

Every input on that list has somebody whose job it is to know it. The site engineer knows what was built. The storekeeper knows what left the warehouse. Document control knows which revision is current. The quantity surveyor knows what was measured for payment.

Trouble starts when project controls fills a gap instead of naming it. The number is late, the report is due, so the planner estimates it. Once. Then it happens again, and after a few months the planner is not assembling the project's data, the planner is producing it.

At that point the question “whose number is this?” has no answer, and it has no answer precisely when you need one — when it turns out to be wrong.

The planner owns the reliability, not the number

Here is the distinction this entire track is built on, and it is worth stating plainly before any technique.

The planner doesn't own the data. The planner owns whether the data can be believed.

Those are different jobs and they need different behaviour. Owning the data means you write it. Owning its reliability means you find out who wrote it, check it against something produced independently, and refuse to publish a figure that nothing corroborates without saying so.

It also means you don't correct somebody else's number on your own. When two records disagree, the correction goes back to the person who reported it and the department that holds the contradicting record, together, and it stays open until they agree. A figure that gets quietly fixed in a spreadsheet is a figure nobody will defend three months later.

The report is the last thing you build

When a report comes out wrong, the first instinct is almost always to change the report. A column gets added to the spreadsheet. The dashboard is rebuilt. The chart is swapped for a better chart.

The report is rarely where the problem started. If a field was collected in three different ways by three different people, no amount of formatting reconciles them afterwards. If a field was never collected at all, it can't appear in an output however the output is designed. The report can only be as accurate as the thing feeding it.

Which gives an order of work, and it runs the opposite way to how most people approach it. The data model is designed first. Then the data is collected. Then it is verified. The report is what comes out at the end.

In practice you will rarely design that model. Most planners inherit one — the coding structure was set before they arrived, the system was chosen by somebody else, and the input sheets already exist. The realistic version of this work is not designing from nothing. It is understanding what you have been given, then finding the fields a report needs that the input sheet never had.

Either way the principle holds: a mistake is not corrected in thirty reports. It is corrected once, in the place it is born.

It is worth saying plainly, because most writing on this subject assumes the opposite. The best project controls system is not the one designed from nothing. It is the one that can take a system somebody else built, with everything already running on it, and make what comes out of it reliable. That is the job almost everybody actually has.

What this track is

Five tracks taught what to do with a number once you have it. Schedule Week 13 works out float. Cost & Cash Week 11 turns quantities into percent complete. Risk Week 8 puts a distribution around a duration. Every one assumes the number is already on your desk and is roughly true.

This track is about how it got there. The first half goes department by department: what each one can tell you, what it can't, and when it closes. The second half is what you issue back.

The name is slightly misleading, and it is worth saying so at the start. Reporting here is not the writing of reports. It is the trade that makes a report possible, and the writing is the smallest part of it.

System design

One column, not four. The question that has no answer when a figure is challenged is who owns it, and a table that also records who checks it and who approves it turns a single missing name into three arguments.

Record	Produced by	Required quality	Verified against	Feeds
Installed quantities	Site engineer	Against an activity and an area, in the unit of the bill	Store issues, survey	Progress, schedule update
Manhours	Supervisor	Allocated to activities, not just totalled	Attendance	Productivity, earned hours
Plant hours	Equipment department	Running hours separated from present hours	Operator log	Utilisation, method decisions
Material issued	Store	Issued quantity, not delivered quantity	Delivery notes	Progress corroboration
Drawing revision	Document control	Current status, and who holds it	Site spot check	Readiness, progress claim
Inspection sign-off	QA/QC	Tied to the activity, not just the system	Inspection record	Completion, handover
Commitments and accruals	Commercial	Coded to the same breakdown you report on	Invoices	Cost report, forecast

Fill it once, agree it in a meeting, and put it in the project execution plan. The value is not the table. It is that the argument about who owns a number happens now, in an hour, rather than in six months when the number is already in a report somebody is challenging.

Practical insight

Open your last monthly report and pick any five numbers from it. Next to each one, write a name. Not a department — a person, the one who would have to answer if that figure were challenged in a meeting tomorrow.

You will get three kinds of answer. Some have an obvious owner and you can write the name without thinking. Some have an owner you are not certain of, which means the number has been arriving for months without anybody confirming it. And some, when you are honest, have your name against them.

That third group is your real exposure. Every one of those is a number you produced because somebody else didn't, and every one of them will come back to you the first time it matters.

Key takeaways

• Project controls produces perhaps eight or nine things. Every one is assembled out of material owned by somebody else.
• Work backwards from a deliverable: what is each field, who produces it, in what unit, and on which day does it close.
• A single monthly progress figure draws on six departments with six different cut-off dates. The report carries one date.
• The failure is not a wrong number. It is a number with no owner, discovered at the moment it is challenged.
• Filling a gap once is help. Filling it every month makes the planner the producer of data they can't verify.
• The planner owns the reliability of a figure, not the figure itself.
• Corrections go back to the reporter and the record holder together, never into a spreadsheet quietly.
• A report can only be as accurate as what feeds it. Changing the report doesn't fix the collection.
• Data model, then collection, then verification, then report. The report is the output, not the starting point.
• Most planners inherit a model rather than design one. The real work is finding the field the input sheet never had.
• The best system is not the one built from nothing. It is the one that makes an inherited system reliable.

Records born here. Data ownership register · the input list behind each deliverable.

What is coming next

Before any department, the method. If a report can only be as good as its inputs, the way to find the weak one is to start at the output and walk backwards.

Next week: working backwards from a deliverable — and why the shape of a data table is a contract rather than a spreadsheet.