
I was very impressed with Sissel's Lean Six Sigma knowledge. She makes it easy to identify improvements and create results.


"We need better suppliers." "We need more staff in production." "Our ordering system is outdated." The solutions were clear... But did they agree on the problem?
A furniture manufacturer contacted us to improve delivery performance.
The team was frustrated. Multiple deliveries were late, and there were different opinions about what was wrong.
But they already had the solutions ready:
"We need better suppliers."
"We need more staff in production."
"Our ordering system is outdated."
The team was ready to implement new systems and processes.
But they didn't agree on how delivery performance should be measured. Or how they should use available data to gain better insights.
Situation: A furniture manufacturer wanted to improve delivery performance. They already had solutions: better suppliers, more staff, new ordering system.
Problem: They didn't agree on how delivery performance should be measured or what it actually was today. Without shared problem understanding, the team pulled in different directions.
Approach: Took a few steps back. Agreed on measurement, mapped the process, analyzed variation.
Result: Focus shifted from "Why aren't suppliers delivering on time?" to "How can we create more predictability for suppliers?" Significant improvement in delivery performance.
Instead of jumping straight to solutions, we used a structured approach:
First, we agreed on how delivery performance should be measured and what it actually was today.
This sounds simple, but this is where disagreement emerged. Some thought delivery performance was "percentage of on-time deliveries." Others thought it was "average delay." And which delivery date was actually agreed upon?
Without agreement on measurement, they wouldn't know if they were moving in the right direction.
Then we mapped the entire process from start to finish.
From order to delivery. All steps. All decision points. All dependencies.
This revealed something interesting: Suppliers often received changed orders at the last minute. Sometimes multiple changes per order.
Then we analyzed available data to understand variation.
When did delays occur? Which product types? Which suppliers? Was there a pattern?
And here the magical shift happened.
From: "Why aren't suppliers delivering on time?"
To: "How can we create more predictability for suppliers?"
The data showed that delays often came after changed orders. Suppliers were doing their best, but their production schedules were constantly disrupted.
The problem wasn't the suppliers. The problem wasn't the number of staff. The problem wasn't the ordering system.
The problem was low delivery performance and a key cause was unpredictable orders to subcontractors.
By understanding the entire system, reducing variation in their own orders, and creating predictability, they significantly improved delivery performance.
Without hiring more people. Without changing suppliers. Without buying a new system.
To understand why shared problem understanding is so important, we can use a tree as a metaphor:
Symptoms are like the leaves on the tree. What we see and experience first. For the furniture manufacturer, the symptoms were delayed deliveries and frustrated customers.
The problem is like the trunk - what binds the symptoms together. The furniture manufacturer thought the problem was suppliers, staffing, or system. It wasn't.
Causes are like the roots. The fundamental factors that create the problem. The real cause was lack of predictability in their own planning.
Focusing on the leaves (symptoms) made it difficult to get clarity on the problem and identify the real root causes.
The sequence matters: First understand the problem. Then investigate causes. Finally, choose solutions.
Let me give another example that shows how easily we narrow down too early.
The Norwegian Institute of Public Health has described sleep problems as one of the country's most underestimated public health issues.
Question: What is the problem?
The answer is given in the problem description from the Institute: sleep problems.
But experience from courses shows that we often narrow down the problem based on our own experiences:
Someone who drinks coffee late at night thinks the problem is caffeine intake.
Another who is stressed at work thinks the problem is the work environment.
A third who has small children thinks the problem is lack of routines.
This tendency to narrow focus early is natural. We look for solutions based on our assumptions.
But when we are a team solving problems together, it's crucial that we have a shared focus and don't narrow down too early.
If we do this without gathering facts first, we risk overlooking the biggest opportunities for improvement.

The image shows how focus determines what is cause and what is effect.
When you set focus on "can't sleep":
Everything to the left becomes causes. For example, coffee late at night.
Everything to the right becomes effects or symptoms. Poor coping, reduced quality of life, sick leave, and finally disability.
But you could set focus elsewhere:
If you set focus on sick leave, sleep problems suddenly become a cause (something that happened before).
If you set focus on disability, both sleep problems and sick leave become causes.
Where you set focus - what you measure - determines what the problem is.
For the furniture manufacturer, low delivery performance was the problem they measured. Unstable planning was the cause. Lost customers was the effect.
The same phenomenon can be both cause and effect, depending on where in the cause-effect chain you set focus.
Maybe you don't manufacture furniture. But I bet you recognize the dynamic:
• The team has solutions ready before the problem is defined: "We just need better equipment"
• You disagree on how success should be measured and what the situation actually is today
• The same problem keeps coming back because you solved the symptom, not the cause
• Leadership asks "Why is this happening?" and gets five different answers from five people
• You spend time discussing who is right, instead of gathering facts
• New actions are implemented without anyone defining what success should look like
The consequence? You waste time and money on solutions that don't work.
Step 1: Agree on measurement before gathering facts
How should you measure the problem? What is the situation today? Before you agree on this, you risk that each person interprets the data differently. Like the furniture manufacturer: Agree on what "good delivery performance" means before you start.
Step 2: Map the process before choosing solution
Understand the entire system. Don't jump to conclusions based on parts of the picture. The furniture manufacturer discovered that large variations in order volume created challenges for suppliers - but only because they mapped the entire process.
Step 3: Analyze variation before determining cause
When does the problem occur? How often? What patterns do you see? Use data to understand before choosing solution. Don't let assumptions drive.
What's the difference between symptoms, problem and causes?
Symptoms are consequences of the problem (the leaves on the tree). The problem is what you measure (the trunk). Causes are what creates the problem (the roots).
The same phenomenon can be both cause and effect, depending on where in the cause-effect chain you set focus. Your focus determines what the problem is.
How do I know how far back in the cause chain we should go?
Ask: What is the purpose? If the goal is quick relief, treating symptoms may be right. If the goal is lasting solution, you must go to the root cause. Most important is that the team agrees on where you attack before you start.
What if the team disagrees on what the problem is?
Then you don't have a problem-solving problem, you have a focus problem. Stop, agree on how you should measure the problem, gather facts, and create shared problem understanding before continuing. Otherwise you're solving different problems.
How do we avoid narrowing down too early based on assumptions?
Distinguish between assumptions and facts. Before gathering data, acknowledge that each person has assumptions based on experience. Agree on shared measurement, gather facts first, then narrow down based on what the data shows, not what you think.
How do I get the team to spend time on problem understanding when they want solutions quickly?
Show the cost of wrong solution. The furniture manufacturer would have spent resources on new suppliers and more staff - solutions that wouldn't have solved the problem. Time spent on problem understanding saves weeks or months on wrong solutions.
This story is from our weekly newsletter, where we share experiences. Short stories for those who want to solve problems at the root and achieve measurable, lasting value creation.
Sign up for our newsletter:
If you want to learn more about the topics in this post:
• Tools and methods for root cause analysis
• Understand variation with statistical process control
• Learn systematic problem solving in Green Belt course
Lean Tech AS | Kristoffer Robins vei 13
0047 481 23 070
Oslo, Norway
L - Look for solutions
E – Enthusiastic
A – Analytical
N - Never give up
