Walk into any program that's slipping and you'll be handed a story about the work. The integration was harder than scoped, the vendor was late, the requirements kept moving. Sometimes that's true. More often, when I trace the slip back to its origin, I don't find a hard problem that took too long to solve. I find a decision that took too long to make — a question that sat in an inbox, a meeting agenda, or a "let's circle back" for three weeks while the team worked around it, built on top of it, and eventually had to tear out what they'd built once the answer finally came. The work wasn't the bottleneck. The decision was.

This is not a niche failure mode. In a McKinsey survey of more than 1,200 managers and executives, 61 percent said that at least half the time they spend making decisions is wasted — and the same research estimated that inefficient decision-making drains a typical large company of hundreds of thousands of manager-days a year. Read that from a program seat: the most expensive resource you have isn't compute or contractor hours, it's the calendar time that disappears between a decision becoming necessary and a decision getting made. We instrument the work obsessively and leave the decisions completely dark.

Where decisions go to die

Decisions don't fail to get made because people are lazy or stupid. They die in three specific, structural ways, and each one is invisible on a normal status board.

1. The decision nobody owns

The most common one. A question comes up that crosses two teams — whose budget covers the new environment, which data model wins, who absorbs the scope change. Because it sits between owners, everyone assumes someone else has it. It's raised in a meeting, nodded at, and orphaned. Three weeks later it surfaces again, exactly as unresolved as before, except now four downstream tasks are blocked behind it. Nobody dropped the ball. The ball was never assigned to a hand.

2. The decision waiting on the cadence

The answer exists — it just can't be spoken until Thursday. The decision needs the steering committee, the steering committee meets every two weeks, and a question that became urgent on a Monday now waits eleven days for a forum to convene. The cadence that was built to create order becomes the thing that injects delay. I've watched programs lose more schedule to "it's not on the agenda until next cycle" than to any technical problem on the plan.

3. The decision made and then lost

This one's the quiet killer. A call gets made in a hallway, a thread, or a meeting nobody minuted. Six weeks later the same question reappears because the people in the room have rotated, and there's no record of what was decided or why. So the program re-litigates it — burning the time twice and, worse, sometimes landing on the opposite answer, which means the work already done against the first decision is now wrong. A decision you can't retrieve is a decision you didn't really make.

The principle

AI cannot make the call for you, and it shouldn't try. What it can do is make the absence of a decision visible — surface the question that's been open eleven days, name who owns it, and show what's blocked behind it — before the silence costs you the schedule. The decision stays human. The latency becomes measurable.

Treat latency like any other risk

The Army taught me a hard truth about command: a decision delayed is itself a decision — usually the decision to let the situation decide for you. The worst thing a leader can do under pressure is not the wrong call; it's no call, held so long that the options expire on their own. That instinct translates directly to program governance, and it's where an AI-augmented setup earns its keep. The same systems I've described for early risk detection can watch the decision layer the same way they watch the work: every open decision logged with an owner and a date it was raised, and an agent that flags the ones aging past a threshold — not buried on page four of a deck, but at the top of the weekly, where leadership has to look at them. The point isn't automation for its own sake. It's that "what are we waiting on a decision for, and how long has it been waiting" stops being a question someone has to remember to ask and becomes a number that's always on the board.

The unglamorous half of this is the decision log, and it's the part everyone skips. Every material decision gets one line: what was decided, who owned it, the date, and the one-sentence why. That record is what kills the third failure mode — nobody re-litigates a decision they can retrieve. It's also the thing that makes AI useful here at all, because the same data discipline that makes a status report trustworthy is what lets an agent reason about your decisions instead of hallucinating around the gaps. And as with everything else on an AI-augmented program, the model surfaces and summarizes, but a named human still owns the call. The agent can tell you a decision is eleven days old and blocking five tasks. It cannot, and must not, be the one who finally signs it.

How to actually do this
  • Track decisions, not just tasks. Open a decision log the day the program starts: question, owner, date raised, status. If it isn't written down, it isn't being managed.
  • Assign every open decision a single owner. A decision that belongs to "the team" belongs to no one — name the hand the ball is in.
  • Measure decision age. Put the oldest open decisions at the top of the weekly, the same way you'd surface an aging high risk. Latency is the metric, not volume.
  • Build an escalation path that beats the cadence. If a decision can't wait for the next steering meeting, there has to be a defined way to force it sooner — or your cadence is a delay engine.
  • Log the answer and the reasoning. One line per decision kills the re-litigation tax and gives your AI tooling something true to reason over.

The bottom line

The schedule you're protecting isn't mostly lost to work that's too hard. It's lost in the dead air around decisions nobody owned, decisions that couldn't be spoken until the next meeting, and decisions that got made and then evaporated. None of that shows up on a task board, which is precisely why it goes unmanaged for so long. AI won't make your hard calls — that's still the job, and it should be. But it will hold a light on the ones you haven't made yet, count the days they've been waiting, and refuse to let the silence pass for progress. Manage the decision backlog like it's part of the critical path, because on most programs it is.