In practice · 07 of 09
Our estimates are planning poker.
Clients pay for not understanding their own systems every single day, and it never appears as a line item.
The cost that has no cost code
Every release is a gamble, so the team asks whoever has been there longest. An estimate is produced by a group of people reasoning from memory about a system none of them has read in full. The estimate is wrong in a distribution rather than a direction, which is why averaging more opinions does not fix it.
Then the work takes longer than planned, or it lands and breaks something nobody predicted, and both outcomes are recorded as delivery performance rather than as the information problem they are. There is no budget line for not knowing, so the cost is absorbed into everything else and never argued about.
Dashboards that report the symptom
Most engineering organisations now measure change failure rate, lead time and deployment frequency, and most of them can tell you the numbers are bad without being able to tell you why. That is not a failing of the metrics. Those measures read the delivery process. They do not read the system, so they can report that changes fail and cannot say which parts of the estate make them fail.
The useful question sits underneath the dashboard. Which components carry a change failure rate several times the average. Which are touched by every release regardless of what the release was for. Where a small change reliably becomes a large one, and why.
This is the one situation where you already hold the baseline. The incident record, the release history and the change log are already in your own systems. Nobody has to be persuaded to fund a measurement exercise first, and nobody can argue with their own data. That makes this the cheapest place to prove that the argument works before committing to anything larger.
What changes when the estimate is grounded
- Estimates stop being a negotiation. A range grounded in what a change actually touches is defensible in a way that a consensus of recollections is not.
- Sequencing improves before capacity does. A high proportion of delivery pain is a small number of components, and knowing which ones changes what you do first.
- A rate review becomes a productivity conversation. If you can evidence what a unit of change costs and why, you are no longer arguing about a day rate.
The vendor conversation this feeds
The unit cost of a supplied engineer has not moved, even though the tooling around that engineer has changed materially. A single-digit discount at renewal does not reflect what has actually happened to delivery, and it is offered precisely because the buyer usually cannot evidence the gap.
The buyers who have done best in that conversation are the ones who arrived with their own evidence of what a unit of change costs, rather than with a target percentage. Time and materials pricing is under real pressure, and the pressure is only available to a client who can quantify it.
Common questions
We already run DORA-style engineering metrics. Is this duplicative?
No. Those measures read the delivery process and are worth keeping. They report that changes fail. They cannot say which parts of the estate cause it, because they do not read the system. This sits underneath them and explains the number they already have.
Is this an engineering productivity programme?
Not in the usual sense. We do not manage your engineers or run your delivery. The work is to make the cost of not understanding the estate visible, and to hold the improvement to a measure declared before the work started.
How quickly does this produce something usable?
Faster than most, because the baseline already exists in your incident and release records. The first useful output is a comparison between what your delivery data says and what the estate itself says, and that is a matter of weeks rather than a programme.
When this comes up. Comes up after a serious incident, a missed commitment, or at a vendor rate review.
How it is delivered
Compass against the existing incident and release records, then Watch where the improvement has to be held over time. Each module is a fixed deliverable behind a go or no-go gate, and the baseline earns the design. The full set of modules is here.
Related situations
- AI enablement on a legacy estateEstablish which parts of the estate are safe to point an agent at, and why the rest are not.
- Sovereign and in-tenant deploymentA qualifying gate rather than an engagement. Nothing crosses the boundary.
- Key person risk and knowledge transferEvidence what depends on fewer than three people, then design the transfer around it.
Tell us what you are trying to land.
A short conversation about your situation and whether an independent accountable role is the right instrument. If it is not, we will say so. No deck follows automatically.