Cost heads that survive a project

Every builder sets up a cost coding structure on day one. By month eight most of them wish they had set up a different one.

The reason is structural rather than careless. The structure is designed for the budget. The budget is a forecast made before anything was known — before the contractor was appointed, before the soil report changed the raft, before the finishes were revised. The actuals then arrive in the shape the invoices happen to have, which is the shape of your vendors' businesses and not of your forecast.

So a structure built for one purpose is filled by data generated for another. The mismatch does not announce itself. It surfaces the first time somebody asks a question the coding cannot answer.

The grain is wrong#

A head too coarse to be useful. "Civil works" as one head on a project that runs three years. Everything lands in it. The variance report says civil works is over budget, which you already knew, and cannot say whether it is labour, concrete, a rate revision or scope that was never in the budget at all. A head that cannot produce an action is a filing category, not a cost head.

A head so fine that nobody codes it consistently. The opposite failure, and it is commoner in offices that were burned by the first one. Sixty heads where twelve would do. The person coding cannot hold the distinctions in mind, so he picks by resemblance, and the fine structure fills with noise. Precision that is not achievable at the point of entry is not precision.

The same cost coded three ways. Shuttering hire booked to formwork by one person, to plant and machinery by another, to civil works by a third, each defensibly. Nobody is wrong. The structure permitted all three and never said which. Now no report on any of those three heads means anything, and the fault is invisible because every individual entry looks correct.

The structure moves under you#

A head invented mid-project. Something genuinely new arrives — a dewatering cost, an item of scope nobody foresaw — and a head is created for it. Sensible in itself. But the budget has no such line, so the comparison for that head is against zero, and the head it would otherwise have come out of shows an underspend it did not earn. Two lines are now wrong and only one of them looks it.

Renumbering. The quietest destruction available. Somebody reorganises the structure so it reads better. Every historical figure now sits under a code that means something else, and every comparison to last quarter is nonsense that still adds up correctly. This is the same disease that running account bills suffer when item codes change midway: the arithmetic survives, the meaning does not.

Coded to a project but not below it. Everything is tagged to the project. Nothing is tagged to a building, a tower, a wing or a floor. Then somebody asks what tower B cost — because tower B is sold to a different set of buyers, or funded by a different partner — and there is no answer that does not involve re-reading three years of invoices.

Contingency as a dumping ground. Contingency is meant for identified risk that may or may not occur. It becomes the head for anything that does not obviously belong elsewhere, because coding to contingency ends an argument. By the time it is exhausted nobody can say what it went on, which means nobody can say whether the project was over budget or merely mis-coded.

Overhead allocated with no stated basis. Head office cost is pushed onto projects by a method that lives in one person's spreadsheet. Change the method and the project's profitability changes without anything happening on site. If the basis is not written and not decided in advance, it will be questioned precisely when the number is inconvenient. Where several entities are involved the same problem sits one level up, in one builder, many companies.

What makes a structure survive#

It is decided by the person who will answer questions from it. Not by the accountant alone, and not by a software vendor's default chart. If the project head is the one who will be asked why tower B is over, he should be the one choosing the heads, because he is the only person who knows which questions get asked.

It is small enough to be remembered. The working test: can somebody coding an invoice list the plausible heads without opening a document? If he has to look it up, he will not, and he will use whichever head he remembers.

It separates what varies with quantity from what does not. Material and subcontract value move with what is built. Site establishment, supervision, plant on hire and finance do not, or move differently. Mixing them makes every per-unit figure a lie, and per-unit figures are what you carry into quoting a rate you can live with on the next job.

It never renumbers mid-project. Add a head if you must. Retire one if you must, and leave it in place, closed. Never reuse a code, for the same reason a bill of quantities keeps its item numbers to the end.

Coding happens once, at entry, by somebody who knows what the cost was for. Not later, by a person reading a description. The site engineer who raised the requirement knows what the material was for. The accounts assistant three weeks later knows only what the invoice says, and the invoice describes what the vendor sold, not what you used it on. This is also the moment when reconciling a vendor bill is cheapest, because the person who can answer the query is still nearby.

The short version#

A cost structure is designed for the budget and filled by the invoices, and that mismatch is the whole problem. Keep it coarse enough to code consistently and fine enough to answer the questions you actually get, including the ones below project level.

Fix the basis for allocations in advance, keep contingency for identified risk only, code at entry, and never renumber. A structure that survives a project is worth far more than one that was elegant at the start of it.