Unit economics
What the projects actually earned, once someone put cost next to revenue
Margin was assumed to be about half. Reading revenue, cost and hours together showed a spread from a third to three quarters — and one project that had quietly overrun its ceiling without a change request.
- Actual margin spread against an assumed 'about half'
- 34% – 76%Actual margin spread against an assumed 'about half'
- One project past its contractual ceiling, with no change request
- +12.6%One project past its contractual ceiling, with no change request
- Realised hourly rate landed at the low end of the nominal range, not the middle
- Bottom of the cardRealised hourly rate landed at the low end of the nominal range, not the middle
The client
A software services company delivering fixed-envelope and time-based engagements across mobile, discovery and platform work, where margin had previously been inferred from invoices alone — revenue visible, cost not.
The engagement
A portfolio unit-economics review across six project phases, reconciled against invoices, time reports, work orders and an external client report.
The problem
In a services business, margin is usually inferred from invoices — which shows revenue and hides cost. That produces a comfortable average and no ability to answer the questions that matter: which engagement types actually pay, whether long projects earn their length, and whether anyone noticed a project passing its ceiling.
What I did
I put cost next to revenue for every project phase and reconciled the result against invoices, time reports, work orders and the report the client had been sent. Three things came out that no invoice would show. First, the margin spread was enormous — short discovery engagements earned three quarters, the longest running project earned a third — which means length is a margin risk, not a margin annuity. Second, the realised hourly rate landed at the bottom of the nominal card rather than the middle, and the mechanism was identifiable: hours booked at zero sale rate for rework and shadow work, and a prepayment invoiced at a superseded rate after a work order had already raised it. Third, one project had finished more than a tenth above its own maximum envelope with no change request anywhere in the file. I also documented the one estimate that disclosed its own method — how overheads are calculated, and that the risk buffer applies only to development rather than to the whole subtotal — because a method you can read is a method you can argue with.
What was built
A reconciliation of revenue, cost and hours per project phase against the commercial documents, exposing the realised hourly rate versus the nominal rate card, margin by project type, the relationship between engagement length and margin, and the specific mechanisms — unbilled rework, prepayments applied at superseded rates — that erode the gap between quoted and realised.
On the table at the end
- Portfolio margin table by project phase
- Realised versus nominal rate reconciliation
- Estimate-envelope breach analysis with the missing change request identified
- Estimate structure documented: overheads, risk buffer basis, what the buffer is calculated on
What it changed
Made per-project economics visible for the first time — the true realised hourly rate, the real margin spread, and a project that had exceeded its contractual ceiling by more than a tenth with no change request on file.
How it ran
- 01
Put cost beside revenue
Every project phase reconciled with hours, so margin stops being a company-wide average and becomes a per-engagement fact.
- 02
Test the assumption
'About half' turned out to span a third to three quarters — with the shortest engagements the most profitable and the longest the least.
- 03
Find where the rate leaks
Zero-rate rework lines and a prepayment issued at a superseded rate, each traced to the specific invoice.
- 04
Check envelopes against actuals
One project past its maximum by more than a tenth, with no change request — found by comparing the estimate envelope to billed hours, not by anyone raising it.
- 05
Document the estimating method
Overhead percentages and the risk-buffer basis written down, so future estimates are comparable and challengeable.
Other work
All case studies →- Software services
Nineteen estimates, one register, five minutes to an answer
Four years of pricing lived in spreadsheets nobody could open. I rebuilt the commercial history into one register — what was estimated, what it sold for, what happened next — and found that half the formulas were already dead.
- Portfolio management
Earned value that survives an empty project
Portfolio dashboards go green because the data model rewards going green. I built one that measures in hours, sorts by trouble, and refuses to report a number it does not have.
- Enterprise software
Restructuring the contract instead of working harder inside it
A fixed-price build went red when the client hired their own engineers and halved our share of the work. I proposed changing the contract model rather than escalating effort.
Something similar on your plate?
Thirty minutes, no deck. I will tell you whether it is worth doing at all.