The Business Owner Is Never Available and the Project Is Paying for It

The work is ready. The person who can unblock it is not.

A story needs one clarification before it can be built. A design needs one sign-off before development. Both wait on the same business owner, who is in back-to-back meetings, traveling, or booked three weeks out. So the team keeps busy on lower-value work, or makes a guess and moves on, because stopping feels worse.

Then the owner surfaces, and half the guesses were wrong. Work gets rebuilt. A decision made in good faith gets overturned. And it is nobody’s fault, because the owner was busy and the team was trying to make progress.

This is not a one-off. It is how the project runs. Work backs up behind one calendar, and the project pays for it downstream.

Project clinic summary

Symptom:
The project keeps stalling because decisions, clarifications, and sign-offs all wait on one business owner who is rarely available.

Likely causes:
The owner’s time was never scoped into the plan; there is no delegation or proxy path; every decision routes through one person regardless of size; and there is no agreed way to proceed when they are out.

BA move:
Separate what genuinely needs the owner from what does not, batch and route the rest through named proxies or documented defaults, and make the delivery cost of waiting visible so availability is owned as a project risk.

Why this hurts the project

The idle time is the cost you can see. It is also the smallest part.

The expensive part is the guessing. A wrong guess costs the rework, the regression testing, the re-explaining, and the updated acceptance criteria. Worse, some guesses become decisions made by people without the authority to make them, and those get reopened when the owner returns and sees what was settled without them.

Then there is a quieter cost that looks like good BA work. The BA becomes the buffer, answering for the owner and holding assumptions so the team can move. That hides the problem from the sponsor, whose project still looks like it is moving.

The reframe that matters: the project is not slow because one person is busy. It is slow because it cannot legitimately move without them.

What this usually looks like in practice

The signs are familiar once you name them. Decisions batch up waiting for one meeting that keeps slipping. “We’ll confirm with the owner” sits on nearly every open item. The team holds a list of assumptions it is “proceeding on”, unsure which are validated. Sign-off happens in a rush before a deadline, with no real review. And the same question gets answered twice, because the first answer came from a stand-in and did not hold.

What the team says and what is actually happening are usually two different things.

The left column is a project coping. The right is one carrying a dependency it has not named.

Likely causes

None of these are about the owner being difficult or disengaged. They are about how the project was built.

The owner’s time was never scoped into the plan. The schedule assumed access nobody secured, so the dependency was real from day one and never named as a risk.

There is no delegation or proxy path. The owner is the only sanctioned route, and no deputy can decide even the small things.

Every decision routes to one person regardless of size, so a low-risk wording change and a strategic trade-off wait in the same queue. The critical waits behind the trivial.

Asks arrive one at a time, dripped individually instead of batched into something the owner can clear in one sitting.

There is no agreed rule for proceeding when the owner is out, so the project stops or guesses. It became the plan by absence.

Readiness gates quietly depend on the owner. A story cannot be “ready” or “done” without input only one person can give, baked into the definition of ready and done rather than made visible.

Diagnostic questions

When the project keeps stalling behind one person, trace it back:

1. Was the business owner’s time ever scoped into the plan, or is the project assuming availability it never secured?
2. Does every decision route to this one person, or only the ones that genuinely need their authority?
3. Is there a named deputy who can decide anything, or is the owner the only sanctioned route?
4. When the owner is out, does the project have a rule for proceeding, or does it stop and guess?
5. How many open items are waiting on this one person, and how long has each been waiting?
6. Are the team’s asks arriving batched and decision-ready, or one at a time?
7. When a stand-in decides, does it hold, or get reopened when the owner returns?
8. Is the delay visible to the sponsor as a risk, or is the BA absorbing it quietly?
9. Do readiness or sign-off gates silently depend on this owner without anyone naming it?
10. Is “waiting on the owner” treated as normal, or as a signal worth escalating?

If most of your answers point at structure rather than at one person’s diary, you are not dealing with a busy stakeholder. You are dealing with a single-point dependency the project never designed around.

IT Project Problem Diagnostic Checklist includes a Stakeholder Alignment section. Use it to check whether the people your project depends on have the availability and authority the plan quietly assumes.

What the BA can do earlier

Every move here reduces the project’s need for the owner’s live time. None is “chase harder”.

Triage the owner’s queue into three buckets. Sort every item waiting on the owner into one of three: genuinely needs their authority, could go to a named proxy, or could proceed on a documented default. Output: a triage list that shrinks the real queue.

Batch and structure the real asks. Stop dripping the owner’s items one at a time. Bundle them into a decision-ready pack: question, options, recommendation, and the cost of not deciding by a date. Output: a pack the owner clears in one sitting.

Establish a proxy and a default rule. Get a named deputy sanctioned for a class of lower-risk items, and agree a rule for the rest: proceed on the documented default unless corrected by a stated date. Output: a delegation agreement the sponsor signs off.

Make the waiting cost visible. Track blocked days and rework from late input, reported in delivery terms. Not “the owner is never around”, but “we lost eleven days this month waiting on one approver, and reworked three stories”. Output: a waiting-cost view that turns availability into a risk the sponsor owns.

Move the dependency upstream. Where the owner’s input is predictable, capture it earlier as documented decisions and acceptance criteria, so fewer questions need a live answer. Output: a smaller synchronous queue.

Escalate the structure, not the person. Take the dependency to the sponsor as a design issue: “the plan assumes availability we do not have, here is what it costs, here are three options.” Output: a sponsor decision on how much owner time the project needs and gets.

A short example

A BA has thirty-odd items in a “waiting on owner” list, and the owner is booked solid for two weeks. The instinct is to chase for a meeting.

Instead, the BA sorts the list. Six items genuinely need the owner. Eleven could go to a well-briefed team lead. The remaining thirteen have a sensible default and need only a “shout if this is wrong” window.

They take the split to the sponsor: “Of the thirty things waiting on one person, six actually need them. Can we get a proxy for the eleven and a default rule for the thirteen, so the real queue is six?”

The owner’s queue drops from thirty to six. And because those six are the only things on it, the sponsor can finally see what they cost. The dependency did not get chased away. It got small enough to see and own.

Common mistakes

Letting the BA quietly absorb the delay. Becoming the buffer keeps the project moving and the problem invisible. Helpful now, expensive over a quarter.

Treating every decision as owner-sized. When trivial and critical share one queue, the critical waits behind the trivial. Sorting by who needs to decide is half the fix.

Accepting rushed sign-off as a real decision. An approval with no time to review is the kind that gets reopened later.

FAQ

Isn’t a busy business owner just a fact of project life?
Their being busy is a fact. Routing everything through them with no alternative is a choice, and choices can change. The fix is not a less busy owner. It is a project that does not need them for everything.

What if the sponsor shrugs it off?
That is why the waiting-cost view matters. A count of lost delivery days and reworked stories is harder to wave away than a complaint, because it names a risk the sponsor is accountable for.

Is this the same as decisions stalling in general?
It overlaps but it is narrower. This is about throughput bottlenecking on one person’s access. If decisions have no clear owner at all, the related read on decisions that keep stalling [INTERNAL LINK: Decisions Keep Stalling in Your IT Project] is the better start.

Where to go next

If sign-off gets rushed and then unpicked, the companion read is on decisions that get reopened later Your Project Keeps Reopening Decisions That Were Already Signed Off. And if the owner dependency is baked into how you decide a story is ready or finished, check how your readiness gates Definition of Ready and Definition of Done: The Two Quality Gates BAs Actually Control are defined, because that is often where the dependency hides.

Your next step

Pull the current list of everything waiting on your business owner. Sort it into three buckets: needs them, could go to a proxy, could proceed on a default. Then count how many genuinely need that one person. The gap between that number and the full list is the cost you have been absorbing without naming it.

Before the next decision stalls, use the IT Project Problem Diagnostic Checklist to see where unowned decisions and stakeholder gaps are already building up on your project.