Diagnosis
Root Cause Analysis for a Stalled Priority
How does root cause analysis find what is actually holding it up?
The completion date moves. An approval takes longer than expected. Work comes back for another review. The same manager gets pulled into every decision. Status meetings multiply, but the work does not move much faster.
Eventually, someone asks, "Why is this still not done?"
That is the right question. But the usual answers are often guesses:
- The team is overwhelmed.
- The owner is not pushing hard enough.
- We need more people.
- Communication is the problem.
- The deadline was unrealistic.
Any of those could be true. None should be assumed. A stalled priority needs root cause analysis.
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 visible symptom. More follow-up, more meetings and more pressure may temporarily create movement, but they do not explain why the work slowed down.
Complex knowledge work may not have one isolated root cause. Several conditions can interact: an unclear result creates repeated review, concentrated authority creates waiting, and every restart increases demand on the people carrying the work. The point is not to force one simple answer. It is to identify the explanation best supported by the evidence.
An illustrative example
The six-hour deliverable that took 19 days
Consider a cross-functional team that needs to finish a customer launch package. The actual writing and design require about six hours. Nineteen days later, the package still has not been approved.
The first explanation is that the creative team is too slow. The project owner asks for more frequent updates and considers adding another designer.
But the route tells a different story. Marketing completes the first version on day one. Product requests changes on day four. Legal reviews the revised version on day eight. An executive then reopens language that product already approved. Nobody is sure whose approval is final, so every reviewer behaves as if it is theirs.
The work itself is not taking 19 days. The work is repeatedly waiting and reopening as it passes through competing review points.
"The team is slow" is the presenting explanation. Unresolved review authority is the better-supported constraint.
The team could test one routing change on the next launch package: one named person holds final approval after the specialist reviews are complete. Earlier reviewers can advise, but they cannot reopen a completed decision without new evidence.
If elapsed time falls while quality holds, the explanation gets stronger. If nothing changes, the team revises the diagnosis.
Before the trace
Check the priority itself first
Not every stalled priority is a workflow problem. Before tracing approvals and handoffs, check whether the work was able to succeed in the first place:
- Outcome validity: Is the intended result still useful?
- Outcome definition: Do the people involved share the same meaning of done?
- Priority choice: Was this priority protected by an actual decision about what would wait?
- Execution conditions: Does the work have the capability, information, funding and authority it requires?
- External dependencies: Is a vendor, regulator, customer or another business unit controlling the date?
A process map cannot solve an invalid outcome, missing funding or an external dependency. Only after these conditions hold does tracing the path become the useful next step.
The common mistake
Root cause analysis can stop too early
Statements such as "the manager is the bottleneck," "the team is overloaded" or "communication broke down" may describe what people can see. They do not yet explain what produced it.
If one manager is delaying decisions, ask why the decisions route through that person. Is authority concentrated? Are decision thresholds undefined? Is the information arriving incomplete? Are reviewers applying different standards?
If a team is overwhelmed, ask what changed in the work. Did simultaneous priorities increase? Did review loops multiply? Did decisions become denser? Did repeated restarts increase the effort required to complete otherwise familiar work?
A visible bottleneck is a place to investigate. It is not automatically the root cause.
This does not remove accountability. It makes accountability more accurate.
The operational method
From root cause analysis to execution gap analysis
For a stalled priority, useful root cause analysis has to follow the work through the conditions it actually encountered, not only the workflow shown on paper.
Emergent Skills calls this operational form of root cause analysis an execution gap analysis. It compares the expected result with what happened, traces where the work waited or reopened, and turns the best-supported explanation into one change that can be tested.
It also keeps human capacity separate from ordinary project resources. Capacity is not a synonym for headcount, available hours, funding or authority. It means the usable cognitive resources and access to skill available under real demand.
A work-path trace alone cannot prove a capacity constraint. It can show that work is repeatedly routing through high-demand conditions or overloaded people. Calling that a cause requires additional evidence and a reversible test.
The test
Change one condition and measure what happens
A root cause analysis should lead to action, but not necessarily a large redesign. Choose one change that directly addresses the best-supported explanation. Then run it long enough to observe whether waiting, rework, decision time or elapsed time improves.
If execution improves, the evidence supporting the diagnosis gets stronger. If it does not, revise the explanation. The intervention is not only the fix. It is part of the test.
That is root cause analysis used as an operating discipline, not a workshop exercise.
Start with one stalled priority
The Stalled Priority Snapshot checks the expected outcome, priority choice, capability, funding, authority and external dependencies. If the work path best explains the delay, it traces where the work waited, looped or routed through overloaded people.
The result is one best-supported explanation and one 14-day change to test.
Give me one important priority that is stalled. In 90 minutes, we will identify where it is waiting, looping or routing through overloaded people, then design one 14-day change to test whether execution improves.
