Moving delivery governance out of the spreadsheet
· 6 min read · by Tan Gravam
The short answer
Move when the sheet's silent failures start costing real money: the first overwritten commitment, the first time two people edit the same row, the first leadership question — what did we promise and why? — the sheet cannot answer. The migration itself is small, because very little data actually moves: the list of live demands and each team's capacity is an afternoon of typing. What actually changes is states — a demand can now be not-ready, parked with a reason, refused on the record, or committed-with-an-exception, and none of those existed in the sheet. Keep the sheet for what sheets are for: ad-hoc analysis, one-off models, anything with one author and no lifecycle.
The intake-and-capacity spreadsheet is not a mistake. At the size where one person makes the commitments and the whole demand list fits on a screen, it is the correct tool, and anything heavier is process theatre. This essay is about the day that stops being true — how to recognise it, and what actually moves when you migrate.
The trigger is not row count
Sheets do not fail by getting long. They fail by getting shared. The real triggers are events, and you tend to remember each one: the first time two people edit the same commitment and one edit silently wins. The first time a number changes and nobody can say who changed it or what it was before. The first time leadership asks the question the sheet cannot answer — what did we promise this quarter, and what did we know when we promised it? The sheet shows the current cell values. The question is about history, and the history was overwritten by the answer.
If none of these has happened to you yet, close this tab and keep the sheet — genuinely. The comparison page says the same thing at more length.
Very little data moves. States move.
The migration looks bigger than it is, because the sheet looks bigger than it is. What actually transfers: the list of live demands — most sheets hold ten to forty that are real — and each team's capacity for the quarter. That is an afternoon of typing, and the act of typing it is itself a cleanup: half the rows turn out to be nos nobody recorded, and copying them forward would just move the rot.
What changes is not the data but what can be said about it. A row in a sheet has whatever status someone typed. A demand in a governance layer has states the sheet never had: understood but not ready; parked, with the reason kept; refused, likewise on the record; committed early, with a named acceptor; closed, with what shipped versus what was promised. None of these is a column you forgot to add. They are transitions with conditions on them, which is the thing a grid cannot hold.
The first two weeks
Do not migrate the process and the tool in the same week. Run intake first: new requests go through the door — what needs to change, who is affected — while the old sheet stays read-only as the archive. The first planning conversation on top of shaped demands will feel slower, because questions that used to surface in week six of delivery are surfacing before the commitment. That is the product working, and it is worth saying so out loud to the team, because until the first honest close the extra questions are all cost and no visible payoff.
What you genuinely give up
Free-form structure. The sheet let you add a column for anything, and one of your columns probably does something clever. A governance layer will not let you, on purpose — the fixed shape is what makes "ready to commit" mean the same thing in every workspace, and what keeps the record trustworthy when someone is motivated to bend it. If the clever column was really an analysis, keep it in a sheet; analysis is what sheets are for. What should not live there any more is the thing the column was wrapped around: the promise, its evidence, and its history.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$10/month per workspace during the launch period (normally $189), unlimited members, 7-day free trial. I answer the support email myself.
More on turning a request into a decision
Read the overview: Turning a request into something you can decide on →
- Saying no is a decision. Record it like one.
Most requests that never get built were never actually declined — they were left to rot in a backlog. That costs more than a clear no.
- What makes a request shapeable
Not every message is a demand. The floor is low but it is real: a need, plus either who it affects or what happens if nothing changes.
- Not every request should enter the process
A bar at intake is usually described as bureaucracy. One sentence wide, applied at the door, it is the cheapest quality control a delivery process has.