When something isn't working, the most visible problem isn't necessarily the real problem.
A piece of equipment fails.
A product isn't gaining traction.
A customer keeps experiencing the same issue.
A process isn't delivering the expected result.
A project encounters a regulatory obstacle.
The natural response is to fix what's immediately in front of us.
Sometimes that's exactly what should happen.
But sometimes we're treating the symptom rather than the cause.
And if we haven't understood the cause, even a technically correct solution can be the wrong solution.
The first problem you see may only be the symptom.
This principle is well established in structured problem-solving disciplines such as Six Sigma.
The objective isn't simply to make the immediate problem disappear. It is to understand why the problem occurred, identify the underlying causes and make an improvement that addresses them.
That distinction matters well beyond manufacturing and process improvement.
It matters in technical, regulatory and commercial decisions too.
Consider a hypothetical product that isn't gaining traction in a market.
The immediate conclusion might be:
"We need more sales activity."
Perhaps.
But what if sales activity isn't the underlying problem?
The product may not fit the way customers actually work.
There may be a regulatory barrier.
The commercial model may not suit the market.
The distribution channel may be wrong.
Customers may not understand the value proposition.
Local service capability may be missing.
Or the original assumptions about the opportunity may simply have been incorrect.
Increasing sales activity won't necessarily solve any of those problems.
Before fixing something, we need to understand what actually needs fixing.
Start with the problem, not the solution.
This sounds obvious.
In practice, it can be surprisingly difficult.
People naturally approach problems through the lens of their own experience.
An engineer may see an engineering problem.
A salesperson may see a sales problem.
A manufacturer may see a product problem.
A service provider may see a maintenance problem.
A regulatory specialist may see a compliance problem.
A customer may simply see something that isn't working.
None of those perspectives is necessarily wrong.
But none necessarily represents the whole problem either.
That's why one of the first questions I like to ask is:
"What do we actually know?"
Then:
"What are we assuming?"
Those are very different things.
Define before you solve.
One of the useful disciplines within structured problem-solving methodologies is defining the problem before attempting to solve it.
In Six Sigma's DMAIC methodology, for example, Define comes before Measure, Analyze, Improve and Control.
The sequence matters.
CUSIO doesn't turn every business question into a Six Sigma project. Nor does CUSIO provide Six Sigma consulting services.
But the underlying problem-solving principle is valuable:
Understand the problem and its causes before selecting the solution.
Before deciding what to do, understand:
- What is actually happening?
- What should be happening?
- What is the difference between the two?
- When does the problem occur?
- What evidence do we have?
- What changed?
- Who experiences the problem?
- What happens upstream and downstream?
- What assumptions are we making about the cause?
That last question can be particularly revealing.
Keep asking why — but verify the answer.
Root cause analysis is often associated with repeatedly asking:
"Why?"
It's a useful concept.
But asking why isn't enough.
At some point, the suspected cause needs to be supported by evidence.
Established root-cause analysis approaches focus on uncovering the underlying causes of problems so corrective action can address those causes rather than simply treating their effects.
Complex problems can also have more than one contributing cause.
That is an important qualification.
Real business problems don't always have one neat root cause.
There may be several contributing factors.
Some may be technical.
Others may be regulatory, operational or commercial.
The objective isn't to keep asking "why" indefinitely.
It is to investigate deeply enough to identify the factors that actually matter and can realistically be addressed.
The technical answer may still not solve the problem.
This is where technical problem-solving becomes particularly interesting.
Suppose we identify a technically correct solution.
It meets the specification.
It performs as intended.
It satisfies the engineering requirement.
That still doesn't necessarily mean we're finished.
Can it be implemented?
Can it be maintained?
Does it comply with the applicable regulatory requirements?
Can the customer operate it?
Can the organisation support it?
Does the commercial model work?
Does solving this part of the problem create another problem somewhere else?
A technically elegant solution that cannot operate successfully in its real environment isn't much of a solution.
Technical correctness is essential.
But it exists within a larger system.
Sometimes the cause sits somewhere else.
This is one reason cross-functional problems can be difficult.
The symptom may appear in one part of a system while its cause sits somewhere else.
A customer problem may originate with a product assumption.
A product problem may actually be an application problem.
A service issue may originate in how something was specified.
A commercial problem may have a regulatory cause.
A regulatory obstacle may be based on an incorrect interpretation of the requirement.
And sometimes everyone involved is doing their individual job correctly, but the interfaces between them aren't working.
That's when looking at the problem from only one perspective becomes limiting.
You need to follow the problem wherever the evidence takes you.
Don't become attached to the expected answer.
This may be one of the hardest disciplines in problem-solving.
Once we've invested time in an idea, product or proposed solution, we naturally want the investigation to confirm that we were right.
But investigation isn't supposed to prove our preferred answer.
It's supposed to help us discover the right one.
Sometimes the evidence confirms the original idea.
Sometimes it changes it.
And occasionally the investigation tells us:
"Don't do it."
That's useful information too.
Finding out early that an opportunity doesn't work can be considerably better than successfully implementing the wrong solution.
Good problem-solving should make the problem stay solved.
There is a simple question worth asking:
"Did we fix the problem, or did we just make the symptom disappear?"
The distinction is important.
The purpose of root-cause analysis is to identify the underlying causes of a problem so that corrective action can address the cause, rather than repeatedly treating its effects.
That doesn't mean every problem requires an exhaustive investigation.
Sometimes the cause is obvious and the solution is straightforward.
Structured methodologies need to be applied sensibly. The methodology should support logical thinking, not replace it.
The discipline is knowing the difference.
Understand first. Decide second.
That principle sits at the centre of how CUSIO works.
Understand the problem.
Separate what we know from what we're assuming.
Follow the evidence.
Look beyond the immediate symptom.
Bring in different perspectives when they're needed.
Identify the underlying cause or causes.
Then decide what to do.
Sometimes the answer will be technical.
Sometimes regulatory.
Sometimes commercial.
Sometimes it will involve connecting people who hold different pieces of the answer.
And sometimes the right conclusion will be that the original proposed solution isn't needed at all.
The objective isn't simply to find a solution.
It's to understand the problem well enough to choose a solution that actually addresses it.