If a build has no agreed metric, its success becomes a matter of opinion. Opinion always favours whoever is presenting.
Not one of them skipped it on purpose. It just never came up. Everyone agreed the process was painful, everyone agreed automation would help, and the conversation moved on to scope. Six weeks later the system works and nobody can say whether it was worth doing.
So we ask for a number before we write code, and we agree it in the audit rather than after the build. Hours returned per week, response time, error rate, cost per order, revenue per head. One of them, named, with a target.
It has to be something the business already measures, or could measure by Friday. Better visibility is not a number. The weekly report takes one person a day and a half is a number, because in eight weeks it either takes ten minutes or it does not.
If we cannot say what would make this a failure, we are not engineering. We are building whatever was easiest to agree on.
Half the arguments about outcomes are actually arguments about the starting point. So we measure the current state before touching anything, even crudely: count the steps, time three real cases, pull the error log from last month. Nobody remembers the old process accurately once the new one exists.
A named metric is a design constraint, and a useful one. When the target is response time, we build the fast path first and leave the elegant admin screen for later. When the target is error rate, the budget goes on validation rather than interface. The number tells you what to cut.
Then we report against it, including when the answer disappoints. A system that returned six hours a week when we projected fifteen is still worth having, and pretending otherwise is how agencies lose the second project. The number keeps both sides honest, which is the entire point of naming it.
