Naming what done means
Before anything is built, the practice and the customer agree on a plain statement of what should be true when the work is finished. That statement shapes the scope, the build, and the handoff.
· 4 min read
IN SHORT
Naming what done means is the first step of every E31 Consulting engagement. The customer and the engineers write a plain statement of what should be true when the work is finished: a desk that drafts and waits, a corpus people can question, a product that ships under the customer's name. Everything after, from scope to handoff, is measured against it.
The most useful sentence in an engagement is usually the shortest one. It says what should be true when the work is finished, in words the person who owns the work would use. The practice calls this naming what done means, and it comes before any version is built.
It sounds obvious. In practice it is skipped more often than not, and the cost shows up at the end, when a working system is delivered and nobody can agree whether the work is finished.
What a statement of done looks like
A good statement is an outcome, not a feature. Three shapes come up again and again.
A desk that drafts and waits. The use case reads what arrives, prepares the response or the action, and stops for a named person to approve before anything lands. Done means that person is reviewing drafts instead of writing them.
A corpus people can question. The site's documents, manuals, procedures, and records are indexed on the appliance, and anyone with the right role can ask a question and get an answer that cites the source. Done means the floor stops walking to the one person who knows where the document is.
A product that ships under the customer's name. The customer's own customers run something built on Czar Chassis, and it carries the customer's brand and the customer's terms. Done means the product is in the hands of the people it was built for.
Each of these can be read aloud by the person who owns the outcome. None of them mentions a model, a route, or an adapter.
Finding the packet inside the statement
Underneath every statement of done is a packet, and the engineers' first job is to find it. What arrives: a message, a document, a ticket, a sensor reading, a customer's request. What a good result looks like: the form of the response, the fields it fills, the tone it takes, the thing it never does. Which step a person still has to take: the approval, the signature, the physical action that stays human. Which system it has to land in: the ticketing system, the records system, the warehouse system, the planning system.
When the packet is clear, the scope almost writes itself. The material the use case may read is whatever it needs to produce a good result. The calls it may make are the routes to the systems it must land in. The role that approves is the person who still has to act. The systems of record are where done becomes visible.
When the packet is not clear, the statement of done is not finished either. That is useful to know early.
Done as the measure at handoff
The statement of done is not filed away once the scope is written. It is the thing the engagement is measured against at the end.
For a forward-deployed engagement, the test is two-part: the statement is true, and the site team can publish the next version themselves. Both have to hold. A desk that drafts and waits is not done if only the engineers know how to change the draft.
For a project, the version that comes back is checked against the statement and the scope. The customer runs it, confirms the outcome holds, and receives the notes that let their operators change it.
In both forms, the record of how the version behaved during build is part of the evidence. It shows the use case doing what the statement says, with the approvals the scope names.
Revising the statement
Statements of done change. A forward-deployed team that sits with a desk for a while often finds that the real packet is different from the one described at the start. The exception path matters more than the main path. The system the result was supposed to land in is not the one the operators actually use. When that happens, the statement is revised with the owner, and the scope follows.
In a project, the statement is held fixed because it is the contract. If the customer learns partway through that done should mean something else, that is the start of a second version, not a change to the first. When a project needs a second version covers how that works.
Writing one before you start
Customers who arrive with a draft statement of done have an easier start. The draft does not have to be polished. It has to name the desk, say what a good result looks like, name the person who still has to act, and name the system where the result lands. The engagements page at /engagements describes how the practice takes it from there.
Questions this raises
- What if we cannot describe what done means yet?
- That is a signal toward a forward-deployed engagement. Engineers sit with the desk and help write the statement from what they learn. A project needs the statement at the start; forward-deployed work can discover it.
- Can done include a measurable target?
- It can include a condition the site can check, such as a role approving every outbound action or a result landing in a named system. The practice avoids promising figures in the statement, because the point is a running use case the team can maintain, not a number.
- Who writes the statement of done?
- The customer owns it and the engineers draft with them. The person who owns the outcome has to be able to read it aloud and agree it is what they want. If only the engineers understand it, it is not done yet.
KEEP READING