Decision Latency: Why Your Projects Wait Longer for a Yes Than They Spend Being Worked On

Somewhere in your portfolio is a project that is ready to move and is not moving, because it is waiting for someone to say yes. The work is done to the point of a gate. The paper is written, or half written. It sits on an agenda, or waits to be added to one, until a board that meets once a month can find a slot to look at it. Nobody is working on it and nothing is wrong with it. It is simply waiting for an answer.

We do not count that time. We count the days a project is worked, because someone is billing to it and the plan is advancing. We do not count the days it spends parked outside a decision, because no one is spending money and no line on the plan is moving. Yet in a great many portfolios the second number is larger than the first. The single most common thing a project does with its life is wait for a human being with authority to decide something, and the wait is almost never anyone's to manage. This piece is about that wait. I am going to call it decision latency: the time between a decision becoming ready to make and the decision actually being made, and the price a portfolio pays for letting it grow.

A project's calendar is mostly waiting, and much of the waiting is for a yes

Start from the fact underneath The Efficiency Paradox. If you measure the whole life of a typical project, from first work to done, and ask what fraction of that calendar was spent actually being worked on, the honest answer is usually a small one. Most of a project's life is wait, not work. The interesting question is what the waiting is for.

Some of it is queueing for a busy resource, the theme of finding your constraint. But a large and badly underestimated share is queueing for a decision: a go or no-go, a budget release, an architecture sign-off, an answer to a blocking question, a resolution of a scope disagreement, an approval to proceed to the next stage. The work is ready. What is missing is a yes. And the resource that supplies that yes, the steering committee, the investment board, the architecture forum, the one executive whose signature the whole thing hangs on, has all the properties of a constraint. It has finite capacity, it meets on a cadence, it has a fixed number of agenda slots, and it is loaded well past what it can clear. So decisions form a queue in front of it, exactly as work forms a queue in front of an overloaded engineer.

Once you see the decision-maker as a constrained resource, the whole apparatus of flow economics applies to it without modification. A queue in front of it has a length. That length, by Little's Law, sets the average wait. And the wait is not free time. It is drag cost, value delayed, accruing every day the answer does not come.

Why the wait is invisible, and therefore uncontrolled

Decision latency has the one quality that guarantees a cost will be ignored: it appears on no instrument anyone routinely watches.

It consumes no capacity, so it never shows up on a utilisation report, the trap examined in The Utilisation Trap. It is not attached to a task, so it does not appear on the plan as a bar with a length. The project manager cannot manage it, because the decision sits above them, outside their authority, in a forum they may not even attend. The decision-maker does not see it either, because from the chair each item is just one more paper in a full agenda, and the aggregate queue their limited cadence has created is not on the page in front of them. So the cost lands in the one place no one is looking: the gap between two boxes on a governance chart, where a project sits and ages and no one is accountable for the ageing.

And a paused-for-decision project is not merely sitting still cheaply. It is doing three expensive things at once. It is holding a slot in your work in progress, one of the fixed number of things your organisation can have in flight, and contributing nothing while it holds it. Its half-finished work is going stale, so that assumptions made before the wait must be checked and often redone after it, which is rework manufactured purely by delay. And the people assigned to it rarely wait idle; they drift onto other work to fill the gap, so a decision queue becomes a source of multitasking across projects, with all the switching cost that carries. The wait is not a neutral pause. It is a small engine of value destruction that runs the whole time the answer is outstanding.

A worked example

Put numbers on a single decision, illustrative rather than exact; the shape is what matters.

A project reaches its stage gate on the first of the month. To proceed it needs a go decision from the portfolio board, which meets monthly. Once live, the thing it delivers is worth about £8,000 a week in avoided cost of delay, so every week it does not proceed costs the organisation roughly that.

Here is what the calendar does to it. The board met two days ago, so the next meeting is nearly four weeks away. When that meeting comes, the agenda is full, the paper is one of fourteen items, and three items get deferred; ours is one of them. It is heard at the following meeting, four weeks after that. So the decision that was ready on the first of the month is made around seven weeks later. Seven weeks at £8,000 is roughly £56,000 of value delayed, on one decision, at one gate, for a project that was ready to move the entire time.

Now recall that a project of any size passes through several such gates, initiation, funding, design sign-off, a go-live approval, and that each has its own queue. If four gates each shed six or seven weeks to decision latency, the project loses something like half a year of calendar to waiting for answers, and on an £8,000-a-week benefit that is comfortably over £200,000 of drag, none of it spent doing anything, none of it visible on a single report. Against that, the actual hours of deliberation the board spent on our item might total ninety minutes. The cost was never the deciding. The cost was the queue in front of the deciding.

Compare a portfolio that treats decision-making as a resource to be run for flow. Routine go decisions under a threshold are delegated to a standing authority that clears them within days. The board meets weekly for thirty minutes on the genuinely large calls only, so the queue in front of it is short. Papers arrive complete or not at all, so nothing is deferred for want of information. The same decision that took seven weeks now takes three days. Multiply the saving across every gate and every project and you have recovered a portfolio's worth of calendar without touching a single delivery team. The decision latency was the cheapest large cost in the whole system to remove, and it was removed by changing a cadence and a delegation rule, not by working anyone harder.

Why single-project management is structurally blind to this

If the cost is this large, why does almost no organisation manage it? Because the frame it manages in has no place to put it.

Managed as a set of independent projects, each is tracked against its own schedule and its own spend. Wait-for-decision time is neither. It is not the project's work, so it is not on the project's plan, and it is not the board's work either, so it is not on the board's. It falls into the seam between them, and a single-project frame has no instrument that reads the seam. Worse, everyone inside the frame is behaving reasonably. The board is being thorough, seeking consensus, giving each paper due consideration, all of which are local virtues. The project team is getting on with other work rather than sitting idle, which is a local virtue too. Every actor optimises their own visible measure, and the aggregate latency that emerges from all those local optima is a cost that belongs to no one and appears to no one.

This is the Project Illusion in one of its quietest forms. A project can be delivered with every gate properly reviewed, every approval correctly minuted, every governance box ticked, and still bleed six figures of value into the gaps between those reviews, because the thing being optimised was the quality of each decision and never the latency of the queue that decisions wait in. The portfolio is not asking to make worse decisions. It is failing to notice that when a decision is made is as much an economic variable as what the decision is, and that a good answer delivered seven weeks late has, in cost-of-delay terms, already spent a large part of the value it was protecting.

What to do instead

The remedy is to treat your decision-making capacity as exactly what it is, a constrained resource with a queue, and to run it for flow. A few rules do most of the work.

1. Measure decision latency as a first-class number. For every gate, record the date the decision became ready and the date it was made. The gap is the metric. You cannot manage a cost you do not count, and this is the cost hiding in your longest projects. Once it is on a page, the queues in front of your slowest forums become impossible to unsee.

2. Find your decision constraint. In the same way you would find the resource that sets your delivery speed, find the forum or person the decisions are piling up in front of. It is usually a monthly board or a single overloaded executive. That queue, not any delivery team, may be the longest one in your portfolio, and it will never appear on a utilisation chart because deciding consumes almost no measurable time.

3. Raise decision throughput by delegating, not by deliberating faster. The board does not need to think quicker; it needs to handle fewer things. Push routine, below-threshold decisions to a standing authority with clear rules, so that only the genuinely large calls reach the scarce forum. This is subordination applied to governance, and it is one of the core jobs of a Value Management Office: to hold delegated decision rights so the portfolio does not queue behind a monthly meeting.

4. Shrink the batch. A monthly three-hour meeting is a large decision batch, and large batches mean long average waits, the same arithmetic as smaller projects. A weekly thirty-minute cadence clears the same decisions with a fraction of the queue. Meet more often for less, and the wait collapses even before you change who decides what.

5. Full-kit the decision. No decision should enter the queue until the paper that supports it is complete: the options, the cost of delay per week, the return on the remaining investment. A half-baked paper is not a fast decision, it is a deferred one, and a deferral is the single most expensive outcome a decision can have. Apply to decisions the same discipline you would apply to starting projects only when they can actually run: ready means ready to decide, not merely ready to discuss.

6. Price every pending decision. Attach a cost of delay per day to each item awaiting an answer, and show it on the agenda. A board that can see it is sitting on £8,000 a week will reorder itself, and the queue becomes self-prioritising in the way a portfolio ranked by its return on the constraint does. Nothing focuses a decision like a visible running meter beside it.

The objection you are already forming

"So you want us to make decisions faster. That is how you get reckless, rubber-stamped calls and expensive mistakes. Governance exists precisely to slow things down and think. Optimise for speed and you will approve the wrong projects quickly, which is worse than approving the right ones slowly."

This confuses two things that are, in fact, independent: how good a decision is, and how long it waited in a queue before anyone considered it. Look again at the worked example. Of the seven weeks that decision took, the deliberation was ninety minutes. The rest was pure queue, the item sitting untouched because the calendar had no slot and the agenda was full. Cutting that queue removes none of the thinking. It removes the waiting before the thinking, which added nothing but drag. You can halve decision latency without shortening a single conversation, simply by meeting more often and by not making large calls wait behind small ones.

And where the reforms touch the decision itself, they improve its quality, not degrade it. Delegation sends routine calls to people closer to the work and frees the scarce forum to give real attention to the few decisions that genuinely need it, rather than rushing fourteen items in three hours. Full-kit means every decision is made on complete information, options costed, delay priced, instead of half of them being punted for want of a number someone forgot to bring. The organisation making worse decisions is not the fast one. It is the one that let a paper that would have taken ninety minutes to approve sit in a queue for seven weeks, watched £56,000 of value drain away while nothing happened, and called the waiting "due diligence".

The instinct to equate slowness with care is one of the most expensive in portfolio governance. Care is what you spend in the meeting. Everything before the meeting is just queue, and queue is drag with a governance chart drawn around it. Before you defend your decision process on the grounds that it is thorough, measure how long your projects spend waiting to reach it. The thoroughness may be real. The waiting is almost certainly the larger number, and unlike the thoroughness, it is buying you nothing.

If this reframed how you read your own governance, the natural next steps are the two ideas it rests on: why most of a project's life is waiting rather than working, in The Efficiency Paradox, and what that waiting actually costs per day, in Drag Cost.