When the Problem Is Local: A Practical Guide to Linear Problem Solving

The pump is running again.

The alarm is cleared. Operations restarted the equipment. The immediate production risk is gone.

So—is the problem solved?

Not necessarily.

Restoring operation is a correction. It protects today’s production. Problem solving begins when the team can explain the gap, test what caused it, change the condition that produced it, and verify that the result holds. That protects tomorrow.

In practice, I see two opposite failure modes. One team closes the action as soon as the equipment runs. Another turns a bounded problem into a small research program. One stops too early. The other adds complexity before it adds evidence.

A local problem deserves neither guesswork nor unnecessary complexity.

It deserves a disciplined chain of evidence.

Linear does not mean shallow. It means the problem has a workable boundary and its cause-and-effect hypotheses can be tested directly.

Start with the gap—not the preferred solution

What I look for first is not a tool. It is the gap.

What should be happening, and what is actually happening?

A useful problem statement describes that difference without quietly inserting a cause or a preferred fix.

The weak statement has already chosen the cause. The better statement tells the team what condition to observe and leaves room for evidence.

A problem is usually ready for linear analysis when:

• the boundary is reasonably clear;
• the required and actual conditions can be described;
• the team can observe and influence the condition;
• competing cause hypotheses can be tested;
• the correction is unlikely to create a major new problem elsewhere.

If those conditions do not hold, the problem may need a wider systems view.

Go to the work before going to the tool

The meeting room produces opinions very efficiently.

The workplace produces evidence.

Before I ask for a Fishbone or Five Whys, I want to know what changed, what appeared first, and what was different on the good run.

• What happened immediately before the deviation?
• What changed recently?
• Which abnormality appeared first?
• Was the standard available, understood, and followed?
• Does the problem occur every time or only under certain conditions?
• What is different when the problem does not occur?

Separate four things:

1. Symptom — what became visible.
2. Possible cause — something that might explain it.
3. Supported cause — a hypothesis consistent with the evidence so far.
4. Verified cause — a condition tested strongly enough to guide corrective action.

A plausible story is not yet a verified cause.

Collect the right data—and keep the context

The operational definition is the quiet hero of problem solving.

If one observer records “startup delay” whenever startup takes longer than expected, while another records it only when an alarm occurs, the team does not have comparable data. It has two interpretations wearing the same label.

Then stratify. Separate the observations by the conditions that may matter:

• startup versus steady operation;
• asset, route, crew, material, or product;
• before and after a maintenance activity;
• normal and abnormal operating conditions;
• single factors and meaningful combinations.

Stratification is not about making the analysis look sophisticated. It is about preventing an average from hiding the difference that can test the cause.

Use tools for the questions they can answer

Problem-solving tools become dangerous when we ask them to prove more than they can.

Test the cause—do not vote on it

The team should never vote on root cause.

After observation, stratification, and cause generation, there will usually be several credible hypotheses. The next step is to make each one predict something that can be checked.

Evidence may come from comparison, event-sequence review, inspection, measurement, stratified history, controlled testing, isolation of a suspected factor, or confirmation that the proposed mechanism is technically credible.

The goal is not mathematical perfection for every shop-floor problem.

The goal is enough evidence to distinguish a cause from a good story.

Select the countermeasure after the cause is supported

Teams often fall in love with a solution before understanding the problem.

Training is proposed because it is familiar. Inspection is added because it is visible. A procedure is revised because it creates a document. A component is upgraded because capital feels decisive.

Any may be appropriate. None should be automatic.

The countermeasure should connect logically to the supported cause. Several actions may fit the same cause, so the team should compare effectiveness, risk, sustainability, cost, and possible side effects before implementation.

The best countermeasure is not always the largest one.

It is the one that changes the causal condition with acceptable risk and can be sustained by the operating system.

Verify more than action completion

“Procedure updated” is an output.

“Training completed” is an output.

“New part installed” is an output.

None demonstrates effectiveness.

Completion is administration. Effectiveness is evidence.

Verification should answer:

1. Did we change the intended condition?
2. Did the performance gap close?
3. Did the result hold without creating a new problem?

A closed action is not necessarily a closed problem.

Verification should also trigger standardization and learning: update the standard where appropriate, clarify the control point, make the abnormal condition visible, define who watches the result, retain the reasoning, and share the learning where the same mechanism may exist.

The Linear Problem-Solving Evidence Chain

Know when the problem is no longer local

A linear investigation can reveal that the original boundary was too small.

Pause and reconsider when:

• the issue crosses several functions or decision levels;
• it returns after a credible local correction;
• different symptoms share the same operating pattern;
• measures or incentives keep recreating the behaviour;
• the fix shifts delay, cost, risk, or workload elsewhere;
• no single team has enough authority to change the condition.

At that point, adding more branches to the Fishbone may not help. The problem may require systems thinking.

The next article will examine that situation:

When the Fix Creates a New Problem: How to Think Systemically in Operations

Solve the problem in front of you

Local problem solving is not simplistic.

It is disciplined work built on a clear boundary, direct observation, testable cause-and-effect logic, and verification.

Use the simplest method capable of producing reliable evidence.

No simpler.

And no more complicated.

Because the purpose is not to demonstrate how many tools the team knows.

The purpose is to change the condition—and know why it changed.