The Outcome Is the Unit of Delivery
Most delivery is measured in artifacts because artifacts are countable. The more interesting question is what an organization is actually buying, and whether anyone's accountable for it.
What gets counted instead
Ask what a piece of work delivered and you'll 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 how they became the currency, and they share a property worth noticing. 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 wasn't present, at a fixed moment, without judgment, and that property is what lets a contract close, an invoice clear, and a status report be believed by a reader three levels away from the work. Outcomes have none of it, since they arrive late, get contested, and need 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's a stretch of work that most delivery structures leave unassigned.
Somebody has to make the new path the path of least resistance, and somebody has to notice that a third of cases don't fit and decide what happens to them. The first exception needs someone present too, because that's when the organization decides, informally and permanently, whether the new system is to be trusted.
In the work I've done, that stretch is where most of the effort actually went, and it was almost never in the plan.
The trust decision in particular deserves a closer look, 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 what it's really judging is what happened when the system didn't 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 later improvement to the system wins that ground back. The moment is entirely predictable and it's almost never staffed.
You won't find any of it in a scope document, even though it's real work that decides whether anything changed, and in most engagements it belongs to nobody. The artifact was the deliverable, the artifact was delivered, and the gap gets 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. The first is that the change shows up in the operation itself, which is the difference between reporting getting faster and decisions getting made earlier because the reporting arrived in time. The outcome also has to be named before the work starts, since choosing the metric at the end, from whatever happened to move, 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 was measuring the project.
The third constraint is what separates a real change from an expensive Hawthorne effect, and it's the one most often skipped, because it means 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 that second measurement into the arrangement at the start, while everyone's optimistic, is far easier than asking for it later, once the result has become someone's reputation.
Which brings us to 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're available early, unambiguous and within the delivery team's control, which makes them comfortable in a way real outcomes never are. High adoption of a system that automates a step which shouldn't exist is a well executed failure, and it'll look excellent in every report.
The test for a proxy is whether it could be fully satisfied while the thing you actually wanted didn't happen. Most of them fail that test immediately, and that's fine as long as they're treated as instrumentation and kept out of the objectives.
The distinction is practical. Instrumentation tells you whether the mechanism is behaving, so low adoption is a genuine signal that something's wrong and worth chasing right away, but it can't 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, and whether anything actually changed was left to somebody who was never named.
Why organizations avoid this
Committing to an outcome means accepting accountability for something you don't fully control, and that's a genuinely difficult position to be in, however much nerve you have.
The operation contains people who make their own decisions, priorities that shift, and conditions nobody predicted. An artifact can be delivered regardless of all that, while an outcome depends on the organization doing things too, so 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, and a good deal more modest than a guaranteed result, since it asks for the specific things only the client can do to be named in advance: 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.
Outcomes are hard to promise, honestly, and 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 can't be written in a sentence isn't an outcome yet. 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 still has to be true.
Most attempts fail at the current value, and the failure tells you something. If nobody can say what the number is today, then either the operation isn't 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. Either is worth discovering in week one, and either is a more useful finding 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, while "still true two quarters after the team leaves" measures the system, and only the second answers the question the organization was actually asking. You'll almost never see it 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's described.
Scoping starts from the operating number. The end of the work moves from launch to the point where the change holds without supervision, and the definition of finished turns into a question about the organization, which is where it belonged all along.
It also changes what gets refused. If the unit is the outcome, then a request to build something that won't 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 the same request is simply revenue. The difference is the real cost of the position, and the reason the model gets adopted less often than it gets endorsed.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
