Forecast what work will cost. Do not track what it did.

Finance asks what the new platform work will cost. Engineering answers in FTE-months. Finance asks what that is in euros. Somebody opens a spreadsheet, and three months later there is a time-tracking initiative.

The initiative solves a different problem from the one that was asked, which is why it never satisfies anyone.

Two questions that sound alike

What will this cost? Asked before the money is committed. The answer changes a decision — whether to do it, whether to do it now, whether to do the smaller version.

What did this cost? Asked after. The answer changes nothing about the thing it measures, and it requires every person to log their hours accurately for months.

Almost every organisation that sets out to answer the first ends up building machinery for the second, because the second is measurable and the first is an estimate. Measurable beats useful in most procurement conversations.

The forecast is one multiplication

Take the capacity figure the delivering team gave — say four FTE-months. Multiply by an estimated monthly cost per person for that craft. That is the forecast.

It is approximate, and its approximation is the point: it is accurate enough to compare two options and to tell whether something is a €40k decision or a €400k one, which is the resolution the actual decision needs.

This is the whole reason to size work in FTE-months rather than story points . Points cannot be multiplied by anything. The conversion has to happen somewhere, and if the unit cannot do it, it happens informally in somebody's head — usually badly, and always without a record.

Why actual-cost tracking corrodes what it measures

Three failures, in increasing order of how much damage they do.

It needs accuracy it cannot get. Hours logged at the end of a week are reconstructions. Everyone knows this and the number gets used anyway.

It arrives too late to matter. By the time you know what something cost, you have spent it. Feedback that arrives after the only decision point is a report, not an instrument.

It changes behaviour in the wrong direction. The moment hours are attributed to projects, the attribution becomes political — time gets logged where it looks defensible, not where it went. So the data degrades exactly as it becomes important, which is the same mechanism that ruins every other consumption metric .

The one legitimate use, and how to serve it

Cross-charging is real. A shared platform team's cost genuinely has to be allocated across the business units it serves, and somebody has to produce the numbers.

But that needs allocation data, not consumption data: which demands consumed committed capacity from which teams, in which quarter, attributed to which cost centre. All of which is knowable from the commitments, forecast at planning time, and none of which requires anyone to log an hour.

The useful boundary: a delivery system should enable cross-charging by surfacing the allocation, and should not execute it. Finance has systems for that, and they are better than anything a delivery tool will build.

Who gets to see it

Per-person cost estimates are the most sensitive data in a delivery system, and the rule that keeps them usable is narrow: visible to whoever decides budgets, invisible to the person they describe.

This is not squeamishness. An estimated monthly cost is a planning figure, not a salary — it is rounded, role-based and often wrong at the individual level. Shown to the person it names, it reads as a statement about their worth, which it is not and cannot survive being mistaken for.

How DeliverySheet draws it

Cost is forecasting only. A per-person monthly estimated cost exists so a commitment can carry a defensible figure; multiplied by the committed FTE-months it produces the forecast. There is no time tracking, no actual-cost consumption, no payroll integration, and those are on a written list of things the product will never do — not a backlog.

Visibility is enforced on the server, not in the UI: the cost field is absent from the response entirely for anyone who should not see it, rather than sent and hidden. A field hidden client-side is a field that has already been sent.

Cost centres resolve through the org — person, then team, then department — and the interface shows only the final resolved value, not the inheritance chain. That was a deliberate call: the chain is implementation detail, and showing it invites arguments about routing rather than about the number.