The demand-stage gap: why enterprise projects fail before they start

When an enterprise project fails, the inquest almost always looks at delivery. The timeline slipped, the budget overran, the scope changed, the vendor underperformed. All of that may be true. But in my experience running transformation programmes, a large share of those failures were decided long before a single line of code was written — at the demand stage, when a vague request was accepted as if it were a clear one. Enterprise projects don’t fail only in delivery. They often fail because they start with unclear requests and weak requirements.

Accountability starts before the project does

Here is the pattern I have watched repeat across organisations and sectors. A request arrives — a sentence, maybe two. It is ambiguous, but it comes from somewhere important, so it is accepted and given a name. From that moment, accountability has quietly begun, even though nobody has agreed what success looks like. The PMO starts chasing context. Business analysts run follow-up after follow-up to reconstruct what the requester actually meant. IT is asked to estimate something that has not been defined. Every one of these people is now accountable for a problem that should have been surfaced and resolved at the very start.

By the time the ambiguity becomes visible — usually in delivery, when reality collides with the unstated assumptions — it is expensive to fix and politically awkward to admit. The people held responsible are rarely the ones who accepted the unclear request. They are the ones downstream who inherited it.

Why the gap persists

If the demand stage matters this much, why do capable organisations keep under-investing in it? Because it is nobody’s job in particular and everybody’s problem in general. Delivery methodologies are mature and well-tooled. Portfolio management tools track initiatives once they exist. Requirements platforms manage requirements once they are written. But the messy, human work of turning an idea into a well-formed request — clarifying the need, finding the right stakeholders, weighing whether it is even worth doing — falls between these tools. It happens in meetings and inboxes, it depends on whoever is diligent enough to chase it, and it leaves almost no reusable trail.

The result is that demand quality is wildly inconsistent. Two requests of similar strategic importance can enter the pipeline with completely different levels of rigour, purely because one landed on a more thorough desk than the other. That inconsistency is not a minor annoyance. It is the root cause of the surprises that show up months later as delivery failures.

Control without becoming the bottleneck

The instinctive fix — more governance, more forms, more gate meetings — usually makes things worse. Heavy process at the demand stage turns the PMO into a bottleneck, and organisations route around bottlenecks. What is needed instead is earlier control that does not slow good requests down: a consistent way to see what is entering the pipeline, whether it is ready, and where it is weak, applied to every request rather than only the ones that happen to get attention.

That is the shift I care about most. Give the people accountable for project decisions a consistent basis to challenge a weak case with evidence, to surface missing decisions and dependencies early, and to compare initiatives on the same terms — and you gain control of the pipeline without becoming the person every request has to wait behind. The goal is not to add a checkpoint. It is to raise the floor on demand quality so that fewer bad starts ever reach delivery.

Where the discipline pays off

Organisations that take the demand stage seriously do not eliminate project failure — nothing does. But they change where and when problems surface. Weak cases get challenged before they consume delivery capacity. Assumptions get tested while they are still cheap to test. Stakeholders who would otherwise have appeared late, with objections, are brought in while their input can still shape the request. The work moves faster overall precisely because less of it has to be redone.

My argument is simple, and I have seen it hold across enough programmes to be confident in it: the single highest-leverage place to improve enterprise delivery is not delivery. It is the demand stage that everyone treats as pre-work. Fix the start, and a surprising amount of what we call a delivery problem never happens at all.