Why delivery commitments slip before a single line of code

Every engineering manager has been in the meeting where a date is missed and the conversation immediately becomes archaeological. Which sprint did it go wrong? Who was blocked? Should we have caught it at the mid-point review?

The questions are reasonable and the answers are almost always useless, because the thing that went wrong usually happened before any of the events being examined. It happened at the moment a request turned into a commitment.

A request and a commitment are different objects

A request is someone wanting something. It arrives as a Slack message, an email, a line in a steering deck, a sentence at the end of a meeting. It has a requester and a desire and usually nothing else.

A commitment is a promise made on behalf of other people's time. To make one honestly you need six things that a request does not contain:

• The problem — what is actually wrong, as distinct from the solution someone already has in mind.
• The outcome — what will be different, stated so that you could later tell whether it happened.
• An owner — one named person accountable for the decision, not a team name.
• Capacity — a defensible size, and confirmation that the teams involved have it.
• Dependencies — what has to come from somewhere else, and whether that somewhere else knows.
• The open questions — the things that are genuinely not known yet, written down as unknowns rather than quietly assumed.

In most organisations there is no step between the two objects. The request is discussed, it sounds reasonable, and it becomes a commitment by social momentum. Nobody decided to skip the six things. There was simply no place where skipping them would have been visible.

The slip is a lagging indicator of the intake

Here is the pattern, and it repeats with unnerving consistency:

• A demand is committed with the problem still stated as a solution. Three weeks in, the team discovers the solution does not address the problem, and the scope changes. That reads as scope creep. It was an unshaped problem.
• A demand is committed without confirming a cross-cutting dependency — a security review, a legal sign-off, a shared platform change. It surfaces at 80% complete because that is when the gate is reached. That reads as a late blocker. It was a dependency nobody had asked about.
• A demand is committed with a capacity number that one person estimated and nobody on the delivering team ever agreed to. It slips by exactly the difference between those two figures. That reads as underestimation. It was an unconfirmed commitment.

In all three cases the delivery process worked fine. It faithfully delivered the consequences of a decision that was made without evidence.

Why more tracking does not fix it

The instinct after a bad quarter is to add visibility to delivery: more granular tickets, more frequent status, a RAG that updates weekly instead of monthly. This helps you find out sooner. It does not change the outcome, because by the time delivery starts the commitment is already made and the missing evidence is already missing.

You cannot inspect quality into a decision after the fact. The leverage is almost entirely upstream, and it is boring: make the six things explicit before the promise, and make it visible when they are absent.

What a shaping step actually has to do

The step between request and commitment does not need to be heavy. It needs to do three things well.

Separate what is known from what is assumed. Most demands arrive as a mixture, and the mixture is the danger — an assumption written in the same tone as a fact will be treated as a fact by everyone downstream. The useful artifact is a short brief that lists known facts, stated assumptions, and the open questions that would change the answer if they resolved badly.

Make "we don't know yet" a legitimate answer. If your process only accepts filled-in fields, people fill them in. You get invented dependencies and fictional risk registers, which are worse than blank ones because they look like diligence. An honest system needs an explicit no known dependencies that is different from not assessed, and different again from a list.

Make an early commitment possible but expensive. Sometimes you genuinely have to commit before you are ready — a regulatory date, a customer escalation, a board promise. The answer is not to forbid it. The answer is to require that someone records why it is early, what is still missing, who is accepting the risk, and what condition would change the decision. Four fields. It takes a minute, and it converts an invisible gamble into a decision with a name on it.

The part that is uncomfortable

Doing this properly means some demands will visibly fail to become commitments. A request will sit in a state that says, in effect, "this is not ready and here is precisely what is missing". That is politically harder than a vague yes, which is exactly why organisations drift toward the vague yes.

But the vague yes does not remove the problem, it defers it to a quarter where it costs more and someone else's plan is attached to it. The only real choice is whether you find out in the week the request arrives or the week before the date.

How DeliverySheet does it

This is the product I build, so treat this section as what it is. DeliverySheet puts one line between intake and delivery — Capture → Shape → Decide → Plan → Commit → Deliver → Learn — and a demand only walks the stages it needs. Small things take the short path; a real initiative takes the long one.

Capture takes raw pasted text and asks for the minimum that makes a request shapeable at all. Shape produces the clarification brief: known facts, assumptions, open questions, contradictions. Plan holds dependencies, decisions, capacity and risks, each of which can honestly be marked none known. Commit refuses to record a commitment on an unready demand unless someone fills in all four exception fields. Deliver records what actually happened, and Learn requires an actual lesson — a thumbs-up alone does not close a demand.

What it deliberately does not do: track anyone's hours, score anyone's throughput, or replace Jira or Linear for day-to-day execution. It owns the decision, not the ticket queue.