The Outcome You Have to Describe
If you cannot write down what finished looks like, you have nothing to accept against and nothing to reject against, and only standing over the work is left.
Reads as a businessReads as employmentCuts both waysDepends where you are
Four factors, and no total. Every bar is the same length: the side is the claim, the size is not. The distinction everything else in this collection rests on.
If you cannot write down what finished looks like, you have nothing to accept against and nothing to reject against. Everything else in this collection depends on a description that exists before the work does.
The practical issue in “The Outcome You Have to Describe” becomes clearer when expectations and evidence are visible to both sides. Used for step rate compensation, a structured way to review step rate compensation can add time and project context, provided the purpose is disclosed, access is limited and every consequential interpretation receives human review.
This is the single cheapest thing a buyer can do and the thing most reliably skipped, because writing it takes an afternoon and starting takes five minutes.
The workflow in “The Outcome You Have to Describe” can be cross-checked against Dubsado client-work articles. A useful review should end with named owners and written decisions instead of a copied checklist.
What a usable description contains
Four things, and none of them concern method:
The thing itself, named precisely enough that a stranger could identify it. The condition it must be in to count as done. The date. What it has to work with, run on, or fit into.
Anything beyond that is you specifying how, and specifying how has a cost that the rest of this collection is about.
The stranger test
Hand the description to somebody in the business who was not in the conversation. Ask them whether the work has been delivered.
If they can answer from the document alone, it is good enough. If they have to come back and ask you what you meant, it is not a specification, it is a reminder of a conversation, and a reminder of a conversation is worth nothing in six months when the person who had it has left.
Precision about the thing, vagueness about the route
"A report, by the fifteenth, covering the four regions, with the underlying figures attached in a form we can open" is precise about the result and silent about the route.
"A report, by the fifteenth, using the template in the shared drive, built from the extract you should pull on Monday, following the structure Priya used last quarter" is a method document. It may be exactly what you want. It is simply no longer a description of a result, and it has moved something.
What to do when the work genuinely cannot be described
Some work cannot. Investigation, early design, anything where the first answer is what the question should have been — these resist description by their nature.
The honest responses are to buy a small defined piece first and describe the next one afterwards, or to accept that what you want is somebody's attention for a period and to think seriously about whether this is the right arrangement for getting it. What does not work is describing nothing and then managing as though you had described something.
Agreeing it rather than sending it
A description you wrote and sent is a position. A description they read, queried and accepted is an agreement, and the queries are the valuable part.
A supplier who reads a specification properly will come back with two or three questions that reveal where you were vague. Those questions cost ten minutes now and save the argument later. A supplier who comes back with nothing has either understood everything or read nothing, and you do not yet know which.
Keeping it where it can be found
The description belongs somewhere both sides can reach, dated, with any agreed change recorded against it. Not in a message thread, not in one person's mail.
This sounds like administration. It is the difference between a disagreement that takes an email and a disagreement in which two people remember different conversations and neither can prove anything.
When it changes, and it will
Work changes. The question is whether the change is recorded as a change or absorbed silently.
Absorbed silently, it does two things at once: the supplier does unpriced work and becomes quietly resentful, and the original description stops matching reality, which means you have lost the thing you would have rejected against. Recorded, even in two lines, it costs a message and keeps both intact.
Why this is the foundation rather than the paperwork
Every instrument available to you later — refusing a deliverable, asking for it again, withholding payment, ending the engagement without argument — rests on a document saying what was supposed to happen.
Without it, you are left with the one instrument you do not have, which is telling somebody they are not doing their job properly and expecting that to change their behaviour. That instrument belongs to an employer. Buying it back costs more than an afternoon of writing.
The description that is too tight
The opposite failure exists and is less common. A specification that fixes every detail of the output removes the supplier's judgement, which was part of what you were buying, and it moves toward method without ever using the word.
A useful test: does the description constrain anything that you would not actually care about if it came back different? If so, that part of it is there because somebody was being thorough, and it is costing you both the supplier's thinking and a factor you did not mean to move.
Why the afternoon is worth it
The specification is not a formality that precedes the work. It is the entire set of management tools you will have once the work has begun.