It happens more than anyone wants to admit. A problem surfaces. Leadership feels pressure to act. A solution gets selected based on assumptions, past experience, or what worked somewhere else. Implementation begins before anyone has confirmed what is actually being solved.
The fix launches. Results are mixed. The problem persists in a slightly different form. The project never quite closes because the team keeps chasing new symptoms. Now the organization is tired, the budget is thinner, and the appetite for another improvement effort is lower than it was before you started.
Root cause work is not slow. Skipping it is.
Where the Pressure Comes From
The impulse to move fast on a solution is understandable. Problems that surface visibly, a backlog spike, a quality failure, an escalation, carry immediate pressure. Stakeholders want to see action, not a diagnostic phase.
The trap is that "action" and "progress" get conflated. Deploying a solution is visible and feels like momentum. Running structured diagnostic work looks like delay. So organizations skip it, or compress it into a few hours of whiteboarding, and move to solution design before the problem definition is solid.
The cost of that tradeoff does not show up at launch. It shows up at the six-month review, when the metric has not moved, or when a new symptom has emerged that looks suspiciously like the old one.
What Diagnostic Work Actually Does
The diagnostic phase does two things that nothing else in the improvement lifecycle can substitute for.
It separates the symptom from the source. A backlog is not a problem; it is an indicator. The problem might be demand variability, insufficient capacity, a handoff failure, a policy that creates rework, or an upstream input issue. Each of those has a different solution. Treating the backlog directly without knowing which one is driving it means you are guessing at best, and reinforcing the wrong behavior at worst.
It also neutralizes the loudest voice in the room. Every improvement effort has one: the person with the most tenure, the strongest opinion, or the most credibility from having solved something similar elsewhere. Diagnostic work does not dismiss that input, but it does not defer to it either. The data speaks for everyone. Not a gut feeling, not a benchmark from a different industry. Evidence from this process, in this organization, right now.
A Diagnostic Question Worth Asking First
Before any solution gets designed, one question cuts through a lot of noise:
Is the output exactly what the process was designed to deliver?
If yes
The process is performing as designed. The problem lives somewhere else: in the design itself, the inputs feeding it, the environment it operates in, or the expectations placed on it. A process fix alone will not solve it.
If no
The process is failing its own design. Now you are looking at execution gaps, adherence issues, capability shortfalls, or controls that are not working. Different problem, different solution set.
These are not variations of the same problem. Conflating them is how organizations end up redesigning a process that was already sound, or retraining people on a process that was fundamentally broken to begin with.
The Pattern Behind Recurring Problems
If your organization keeps solving the same problems, or starts improvement efforts that never quite close, the gap usually is not execution capability. Teams can generally implement what they are pointed at.
The gap is earlier. It is in how the problem was defined before solution design began.
Recurring problems are almost always a signal that the root cause was never isolated. The symptom was addressed, pressure came off, the project closed, and the underlying condition kept running until the next flare-up. That cycle has a compounding cost. Each iteration consumes resources and produces diminishing returns, not because the organization cannot improve, but because it keeps improving the wrong thing.
What Sustained Diagnosis Requires
Three things have to be in place before solution design begins:
A clear definition of what is actually broken
Not "the backlog is too long" or "quality is poor." What observable condition, in what part of the process, is producing the gap between expected and actual output?
Evidence that separates cause from correlation
Data stratification, process observation, 5-why chains. Something that rules out contributing factors and points to a root driver, not a plausible story about one.
Agreement on the problem statement before solution design starts
This is the one that gets skipped under pressure. Solution design that begins before the problem statement is validated is building on an assumption, not a finding.
If the Solution Fades, the Process Probably Is Not the Culprit
When a well-designed solution quietly fades back to the old way, the instinct is usually to re-examine the process or the technology. Occasionally that is right. More often, the problem is upstream: adoption was treated as an output of good design rather than a parallel workstream with its own requirements.
The question worth asking before the next initiative moves from problem statement to solution design: do we have confirmation of what we are actually solving, or are we moving on an assumption that feels solid enough to act on?
If the answer is the latter, the six-month review will confirm it.
No skip gates. Evidence-confirmed root cause only.
I built the diagnostic phase into FORGE specifically because this is where most improvement efforts go wrong, not in execution, but in problem definition. The Capability Gate between Root and Generate requires evidence of root cause before solution design begins. It is not a conversation or a meeting. It is a signed control artifact.
Solving the right problem starts here.
A 30-minute strategy conversation is enough to assess whether your current improvement efforts are structured for sustainable results or quietly set up to fade.
Schedule a Strategy ConversationPart of an ongoing series on operational design, process transformation, and what it takes to make change endure.