Why your delivery team is not slow, your decisions are

Most delivery teams are not slow because execution is slow. They are slow because decisions are slow. Work waits for an owner. It waits for a trade-off nobody has been willing to name out loud. It waits for an approval sitting in someone’s inbox. It waits for a risk acceptance nobody wants their name against. It waits for an escalation someone is reluctant to make because raising it feels like admitting the plan is in trouble.

Then leadership looks at a throughput number and asks why the team is not moving faster. The team is moving. The decisions the team is waiting on are not.

Delivery flow metrics tell you how fast work moves once it has everything it needs. They tell you almost nothing about how long work sat waiting before that point, which is usually where the real time is lost. The fix is not another velocity chart. It is tracking decision latency as its own metric, next to delivery flow, not buried inside it.

For every stalled item, track when the decision was actually raised, not when it was first mentioned in passing. Track who owns it, by name, not by team. Track what evidence is missing that is preventing the decision from being made. And track what the delay is actually costing, in the same terms leadership already uses for everything else: time, money, or risk exposure. A decision with no named owner and no visible cost of delay will sit indefinitely, because nothing is forcing it to move.

Part of why decisions stall in plain sight is that the artefacts meant to force them stop doing their job. A risk register that does not change a single decision is admin, not risk management. A stakeholder map that does not shape how you actually engage anyone is decoration. A business case that nobody revisits once it is approved is theatre, wheeled out once and never checked against reality again. A status report that hides the trade-off underneath a green status is comfort reporting, not communication.

Templates are useful for structuring thinking. They become dangerous the moment a team mistakes filling one in for actually making the decision it was designed to prompt. The strongest PMs use frameworks to force a decision into the open. They do not use them as a substitute for having the decision at all.

Decisions rarely die from a single dramatic failure. They die quietly in three places. In the recurring meeting that reviews the same open item for the fourth week running without anyone naming why it has not moved. In the inbox of a sponsor who has too many competing asks and no visible cost attached to leaving this one unanswered. And in the space between two people who each assume the other has the authority to decide, so neither one does.

Finding which of the three is actually happening on your programme is more useful than adding another status meeting to the calendar, because more meetings do not fix an ownership gap, an invisible cost, or an authority assumption. They just add another place for the same stalled decision to be discussed again without moving.

Pick the three work items that have been stalled longest on your current programme and run each through this.

Age. How long has this decision actually been open, counted from when it was first genuinely raised, not from when it started feeling urgent?

Owner. Is there a named individual accountable for making this call, or does it currently belong to the team or the business, which in practice means nobody?

Missing evidence. What specific information is this decision waiting on, and who is responsible for producing it?

Cost of delay. What is this delay actually costing, expressed in time, money, or risk, in language a sponsor would recognise as a reason to act?

Run the audit above against your three oldest stalled decisions this week, and bring the cost-of-delay answer, not the status update, to whoever can actually unblock them. A throughput problem framed as a delivery-speed issue gets a delivery-speed fix that will not work. The same problem framed as a decision-latency issue, with a named owner and a visible cost attached, tends to move within days.