The Outcome Is the Unit of Delivery
Most delivery is measured in artifacts because artifacts are countable. The question worth asking is what an organization is actually buying, and whether anyone is accountable for it.
What gets counted instead
Ask what a piece of work delivered and you will usually get a list of things that now exist. A platform. A report. A set of recommendations. A migration completed on schedule.
Each of those is real, verifiable, and easy to agree on, which is why they became the currency. They also have a common property. Every one of them can be entirely true while nothing about the way the work moves has changed.
The countability is doing more work here than it appears to. An artifact can be checked by someone who was not present, at a fixed moment, without judgment. That property is what allows a contract to close, an invoice to clear, and a status report to be believed by a reader three levels away from the work. Outcomes have none of it. They arrive late, they are contested, and they require somebody to exercise judgment about attribution. Given a choice between a measure that settles cleanly and a measure that matters, the machinery of delivery will choose the one that settles.
The gap nobody owns
Between a working artifact and a changed operation there is a stretch of work that most delivery structures leave unassigned.
Somebody has to make the new path the path of least resistance. Somebody has to notice that a third of cases do not fit and decide what happens to them. Somebody has to be present when the first exception arrives and the organization is deciding, informally and permanently, whether the new system is to be trusted.
In the work I have done, that stretch is where most of the effort actually went, and it was almost never in the plan.
The trust decision in particular is worth naming because it happens once and then hardens. An organization forms its view of a new system in the first two or three difficult cases, and the view it forms is not really about the system. It is about what happened when the system did not know what to do and a person had to decide whether to fight it or route around it. Route around it once successfully and the workaround becomes the process, and no amount of subsequent improvement to the system recovers the ground. That moment is entirely predictable and it is almost never staffed.
You will not find any of it in a scope document. It is real work, it determines whether anything changed, and in most engagements it belongs to nobody. The artifact was the deliverable, the artifact was delivered, and the gap is treated as the client's problem.
What counts, and what only looks like it
Outcome is a word that decays quickly into whatever the speaker wants it to mean, so it needs constraints.
Three of them do the work. It has to be a change in the operation rather than in the tooling, which is the difference between reporting getting faster and decisions getting made earlier because the reporting arrived in time. It has to be named before the work starts rather than selected afterwards from whatever happened to move, since choosing the metric at the end is how every intervention succeeds. And it has to survive the withdrawal of attention, because a number that improves while a project team is in the building and reverts within a quarter measured the project rather than the system.
The third constraint is the one that separates a real change from an expensive Hawthorne effect, and it is the one most often skipped because it requires waiting. A measure taken at go live and a measure taken two quarters after the last project person left are different measures, and only the second one is evidence. Building the second measurement into the arrangement at the start, when everyone is optimistic, is far easier than requesting it later, when the result has become someone's reputation.
Which brings up the proxies. Adoption, satisfaction, usage, on time delivery. All of these get reported as outcomes and all of them are proxies.
They persist because they are available early, they are unambiguous, and they are within the delivery team's control, which makes them comfortable in a way real outcomes are not. High adoption of a system that automates a step which should not exist is a well executed failure. It will look excellent in every report.
The test for a proxy is whether it could be fully satisfied while the thing you actually wanted did not happen. Most of them fail that test immediately, which does not make them useless. It makes them instrumentation rather than objectives.
The distinction is practical. Instrumentation tells you whether the mechanism is behaving: low adoption is a genuine signal that something is wrong, and worth chasing immediately. It just cannot tell you whether the mechanism was worth building. Treat the proxies as an early-warning system and the outcome as the verdict, and both keep their proper size.
The artifact was delivered. Whether anything actually changed was somebody else's problem, and nobody was ever named.
Why organizations avoid this
Committing to an outcome means accepting accountability for something you do not fully control, and that is a genuinely difficult position rather than a failure of nerve.
The operation contains people who will make their own decisions, priorities that shift, and conditions nobody predicted. An artifact can be delivered regardless. An outcome depends on the organization doing things too, which means the commitment has to be joint, and joint commitments are harder to write down and harder to enforce.
The workable version of a joint commitment is narrower than it sounds. It does not require the client to guarantee a result. It requires naming, in advance, the specific things only the client can do: the decision that has to be delegated, the process that has to be retired, the person who has to be available. Written down at the start, those read as ordinary dependencies. Discovered at the end, they read as excuses, which is why the writing down is the whole of the technique.
The honest version is not that outcomes are easy to promise. It is that the alternative quietly transfers all the risk to the party least equipped to carry it, which is the operation itself, and then calls the transfer a successful delivery.
Writing one down
An outcome that cannot be written in a sentence is not yet an outcome. The sentence has a recognizable shape: a named operating measure, its current value, the value it should reach, and the date by which the change has to still be true.
Most attempts fail at the current value, and the failure is informative. If nobody can say what the number is today, then either the operation is not instrumented for the thing everyone says is the problem, or the thing everyone says is the problem is a proxy for something nobody has named. Both are worth discovering in week one rather than at the end, and both are more useful findings than the scope document that would otherwise have been produced.
The date matters as much as the number and gets less attention. "Within three months of launch" measures the project. "Still true two quarters after the team leaves" measures the system. The second is the only one that answers the question the organization was actually asking, and it is the one that almost never appears in a statement of work, because it commits somebody to being wrong in public later.
The consequences
Taking the outcome as the unit changes how the work is run more than it changes how it is described.
Scoping starts from the operating number rather than from a feature list. The end of the work moves from launch to the point at which the change holds without supervision. And the definition of finished stops being a question about the system and becomes a question about the organization, which is where it belonged.
It also changes what gets refused. If the unit is the outcome, then a request to build something that will not move the named number has to be declined or renegotiated, even when the client is willing to pay for it and the team is capable of delivering it. Under an artifact model that request is simply revenue. That is the real cost of the position, and it is the reason the model is adopted less often than it is endorsed.
If this describes an operation you are responsible for, the diagnostic is where that conversation starts.
How engagements begin
