What one item of work actually costs to produce

Ask a software supplier what a single delivered item cost to produce and you will usually get a day rate multiplied by an estimate. That is not a cost. It is a price with a story attached.

We meter it instead. Every delivered item carries the machine cost of producing it, recomputed from the work record rather than typed into a slide. We can tell you what a given change cost — and, more usefully, what a proposed one would cost before you commit to it.

The interesting number is the unflattering one

12.1% of that spend went on rework. We show it as its own line rather than absorbing it into the total, because a rework figure you cannot see is a rework figure nobody manages.

The same board reports that time lost to queueing rose sharply as more work ran in parallel. That reading is on the board today. It is not a good number, and hiding it would make the rest of the board worth less.

Why metered cost changes the conversation

When the unit cost of delivery is visible, scope stops being a negotiation about day rates and becomes a question about value. You can ask whether a feature is worth fourteen dollars of machine time and a review cycle. That is a much better question than whether it is worth three developer-days.

• The price of the work and the evidence it went out clean come from one record
• Rework is measured separately, so it can be attacked rather than absorbed
• Cost per item, per feature and per specialist sit on the same board as progress

None of this makes the work cheaper by itself. It makes the work legible, and legible work is the only kind you can improve.