Built is not finished
Look around your business and count the things that got built and then quietly stopped being used. The whiteboard that became decoration. The automation somebody switched off. The hire nobody actually lets decide anything. None of those were bad builds. They just never reached done, and nobody noticed, because built felt like done.
Four states, and one vocabulary for everything you build. Every deliverable, whether it is a piece of software, a written procedure, or a person being trained into a role, moves through the same four. Anything short of the last one is unfinished, however good it looks.
The same four states, on three different things
Seeing a person in the same grid as a piece of software looks strange for about ten seconds, and then it is the most useful column on the page.
| State | A system | A process | A person |
|---|---|---|---|
| Built | It exists and it runs | It is written down | They have been trained |
| In use | Used in a real week without you in the room | Followed when nobody is watching | Doing the job unsupervised |
| Documented | Someone else could pick it up | The SOP is the documentation | A curriculum and a standard exist |
| Owned | One named person keeps it alive | One named person keeps it current | They own the outcome, not the task |
A system nobody uses, a procedure nobody follows, and a person nobody lets decide are the same failure. Recognising that is the whole reason for having one vocabulary instead of three.
The common failure is not building. It is adoption.
Things get built and then quietly abandoned. A whiteboard gets mounted and becomes decoration. An automation gets switched off and the work goes back to being done by hand. A tool gets bought and ends up used as a list. In every case the build was fine and nothing was wrong with the work. It simply never reached in use, and nobody noticed, because built felt like finished.
So construction capacity is rarely your constraint. Adoption capacity is. Which means the build queue should be ordered by who can absorb the thing, not by what is most valuable to build.
How to actually run it
Put the state on the thing
Every procedure, every module, every tracked system carries a status line with one of the four words and a named owner. If it is not written on the thing, nobody is tracking it.
Be honest about it
Most things sit at built for a long time. Say so. A false owned is worse than an accurate built, because it stops anyone ever looking at it again.
Owner is a name
Not a role with nobody in it, and not eventually. If you cannot write a person's name, the honest status is not owned.
Every build ships with the thing that measures its own use
A tracker, a scorecard, a log line. Without one you cannot tell in use from built, and you find out in month six that four things are decorations.
Two questions, in the review you already run
- 01What moved a state this period, and what did not?
- 02What has been sitting at built long enough that we should either finish it or archive it?
Neither one needs a new meeting. They belong in the review that already happens, which is the only reason they survive.
Most of what I do is getting things to owned
Building is the easy half. Getting a system into real use, documented, and handed to a named owner is the half that decides whether anything survives. The strategy call is free and you keep the plan either way.