You will commit before you are ready. Make it cost four fields.
· 6 min read · by Tan Gravam
The short answer
Do not forbid committing to work that is not ready — organisations have real deadlines and the ban simply moves the decision somewhere unrecorded. Require instead that an early commitment names four things: why it is being made early, what is still unknown, who is accepting the risk, and what condition would change the decision. That is a minute of work, it makes the exception countable, and at quarter end you can see whether your misses came from early commitments or from something else.
Every process that tries to enforce readiness eventually meets a date that does not care. A regulator's deadline. A contract. A customer escalation that has reached someone with the authority to end the conversation. The demand is not ready and the answer is going to be yes anyway.
What happens next determines whether your process is real or decorative.
The two failure modes
The strict process. Readiness is mandatory, no exceptions. What actually happens is that the demand gets marked ready by someone who ticks the boxes at 6pm the day before the steering meeting. The checklist is satisfied and nothing was checked. Worse, the process now certifies the demand as ready, so downstream nobody treats it with the caution it deserves. You have converted a known gamble into an unknown one.
The soft process. Readiness is advisory. Commit anyway, everyone understands it is a bit early. Nothing is recorded, because nothing needs to be. At quarter end four demands have slipped and the conversation is entirely narrative — someone remembers that two of them were rushed, someone else disagrees. There is no data because none was captured, so the same argument happens next quarter.
Both fail in the same way: the fact that a commitment was made without evidence is not written down anywhere.
The third option: allowed, recorded, countable
Let people commit early. Require that the exception carries four fields, all of them mandatory:
- Why now. What forces this date. Not "business priority" — the specific external fact.
- What is missing. Which readiness dimensions are unresolved. Named, not summarised.
- Who accepts. One person, by name, who is accepting the risk on behalf of the organisation.
- What would change the decision. The condition under which this commitment gets revisited.
That is perhaps sixty seconds of typing. It is not a governance ritual and it should not become one — the moment it needs an approval workflow it will be routed around.
Why these four and not others
Each one does a specific job, and dropping any of them collapses the exercise.
Why now forces the pressure to be named. A surprising share of "hard deadlines" turn out to be someone's preference once written in a sentence that another person will read. The field is doing useful work even when nothing changes, because the answer is now on the record next to the outcome.
What is missing is the one people most want to skip and the one that pays off first. A commitment where the gap is "we have not confirmed capacity with the platform team" is a different animal from one where the gap is "we have not decided the pricing model". The first has a phone call as its remedy. Written down, the gap frequently gets closed within a week — nobody would have chased it if it were only a vague sense of unreadiness.
Who accepts is the field that makes the whole thing real. Risk accepted by "the leadership team" is risk accepted by nobody. This is not about blame afterwards; it is that a named person behaves differently at the moment of naming. Some exceptions do not survive the request for a name, which is the system working.
What would change the decision converts a one-off gamble into something with a review trigger. "If the vendor has not confirmed by the 15th we re-scope." Without it, an early commitment is simply carried until it fails.
The payoff is at quarter end
During the quarter this feels like a minor bookkeeping step. Its value shows up in the retrospective, when you can ask a question that is normally unanswerable: of the commitments we missed, how many were flagged as early at the time?
Both answers are useful and they point in opposite directions.
If most misses were early commitments, your delivery capability is fine and your decision discipline is not. The fix is upstream and organisational — usually about who is allowed to create a hard date, and how late a request can arrive.
If most misses were demands everybody agreed were ready, the readiness bar itself is wrong. Something you consider sufficient evidence is not. That is a much more interesting problem, and you cannot even see it without the exception data separating the two populations.
A second-order benefit: the count itself is a governance signal. Two exceptions a quarter is a functioning organisation absorbing genuine shocks. Fifteen is not an exception process, it is the actual process, and someone should say so out loud with a number rather than a feeling.
How DeliverySheet enforces it
Committing a demand that is not ready requires the exception, and all four fields are required — the rule is a single predicate on the server, so the client cannot talk its way past it and a direct API call cannot either. The requirement scales with the path: a standard or initiative demand always needs it when unready, an urgent one needs it too, and a genuinely quick demand uses a lighter confirmation instead of the full commitment form. A demand still in discovery cannot be committed at all — the loop goes back to the decision.
Exceptions then surface as their own report — Early commitments — because a governance record nobody can list is not a governance record. That report is where the quarter-end question above actually gets answered.
None of this stops anyone from committing early. It was never supposed to. It stops them from doing it invisibly.
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 writing
- Separate the facts from the assumptions before you plan anything
Requests arrive as a blend of what is known, what is assumed and what nobody has checked. Written in one voice, the assumptions get treated as facts.
- AI should draft and challenge. It should not decide.
Where an LLM genuinely helps in delivery planning, where it must not be trusted, and the design rule that keeps the two apart.
- 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.