A Deal Is Not A Deliverable

When a project stalls three weeks before a promised go-live, the instinct is to ask who is blocking it. The more useful question is who was ever meant to unblock it, because in a lot of the stalls I see, the honest answer is nobody. A contract was signed, a start date was announced, and the assumption that requirements would simply materialise somewhere between sales and delivery turned out to be the actual plan. It rarely survives contact with a calendar.

I sat in a delivery review recently where exactly this played out. A quarter was nearly over, a board of work needed tidying before the close, and one item produced a real disagreement: should it be marked blocked. On one side, the case was straightforward — there was a purchase order, the project had a go-live date roughly three weeks out, and marking it blocked felt like an insult to a deal that was very much alive. On the other side, the case was just as straightforward — there was nothing in the tracking system beyond a placeholder ticket, no requirements, no acceptance criteria, and therefore nothing an engineer could actually pick up and build. Both people were completely right, and that is exactly why the argument couldn't resolve itself. They were answering two different questions with the same word.

"Blocked" as a commercial status means the deal is stuck: no purchase order, no scope, no relationship. None of that was true here. "Blocked" as an engineering status means there is no instruction precise enough to act on. That was entirely true here. The status field on the board only has room for one answer, so the two meanings collide, and whoever loses the argument walks away feeling like the label was used against them. Nobody was lying. The tool just couldn't hold both truths at once, and the people using it hadn't agreed on which one it was supposed to represent.

Underneath the semantic fight was the actual problem, and it's a more common one than the specifics suggest: a proposal document is not a specification, and a purchase order is not an acceptance criterion. The work in question was framed as low-risk because it extended interfaces that already existed for an existing customer, similar to a change made not long before. That similarity was doing a lot of unearned work. The previous change had exposed hard-coded values that only broke because a supposedly minor extension turned out to touch assumptions nobody had written down. "Copy this and change a few things" is not a requirement, it's a hope, and hope doesn't survive the first edge case an engineer actually has to make a decision about — what happens with a department code that doesn't fit the existing pattern, what the acceptance criteria for the new billing path actually are, whether a system that isn't obviously part of the deal should be included or deliberately excluded. Every one of those needs someone to decide and write it down, and in this case nobody currently held that job. The people who could authorise the deal were not the people who could specify the build, and no one had been assigned to stand in the gap between them.

That gap is where a surprising amount of delivery risk actually lives, and it's easy to miss because it doesn't look like a technical problem. Everyone can point to the purchase order. Everyone can point to the empty ticket. Nobody can point to the moment where the first should have turned into the second, because there was never a named owner for that moment. Compare it to an adjacent piece of work on the same board, where the business itself hadn't been raising the stories a technical integration needed, and the team just quietly absorbed the job of writing them, because a technical integration without a business-facing owner is at least a problem engineers can solve on their own terms. The commercial extension work was the opposite case — a business relationship engineers had no authority to interpret, sitting untranslated because everyone assumed it was someone else's next step.

The fix that got agreed on on the day was almost anticlimactic: mark it blocked for now, note explicitly that this changes nothing about the commitment or the date, and unblock it the moment real stories exist. That sounds like a paperwork compromise, but it did something more important than resolve an argument about a label. It separated the two questions cleanly. Is the deal alive — yes, untouched, moving forward. Can anyone build against it today — no, and that "no" needs a name attached before it becomes a "yes." Once you stop asking a single status field to answer both questions, the actual gap becomes visible instead of being argued over.

The revenue consequence was named plainly in the room, which is worth pausing on, because it's usually left implicit. Missing the go-live date didn't just mean an awkward conversation with a customer — it meant a payment milestone slipping, on a deal where the payment was tied to delivery, not to intent. That's the part that made the disagreement worth having properly rather than smoothing over. When a status label is treated as a minor administrative choice, it's easy to leave the real gap unresolved for another sprint, because nothing visibly breaks until the date arrives. Naming the cost up front — this specific slip costs this specific milestone — is what got the conversation from "who's right about the label" to "who is going to own writing the first story by tomorrow."

I've come to think the useful discipline here isn't really about ticket hygiene at all, even though that's how it always shows up on a board. It's about recognising that the ability to sell something and the ability to specify it are different skills, held by different people, and a deal moving quickly is not evidence that both have happened. The commercial side can move at the speed of a signature. The specification side moves at the speed of someone sitting down, thinking through the edge cases, and being willing to be wrong about a detail in front of the people who'll build it. Those two speeds are never naturally in sync, and pretending otherwise is how a project with every reason to succeed ends up three weeks from a go-live date with an empty ticket and a room full of people arguing about what "blocked" means.

The practical habit worth taking from it is small: whenever a deal, an announcement, or a go-live date gets set, ask in the same breath who is responsible for turning it into something a builder can act on. Not eventually — now, with a name next to it. If nobody can answer that question, you don't have a blocked project yet. You have a project that's about to become one, and you still have time to do something about it while that's still true.