Project Delays
Slow Decision-Making: Why Ready Projects Wait
The options are documented and the work is ready, but the call has no owner, no criteria or no open slot on the agenda. This page covers why ready projects wait on decisions, how to measure the wait and how to test a faster route.
Executive Summary One unresolved decision can control an entire project schedule +
Ready projects wait when a decision has no route: nobody owns the call, the decision-maker is overloaded, consensus replaces commitment, criteria arrive late or approvals sit in a batched meeting cadence. The delay costs twice: the wait itself, plus all the status updates and re-explanations spent managing it.
The fix starts with measurement. Record when each decision became ready, who owns it and when it was actually made. That interval is decision latency. Then change the route for one class of decision for 14 days and track whether the affected work advances sooner.
The Stalled Priority Snapshot is a $1,500, 90-minute session that traces where one important decision is waiting and tests a faster route.
A project team can be ready to move and still lose days or weeks because one decision has nowhere to go.
The options have been documented. The work is ready. But the sponsor wants more agreement, two departments believe the other owns the call, or the question has to wait for the next steering meeting. Sometimes the executive with authority simply has thirty other matters in the same queue.
The project remains active, but its next meaningful step is unavailable. This is how slow decision-making becomes a project constraint.
How slow decision-making delays a project
McKinsey found that fewer than half of surveyed managers said decisions in their organizations were timely. Sixty-one percent said at least half of the time spent making decisions was ineffective.
For a typical Fortune 500 company, McKinsey estimated the opportunity cost at about 530,000 days of managers' time and $250 million in wages annually.
The figure is a company-wide estimate and says nothing about any single delayed project. What it does show is that decision friction runs well beyond the occasional difficult choice.
A waiting decision creates secondary work. People prepare another status update, revisit the options and answer questions already covered. They adjust schedules that may move again. Team members keep carrying the unresolved matter while starting something else.
By the time the decision arrives, the cost includes both the delay and the labor spent managing it.
Project software can show that a task is blocked, a milestone is late or an approval is overdue. It may not show why the decision waited, how many people it passed through, or whether the person with authority had room to consider it. Those are questions about the route the work follows.
Five reasons project decisions wait
Decision rights are unclear
Several people are consulted, but nobody can say who makes the final call. Everyone can raise an objection, and nobody owns the decision date. The project governance chart may look complete while the actual decision rights remain uncertain.
The decision-maker is overloaded
Important work stacks up around trusted executives, managers and specialists. Research reported in Harvard Business Review found that 3% to 5% of employees accounted for 20% to 35% of value-adding collaboration in the organizations studied.
When the same small group supplies judgment, approval and rescue work across a portfolio, its queue becomes part of every project's schedule.
Consensus is used when commitment would be enough
Some decisions require broad agreement. Many do not. A reversible choice can sit unresolved while a group tries to eliminate every objection.
The extra discussion does not always improve the answer. McKinsey reports that only 37% of surveyed respondents said their organizations' decisions were both timely and high quality.
The criteria arrive late
The team prepares an answer without knowing what evidence the decision-maker will require. A new criterion appears during review and sends the work back for more analysis.
Decisions are batched
A steering committee meets every other Thursday. Missing one agenda creates a two-week approval delay, regardless of how small or reversible the decision is.
Measure decision latency, not meeting activity
- The date the decision became necessary
- The date the required information was ready
- The named decision owner
- The promised and actual decision dates
- Any reopening or reversal
The interval between "ready for decision" and "decision made" is the decision latency. It tells you more about the delay than the number of meetings held about it.
Separate preparation time from waiting time. A complex decision may require ten days of legitimate analysis. That is different from completing the analysis on Monday and waiting until the following Friday for somebody to choose.
If several projects are waiting on the same person or forum, use a bottleneck analysis to see whether that decision queue is controlling delivery across more than one priority.
Check whether the project still deserves the decision
- Is the intended outcome still valid?
- Does leadership still treat it as a chosen priority?
- Are the required capability, information, authority and funding available?
- Does an external dependency control the pace?
If the organization is unwilling to decide because it no longer believes in the project, a faster meeting will not solve the problem. The project needs an explicit choice: recommit, redefine or stop.
Test a faster decision route for 14 days
For low-risk decisions, you might also define when silence counts as approval, where policy allows it. If escalation is necessary, give the work one clear escalation point instead of several informal ones.
Track the age of the decision queue and whether the affected work advances sooner. Do not judge the experiment only by whether people liked the new arrangement.
Some decisions deserve the wait. Real dissent, hard evidence and careful judgment take time, and a 14-day test is not aimed at those. It is aimed at the routine choices where an unclear owner, an overloaded approver or a meeting calendar has been setting the project schedule by default.
When one decision is holding an important outcome
The Stalled Priority Snapshot traces where the decision is waiting, separates preparation time from waiting time and tests a different route.
