Before You Reach for Root Cause: Are You Fixing a Breakdown or Redesigning a System?

A pump fails. A work order is late. A contractor crew waits for a permit. A production target is missed.

The instinct is immediate: find the root cause.

That instinct is often right. But it is not always the right first move.

Some problems are contained: a deviation can be defined, the relevant conditions can be observed, a limited set of hypotheses can be tested, and the team can correct and verify the result. Other problems return after every corrective action, move between departments, or worsen when one team optimizes its own part of the work. Those are warning signs that the issue is not merely a local breakdown. It may be a system pattern.

Root-cause analysis is not one universal technique; it is a family of methods used to uncover causes of problems. That is exactly why method selection matters. A familiar tool can still be the wrong tool for the condition in front of you.¹

The question before root cause

Before launching an investigation, ask one question:

A localized equipment failure, a missing approval, or a late work package may require fast linear investigation. But chronic backlog, recurring schedule instability, long permit delays, poor materials availability, or repeated friction between operations and maintenance usually demand a broader view of interactions, incentives, handoffs, and feedback.

A systems perspective does not reject local problem solving. It asks leaders to manage interrelated components as a unified whole, rather than assuming a collection of separately optimized actions will automatically produce better overall performance.²

The Operations Problem-Solving Triage

The triage below is an original WeCAN Solv conceptual model. It is not an industry benchmark, a maturity score, or a validated diagnostic instrument. It is a simple pause point for choosing a sensible starting response.

Use two questions.

1. Can we directly change this?

• Controllable: the team owns the decision, process, asset condition, or work method.
• Influenceable: the team cannot solve it alone, but can work with the people who own a critical part of the condition.
• Outside practical control: the condition is external or constrained beyond the team’s realistic authority.

2. Is the problem contained or distributed?

• Contained: one event, asset, task, work package, process step, or decision.
• Distributed or recurring: several functions, time periods, handoffs, priorities, incentives, delays, or feedback effects are involved.

The point is not to classify a problem perfectly. The point is to stop choosing a tool by habit.

When linear problem solving is the responsible choice

Linear problem solving is powerful when the team has a workable boundary and can act on the important conditions. It is often the best starting point for a defined defect, a specific failure event, an unclear work instruction, an approval that is repeatedly missed, or a limited handoff breakdown.

A disciplined sequence is straightforward:

1. Define the deviation. What should be happening? What is happening instead? Where and when does it occur? What is the consequence?
2. Gather evidence close to the work. Use observations, records, timing, equipment condition, work history, and the people who know how the job actually happens.
3. Organize possible causes. Fishbone diagrams, cause-and-effect maps, and similar methods can prevent the first confident explanation from becoming the conclusion.
4. Turn possibilities into testable hypotheses. Ask what you would expect to observe if a proposed cause were contributing—and what evidence would weaken that explanation.
5. Correct, verify, and standardize. An action is not complete when it is assigned. It is complete when the result is checked and the improved method is usable in normal work.

This sequence brings clarity without turning every issue into a major workshop. It makes reasoning visible and shifts the discussion from opinion to evidence.

When a local fix is not enough

Now consider a recurring operations pattern:

• Schedule compliance is low.
• Break-in work consumes the week.
• Preventive work is deferred.
• Failures increase.
• Supervisors are overloaded.
• Materials are unavailable when needed.
• Operations and maintenance blame each other for missed commitments.

A local root-cause exercise may still find valuable corrections. A late material release or unclear permit handoff deserves attention. But where the whole pattern returns, leadership needs a wider question:

Systems thinking is useful where there are too many interdependencies to hold in mind at once. A causal-loop diagram is one way to make cause-and-effect assumptions and feedback relationships visible. It is a hypothesis-building aid, not a magic proof machine.³

The value is the conversation around the loop:

• Where can we observe this relationship?
• Which link is evidence, and which is assumption?
• What delay is hiding the effect of our earlier decision?
• What intervention might improve the whole pattern rather than move the burden?
• Who needs to be involved because the solution crosses their boundary?

Public systems-thinking guidance makes the same point in a different setting: feedback-loop maps can help teams visualize relationships where stakeholders and interdependencies are too complex to retain mentally.⁴

The overlooked middle: workarounds and ownership boundaries

Not every constraint can be removed immediately. A temporary workaround may protect safety, service, quality, or production while the organization investigates a deeper issue. That can be entirely appropriate.

But a workaround needs a clear label, an owner, an expiry condition, and a decision about whether it is buying time for a genuine solution or quietly becoming the new operating system.

A 15-minute triage before the investigation

You do not need a workshop to apply this model. Before launching a formal investigation, take 15 minutes and ask:

1. What is the observable performance gap? State expected versus actual performance without leaping to explanation.
2. What is the current boundary? Is this one event, one asset, one task—or a pattern across time and functions?
3. What can we control, influence, or only adapt to? Name the real decision authority.
4. What evidence do we have—and what are we assuming? Separate observations from conclusions.
5. What is the right next method? Decide whether the condition needs linear investigation, system mapping, an interface redesign, or a leadership-level risk conversation.

That pause can prevent weeks of effort aimed at the wrong level of the problem.

It is not either/or

Linear and systemic thinking are not competitors.

A systemic issue often contains local defects that still need immediate correction. A local failure can reveal a wider design weakness. The skill is knowing when to move between levels:

• Fix the failed component—then ask whether the failure was isolated or part of a recurring condition.
• Correct the late permit—then ask whether the permit process creates a pattern of avoidable delay.
• Resolve the material shortage—then ask whether planning, inventory policy, work readiness, and supplier coordination are operating as one system.

The strongest organizations do both: respond quickly to the breakdown and learn from the pattern.

Technology should support the discipline—not replace it

Over time, the WeCAN Solv product family is intended to support this discipline without pretending that software can think on behalf of the people responsible for the work:

• WrenchWise™ is being developed to support structured frontline observations and clearer work-condition evidence.
• DecideWise™ is being developed to support transparent comparison of viable options and trade-offs.
• ValueStreamWise™ is being developed to help teams visualize cross-functional flow, constraints, and handoffs.
• HoshinWise™ is being developed to support alignment, ownership, review rhythm, and sustained execution.

Methods still come first. People define the problem, challenge assumptions, decide, act, and learn. Technology should make that operating discipline easier to run—not pretend to do the thinking for them.

The question to keep

The next time a team says, “We need root cause,” do not stop them.

Ask one question first:

A contained, controllable breakdown deserves fast and disciplined linear work. A recurring, distributed pattern deserves a system-level conversation. Choosing the right level of thinking is not delay. It is the beginning of solving the right problem.