Business Bottlenecks - Stalled Priorities
Root Cause Analysis for a Stalled Priority
Trace the approval delays, rework, missed handoffs and unclear ownership that keep important work from moving.
A project delay rarely shows up as one obvious failure. The completion date moves. An approval sits longer than it should. Work comes back for a second review, then a third. The same manager keeps getting pulled into decisions that were supposed to happen without her. Status meetings multiply and the priority still does not move much faster.
Eventually someone asks why it is still not done, which is the right question. The answers that show up first are usually guesses: the team is overwhelmed, the owner is not pushing hard enough, more people are needed, communication is the problem, the deadline was never realistic to begin with.
Any of those could be true. None of them should be assumed. A stalled priority needs root cause analysis grounded in the route the work actually took, not the explanation that happens to be closest at hand.
The symptom
A late date is not a diagnosis
Harvard Business School Online describes root cause analysis as a way to uncover the causes of a problem and develop specific solutions instead of repeatedly treating its symptoms.
For a stalled priority, the missed date is the symptom, not the story. More follow-up, more meetings and more pressure from above can create the appearance of movement for a while, but none of it touches why the work slowed down in the first place.
If this pattern sounds familiar, the most common reasons projects stall is a reasonable place to start reading. But the cause still has to be established from the specific priority in front of you, not lifted from a generic list.
Complex knowledge work rarely has one clean root cause. An unclear result triggers repeated review. Concentrated authority creates waiting. Every restart adds to the workload of the same handful of people already carrying it. These conditions feed each other. The job is to find the explanation the evidence actually supports, including the uncomfortable possibility that the work path is not the main problem at all.
The available evidence
What project tools show, and what they leave unresolved
Workfront, ServiceNow, Jira and similar systems will show owners, deadlines, dependencies, status changes, workload and reported blockers. Pull that record and you might find an approval that sat untouched for nine days, a handoff that failed twice, or a deliverable that kept bouncing back to review.
Use it. It tells you where work waited, looped or changed hands. It rarely tells you why. A ticket sitting in "In review" could be waiting on a specialist who is out that week, missing a piece of information nobody flagged, or stuck behind a decision meeting that only happens on Thursdays. Root cause analysis is the work of connecting that record to the actual operating condition behind it.
An illustrative example
The six-hour deliverable that took 19 days
A cross-functional team needs to finish a customer launch package: one PDF, a landing page and an email. The actual writing and design work is maybe six hours, split across two people. Nineteen days later it still is not approved, and the launch date has already been quietly pushed once.
The first explanation on offer is that the creative team is too slow. The project owner starts asking for daily status updates and floats the idea of bringing in a second designer.
The Jira history tells a different story. Marketing finishes the first draft on day one. Product asks for changes on day four, mostly wording. Legal reviews the revised version on day eight and flags a claim about compatibility that nobody had checked. Then an executive who was copied late reopens language product had already signed off on, in a comment thread that never gets fully resolved. At that point nobody is confident whose approval is actually final, so each reviewer starts treating their own pass as the last word.
The writing was never the bottleneck. The package spent nineteen days waiting on people and reopening decisions that were supposed to be closed.
"The team is slow" is what it looked like from the outside. Unresolved approval authority is what the timeline actually shows.
One fix worth testing on the next launch: name a single person who holds final approval once the specialist reviews are done. Earlier reviewers can still raise concerns, but they cannot reopen a decision that already closed without something new to point to.
If elapsed time drops on the next package and quality holds, that is real support for the diagnosis. If it does not move, the explanation was wrong somewhere, and it is worth revisiting.
Before the trace
Check the priority itself first
Not every stalled priority is a workflow problem, so before tracing approvals and handoffs it is worth checking whether the work could have succeeded at all. Is the intended outcome still useful, or has the business moved on without anyone updating the brief? Do the people involved actually share the same idea of what "done" looks like? Was this priority ever protected by a real decision about what would wait for it, or does it just have a name and a deadline? Does the team have the skill, information, funding and authority the work requires? And is a vendor, regulator, customer or another business unit quietly controlling the date regardless of what your team does?
A process map will not fix an outcome nobody believes in, funding that was never approved, or a dependency sitting outside your building. Only once those hold up does tracing the actual path become the useful next move.
The common mistake
Root cause analysis can stop too early
"The manager is the bottleneck," "the team is overloaded" and "communication broke down" describe what people can see happening. None of them explain what produced it, and it is tempting to stop right there because the sentence already sounds like an answer.
A manager who is delaying every decision is worth a second question: why does everything route through that one person? Maybe authority was never actually delegated, maybe nobody defined what decisions do not need her sign-off, or maybe the information arriving is incomplete often enough that she has learned not to trust it. An overloaded team raises a similar question in the other direction. Did the number of simultaneous priorities creep up without anyone noticing, did review loops multiply somewhere in the last quarter, or has ordinary, familiar work simply gotten harder because it keeps getting restarted from scratch?
A bottleneck analysis is useful for finding the constraint currently setting the pace. Root cause analysis is the step after that: asking what created the constraint, and what is keeping it there.
Finding the bottleneck tells you where to look next. It does not tell you what you are looking at.
None of this is about letting anyone off the hook. If anything it makes accountability more accurate, because it stops pointing at the person standing closest to the delay and starts pointing at what put them there.
The operational method
From root cause analysis to execution gap analysis
For a stalled priority, root cause analysis only holds up if it follows the work through what it actually encountered, not the version of the workflow that lives on a slide.
Emergent Skills runs this as what we call an execution gap analysis: compare the expected result against what happened, trace where the work waited or got reopened, and turn the best-supported explanation into one change you can actually test.
It also keeps human capacity separate from ordinary project resources, which get confused constantly. Capacity is not headcount, available hours, funding or authority. It is the usable cognitive bandwidth and access to skill a person actually has left once real demand is accounted for.
A work-path trace by itself cannot prove a capacity constraint. What it can show is that work keeps routing through the same overloaded people or the same high-demand conditions. Calling that the cause takes more evidence than the trace alone, plus a test that can be reversed if it turns out to be wrong.
The test
Change one condition and measure what happens
Root cause analysis should end in action, but not necessarily a redesign of the whole process. Pick one change that speaks directly to the best-supported explanation. Name the owner, the metric, and the result that would prove the diagnosis wrong. Then run it long enough to actually see whether waiting, rework, decision time or elapsed time moves.
If it improves, the diagnosis just got stronger. If it does not, check whether the change was carried out as designed. If it was, revise the explanation.
Used this way, root cause analysis is an operating habit, not a one-time workshop exercise.
Start with one stalled priority
The Stalled Priority Snapshot checks the expected outcome, priority choice, capability, funding, authority and external dependencies first. If the work path provides the best-supported explanation, it traces where the work waited, looped or routed through overloaded people.
The result is a one-page readout within 24 hours: one best-supported explanation, and one 14-day change to test, with an owner, a metric and a condition that would prove it wrong.
Give me one important priority that is stalled. In 90 minutes we will find where it is waiting, looping or routing through overloaded people, then design one 14-day change to test whether execution actually improves.
