Your Project Isn’t Behind Schedule. Your Decisions Are.
Here is a project management opinion that may make some executives uncomfortable:
A lot of “schedule problems” are not schedule problems. They are decision problems. The project team gets blamed because the milestone slipped. The project manager gets asked for a recovery plan. The schedule gets compressed. The team is told to work faster.
But nobody asks the uncomfortable question: How much time did we lose waiting for decisions?
- Waiting for scope approval.
- Waiting for a sponsor to choose between two options.
- Waiting for requirements to be clarified.
- Waiting for a vendor selection.
- Waiting for a budget decision.
- Waiting for legal review.
- Waiting for an executive to decide what mattered more.
Waiting for someone to say yes. Or no. Or anything. Then, after three weeks of waiting, the decision finally arrives.
And the project manager is asked: “Can we still hit the original date?”
That is not schedule management. That is schedule fiction. Project schedules are built on assumptions about how long work takes.
But work cannot begin when critical decisions remain unresolved. A two-day task that waits three weeks for approval is not a two-day activity from the project’s perspective. It consumed three weeks and two days.
Yet organizations frequently track the two days and ignore the three weeks. That creates a distorted view of project performance. The project appears slow. The team appears inefficient.
The project manager appears unable to control the schedule!!
But the real bottleneck is governance.
This is one of the most common patterns I see in troubled projects. Teams are not always failing to execute. Leadership is sometimes failing to decide.
That distinction matters because the recovery strategy is completely different.
If the team is truly slow, you may need more resources, different skills, better planning, or process improvement. If decisions are slow, adding people will not solve the problem.
- You need better governance.
- You need clear decision rights.
- You need escalation thresholds.
- You need deadlines for executive decisions.
And you need transparency around the impact of waiting.
One of the simplest project controls I recommend is a decision log. Not a complicated system. Just a visible record of:
- What decision is required?
- Who owns it?
- When was it requested?
- When is it needed?
- What happens if it is late?
- When was it actually made?
That last question matters.
Because when a project enters recovery, the decision log often tells a very different story than the project schedule. It shows how much delivery time was actually lost outside the delivery team. This is not about blaming executives.
Good project governance is not about blame.
It is about visibility. Executives are busy. Sponsors manage competing priorities. Business owners may need additional information. Some decisions genuinely require discussion.
But every decision has a cost of delay. That cost should be visible.
Imagine a software implementation.
The team needs approval on a future-state workflow. The decision is scheduled for Monday. Monday passes. Leadership wants more information. The meeting moves to Thursday.
Thursday arrives and one stakeholder cannot attend. The discussion moves to the following Tuesday. Tuesday’s meeting ends without agreement.
Another meeting is scheduled.
Three weeks later, the project receives direction. The implementation team now has three weeks less time to configure, test, train, and deploy.
What typically happens next?
Nobody moves the go-live date. Instead, the schedule gets compressed. Testing gets shortened. Training gets squeezed. The team works evenings. Risks increase. Then something breaks. It always breaks!
And... everyone asks why the project was poorly managed. That is how governance failures become delivery failures.
The same pattern happens with scope.
Scope creep is often described as something the project manager failed to control. Sometimes that is true. But scope creep is also frequently a leadership behavior. Someone asks for “one small change.” Nobody wants to say no. This is what usually happens:
- The change is approved informally.
- No schedule impact is accepted.
- No budget impact is acknowledged.
- No resource adjustment is made.
- The work is simply added.
- Then another request comes.
- Then another.
Eventually the project is expected to deliver 120% of the original scope with 100% of the original time and budget. That is not scope management. That is wishful thinking.
Strong project governance requires leaders to recognize that every meaningful decision has consequences.
If scope increases, something else may need to move. If a decision takes longer, the schedule may need to move. If a deadline cannot move, scope or quality may need to change. If resources are constrained, priorities must be established.
Project managers can identify tradeoffs. They cannot eliminate them.
That is why executive sponsors are so important.
A strong sponsor does not simply attend steering committee meetings. A strong sponsor clears obstacles. They also are present in the moment to:
- Makes decisions.
- Forces alignment.
- Protects priorities.
- Resolves conflicts.
- And accepts the consequences of tradeoffs.
That is leadership.
When a project becomes troubled, one of the first things I would examine is the decision environment. I would ask:
- How many critical decisions are currently open?
- How long have they been open?
- Who owns them?
- Which tasks depend on those decisions?
- What milestones are now at risk?
- Which issues have been escalated repeatedly?
- Where is authority unclear?
- Which meetings are status meetings that should actually be decision meetings?
Those questions often reveal why the project is struggling. Sometimes the fastest way to recover a project is not to change the schedule. It is to change how decisions are made. That might mean:
- Creating a weekly decision forum.
- Giving the project manager greater authority.
- Setting escalation deadlines.
- Reducing the number of approvers.
- Separating advisory stakeholders from decision owners.
- Creating clear decision thresholds.
- Documenting the cost of delay.
- Requiring decisions to be made with the information available rather than waiting indefinitely for perfect information.
This is also where business process optimization intersects with project management.
Decision-making is a process.
Like any business process, it can be slow, redundant, unclear, or poorly designed. How many approvals are actually necessary? Why does a decision require four meetings? Why are ten people reviewing something that one business owner can approve? Why does every exception need executive approval? Why are decisions being made in meetings instead of through defined workflows?
Organizations spend enormous effort optimizing operational processes while ignoring their decision processes.
That is not a win...That is a mistake. Slow decisions create slow projects. And slow projects create cost. Vendor cost. Labor cost. Opportunity cost. Change fatigue. Lost stakeholder confidence. Delayed revenue. Delayed benefits.
The project schedule should expose that cost, not hide it.
One of the healthiest changes an organization can make is to stop treating executive decision time as invisible. It should be added to the project schedule as a change order as soon as possible. Your estimates for executive-level decision-making should always be liberal.
If leadership needs two weeks to make a decision, put three weeks in the schedule.
If that sounds unacceptable, improve the decision process.
Do not pretend the time does not exist. Because eventually the project team will be forced to absorb it. And that is where burnout begins.
Good project management is not about creating a schedule that makes everyone comfortable.
It is about creating a schedule that reflects reality. Reality includes the time it takes to do the work. And the time it takes the organization to decide what work should be done.
So the next time a project falls behind, before asking the project manager for another recovery schedule, ask one question:
How much time did we lose waiting for decisions?
The answer may change the entire recovery conversation. Your project may not be behind schedule.
