One event. Two keyboards. Every error you have.
It is Monday evening. The core wall gang — five men and a crane — tied two point eight tonnes of reinforcement today. One thing happened.
It is about to be recorded twice, by two people, in two systems that have never met. And in the gap between those two records lives every wrong number your cost report has ever produced.
This week is short on new arithmetic and long on the reason the arithmetic keeps betraying you.
Watch the same Monday go into the building twice.
The cost system, and the schedule system
The quantity surveyor opens his spreadsheet. Five man-days, one crane-day, booked to cost code 03-140-10 — the superstructure reinforcement labour from Week 6. About thirteen hundred dollars of actual cost lands against that code.
Down the corridor, the planner opens the programme. The activity called “Core wall rebar” moves from wherever it was to twelve percent further along. Remaining duration updates. A progress line shifts.
Two records. The same five men, the same crane, the same tonnage — entered by two different people, into two different systems, under two different names. The cost system knows it as a code. The schedule knows it as an activity. Neither knows what the other did.
Now try to calculate earned value. Earned value needs cost and progress in the same place, divided by each other. But your cost is filed by code and your progress is filed by activity, and to bring them together somebody has to sit down, once a month, and match four hundred cost codes against two hundred schedule activities by hand.
That reconciliation is where cost control goes to die. It is late, it is manual, it is done under deadline by someone who did not do either of the original entries, and every mismatch — every code that maps to no activity, every activity with no code — becomes a number that is quietly wrong and confidently reported.
The paradox this explains
Go back to Week 8, to the number that should have frightened you and did not frighten anyone on the actual job.
The reinforcement package was at SPI 1.00 and CPI 0.67 at the same time. On plan and on fire. I told you a schedule report is structurally incapable of seeing the cost problem — and now you can see exactly why.
The gang tied the full 114 tonnes the plan asked for. That is a true fact, and it lived in the schedule system as good news: SPI 1.00. The same gang took 45.6 gang-days to tie what should have taken 22.8. That is the same true fact from the other side, and it lived in the cost system as a disaster: CPI 0.67.
One reality — full tonnage, double the hours — split down the middle and filed in two places that never sat next to each other. Neither system was wrong. Neither system was complete. And because the two halves never met on one screen, the contradiction that should have been obvious in month two stayed invisible until month six.
If a single record had said “full tonnage achieved, at twice the planned hours”, no site manager alive could have missed it. The problem was never the data. It was that the data was born in two places.
“Capture the event once, where it happens. Every time a fact is typed a second time, you have not made a copy — you have made a chance to disagree with yourself.”
— THE SINGLE-CAPTURE PRINCIPLE
Not one system. One entry — that both systems draw from.
Capture it once
The fix is not a bigger spreadsheet or a monthly meeting to argue the two systems into agreement. It is to capture the event a single time, at source, with everything about it attached.
One record, entered on the deck by the person who was there: the date, the cost code, the activity, the man-days, the plant, and the tonnes fixed — all of it, on one line, because all of it describes one event.
Then the cost system reaches into that record and takes the hours. The schedule reaches into the same record and takes the tonnes. Earned value is cost divided by progress, and now both halves come from the same line, entered once, by one person, at the moment it was true. There is nothing to reconcile because nothing was ever separated.
This is the whole of it. It sounds like an IT problem and it is really a discipline problem: a fact is entered exactly once, as close to the work as possible, and everything downstream is a view of that entry — never a re-typing of it.
Why this is the hinge of the whole track
Look back at what single capture quietly makes possible.
Week 6 insisted that cost and progress must share a cost code. Week 7 built control accounts where one owner sees both. Week 10 needed physical measurement and financial accrual to come from the same reality. Week 11 measured progress in tonnes so it could be divided into cost. Every one of those weeks assumed, without saying so, that the cost fact and the progress fact describe the same event and can be brought together.
Single data capture is the assumption made real. Without it, Week 6's shared code is just two systems using the same number by coincidence, drifting apart the first month somebody is busy. With it, the code is a genuine bridge, because the number underneath it was only ever entered once.
It is the least glamorous idea in the track and the one that makes all the others true.
Practical insight
Find out how earned value is calculated on your project. Ask to see the actual step where cost and progress come together.
If someone exports the cost ledger, exports the programme, and matches them in a third spreadsheet once a month — you have two-system capture, and your EVM is only as good as that monthly matching exercise, which is to say not very good and getting worse.
Then ask the site: when the foreman records what his gang did today, does he record the hours and the quantity on the same sheet, at the same time? If the hours go to the QS and the quantities go to the planner on two different bits of paper, you have found the exact keyboard where your cost report starts being wrong.
You do not need software to fix it. You need one sheet, filled in once, that carries both.
Key takeaways
✔ One event on site is routinely recorded twice — hours to the cost system, quantities to the schedule — by two people who never compare notes.
✔ Earned value needs both together, so the two get matched by hand every month: 400 codes against 200 activities. That reconciliation is where errors are born.
✔ Week 8's SPI 1.00 with CPI 0.67 stayed hidden for six months because the two halves of one fact lived in two systems.
✔ Full tonnage at double the hours is one record and an obvious alarm — but only if it is one record.
✔ Single data capture: enter the event once, at source, with hours and quantities together. Cost pulls one, schedule pulls the other.
✔ It makes Week 6's shared-code rule real — the code is a bridge only when the number under it was entered once.
✔ It is a discipline, not a system: a fact is entered once, near the work, and everything downstream is a view of that entry.
✔ You do not need software. You need one sheet that carries both the hours and the quantity.
What is coming next
Once the hours and the quantities live on the same line, a new number becomes available — one that is sharper than cost and faster than a valuation.
If you know the hours a gang spent and the quantity they produced, you know their productivity. And productivity turns overnight, long before the money catches up, which makes it the earliest warning you will ever get.
Next week: productivity control and earned hours — the leading edge of a cost problem, and how to read it before it reaches your report.
Enjoyed this lesson?
Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.
Already following on LinkedIn works too — this is just for the weekly email.