Topic
Planning that stays honest
The short answer
An honest plan does three things. It separates known facts from assumptions from open questions, because a request written in one confident voice makes an assumption indistinguishable from a fact and every downstream estimate then inherits it. It models vertical delivery streams and horizontal cross-cutting concerns differently, because verticals consume capacity continuously while horizontals consume it in bursts and gate other teams' progress. And it lets assessed-and-nothing-found be a first-class answer, distinct from not-assessed, because otherwise people invent dependencies and risks to look diligent, and invented entries are worse than blanks.
A plan is a set of claims about a future nobody has seen. It stays useful for exactly as long as it keeps being honest about which of those claims are established, which are believed, and which are guesses wearing the same typeface.
Separate what is known from what is assumed
Requests arrive as a blend of fact, assumption and open question, written in one confident voice. The damage is done by the formatting: an assumption written in the same tone as a fact is treated as a fact by every subsequent reader, and the estimate, the commitment and the quarter plan all inherit it without anyone consciously deciding to accept it. Split the three, name the evidence behind anything you called a fact, and the list of assumptions turns out to be a better risk register than the one you would have written from a blank field.
Model cross-cutting work as what it is
Vertical work is a delivery stream owned by one team, consuming capacity continuously in its own lane. Horizontal work — security, legal, compliance, design, accessibility, privacy — pulses into several verticals at gates, is driven by other people's schedules, and gates their progress. Planning both with the same object, usually called an epic, is why the most predictable bottleneck in delivery keeps arriving as a surprise: four lanes reach the same gate in the same fortnight, and the two-person group behind it had no way to see it coming.
Let "nothing found" be an answer
A planning dimension needs three states, not two: not assessed, assessed and nothing found, assessed with items. Collapse the middle one into "empty" and an honest blank becomes indistinguishable from a skipped step — so people invent dependencies and risks to look diligent. Invented entries are worse than blanks: they consume the scarcest resource in the process, which is review attention, and they make the register look trustworthy when it is not.
And keep AI on the reversible side
The dividing line is not model capability, it is accountability. Use AI where the output is verifiable in seconds and a wrong answer costs one edit — turning prose into a structured draft, listing what a plan has not answered, challenging a too-clean "no known risks". Keep it away from anything carrying an organisational commitment: what gets committed, who owns it, how much capacity it takes, whether something is ready.
The full argument
Separating fact from assumption, modelling cross-cutting work, and knowing where AI belongs.
- A decision without a record is a decision you will make again
Teams re-litigate the same architectural and scoping calls every few months, because what was recorded was the outcome and never the reasoning or the conditions.
- The dependency you don't own
Most delivery risk sits in work another team has to do for you — and the usual tracking treats it exactly like work you control.
- 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.
- "No known risks" has to be a valid answer
Planning templates that only accept filled-in fields get filled in. The result is a risk register full of fiction, which is worse than an empty one.
- Vertical and horizontal work: the distinction planning tools miss
Delivery streams and cross-cutting concerns behave differently, need different capacity models, and fail differently. Most tools call both an "epic".
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.