Most program delay is a queue of unmade decisions

Every recovery plan we get handed starts from the same assumption: the work is taking too long. So the plan adds people, compresses testing, runs workstreams in parallel, and moves go-live to the last defensible Friday of the quarter. Six weeks later the program sits roughly where it did, minus the contingency.

The assumption is usually wrong. On large programs the binding constraint is how long work waits for someone to answer a question. Nobody measures that wait, so nobody manages it, and it grows until it becomes the schedule.

What a decision queue looks like

Pick five items sitting in “in progress” on your board right now. Ask one question about each: is this waiting on effort, or on an answer? The split is rarely what the steering committee assumes.

Answers-in-waiting on a typical transformation program look like this:

• An integration pattern that needs architecture sign-off, which needs the security lead, who sits on three other programs.
• A data-residency question legal will not answer until commercial confirms which entity contracts with the customer.
• A scope change that is approved on paper but has no budget line, so it sits between the sponsor and finance.
• A vendor clarification raised eleven days ago, unanswered because the contract owner left and nobody reassigned the mailbox.

None of these are delivery problems. All four land in the status report as delivery slippage, because slippage is the only column the report has.

Two numbers worth tracking

The first is decision cycle time. For every decision the program needs, log the date it was first raised and the date somebody actually answered it. Not discussed, not noted, answered. The gap is the cycle time. Where we have run this, the distribution comes out lumpy: a cluster closed inside a week, then a long tail sitting at thirty, sixty, ninety days. The tail is where the schedule goes. That pattern is illustrative, not a benchmark. Measure your own.

The second is the share of in-flight work blocked on an answer rather than on capacity. Under ten percent and your constraint really is people, so a resourcing plan makes sense. A third or more and adding people will make things worse, because more parallel work generates more questions feeding the same queue.

Why the queue forms

Decision latency is rarely caused by indecisive people. It is caused by structure, and there are four structures that produce most of it.

The first: the decision has an audience instead of an owner. When a question belongs to the steering committee, it belongs to a calendar slot rather than a person, and it inherits that slot’s frequency as its floor. A monthly forum cannot resolve anything in under a month.

Second, the forum is oversubscribed. A two-hour meeting with nineteen agenda items will settle four and defer the rest. Deferred items come back next month at the bottom of the list, and the queue compounds without anyone noticing.

Third, nobody knows what they are allowed to decide. Absent a written threshold, people escalate. Escalation feels safe and costs the escalator nothing. The cost lands on the schedule four months later, filed under something else.

Fourth, and most common of all, the decision is not ready to be made. It sits in the queue because the options were never worked up: no recommendation, no numbers attached, no statement of what happens if nothing changes. That one is a preparation failure, not a governance failure, and it is the cheapest of the four to fix.

What shortens it

Put a name and a date against every open decision. A decision log where each row has an owner is worth more than most steering packs, and it takes an afternoon to build from the existing risk and issue registers.

Write down the thresholds. State what a workstream lead can decide alone, what needs the program director, and what genuinely requires the sponsor. Organizations that do this usually find the working threshold has drifted two levels above where the policy puts it.

Cap the agenda. Five decision items per steering committee, each with a written recommendation circulated beforehand, beats nineteen status updates. If more than five are outstanding, the fix is a second forum or a delegated one, not a longer meeting.

Report the queue. Decision cycle time and the count of decisions aged past fourteen days belong on page one of the status report, alongside schedule and spend. What sits next to the schedule gets managed like the schedule.

What the measurement exposes

Measuring decision latency makes governance visible in a way status reporting never does. It shows which executives are structurally overcommitted and how much of the program’s schedule risk sits above the program manager, not below. Some of the approvals it exposes will turn out to exist for reasons nobody present can explain.

That is the point. A program manager who pushes delivery teams harder buys a few percent. Only the sponsor can shorten the queue, and no sponsor will act on a problem that appears on none of the pages they read.

Before the next recovery plan, run the count. Five items, one question: effort, or answer? If the answers outnumber the effort, resequencing will not save the date, and what you need is a governance plan wearing a schedule’s clothes.

Images: “Businesspeople planning tasks with sticky notes” by Rawpixel Ltd (CC BY 2.0); “Productivity: Clearing the Personal Kanban Board for a Special Project” by orcmid (CC BY 2.0); “‘The Fish Bowl’ meeting room” by EG Focus (CC BY 2.0). Sourced via Openverse.