Structured
Problem Description: When a Well-Defined Problem Is Half the Solution
— and Your Team Stops Wasting Weeks Solving the Wrong Question
Has it ever happened to you that your team spent three weeks of intense
work solving a problem — and at the end, you discovered they were solving something completely
different from what was actually going on? That the root cause they so
thoroughly analyzed wasn’t even what caused the defect? That the entire
beautiful 8D reporting effort amounted to nothing because the starting point was
wrong?
If you’ve worked in quality for at least five years, you’ve experienced this. Not once. Not
twice. Repeatedly. And always with the same feeling — frustration over wasted
energy that could have gone into the real solution.
The problem isn’t in the tools. The problem isn’t in the people. The problem is
that nobody has ever taught you how to properly describe
a problem.
Day One: When Everything Starts
Wrong
Imagine Monday morning. On your desk lies a complaint from a key
customer. An email from the production manager says: “We have a problem with the
color on lines 3 and 5. The customer is complaining.” Within two hours, a team has gathered. The
board is covered in Post-its. Someone is already proposing a solution. Someone
else is blaming the supplier. A third person is searching for when it first
happened.
After four hours, you have a full board and zero agreement on what is
actually happening. Because “a problem with the color” can mean twenty different
things.
Is it too light? Too dark? The wrong shade? Spots?
Uneven coverage? Peeling? Where exactly? On which parts? When did it
start? Is it on all batches or only on a specific one?
Until you answer these questions, every solution is a
lottery.
Why Is Defining a Problem So
Difficult
The culprit isn’t laziness or incompetence. The culprit is four
fundamental psychological and organizational barriers:
First barrier: The pressure for an immediate solution. Production
is down. The customer is waiting. Management wants an answer yesterday. Under this
pressure, we naturally jump to solutions before we even understand the problem. It’s
like prescribing antibiotics before you know whether it’s a bacterial infection.
Second barrier: The assumption that the problem is obvious.
“But we can clearly see what’s happening.” No. We can’t. We see a symptom. We see
a consequence. We see what is visible. But what’s visible is usually only the
tip of the iceberg.
Third barrier: Confusing symptoms with causes.
“The problem is that the supplier is sending bad material.” That’s not a problem
definition — that’s already a hypothesis about the cause. And if this hypothesis is wrong,
your entire subsequent investigation will go in the wrong direction.
Fourth barrier: Non-specific language. “Quality
problem.” “Defective parts.” “Process failure.” These phrases are so
general that they can mean anything — and therefore they mean nothing.
What Is Structured Problem
Description
Structured Problem Description is a systematic approach to defining
a problem before you begin any analysis. It’s not another problem-solving tool — it’s the
predecessor to every tool. It’s a discipline that
guarantees that before you pursue a solution, you know exactly what you’re solving.
Think of it this way: Every problem-solving effort has three phases —
Definition, Analysis, Solution. Most teams spend 5 %
of their time on definition, 30 % on analysis, and 65 % on solution. Successful teams
have it the other way around — 40 % on definition, 40 % on analysis, and 20 % on solution.
Because a well-defined problem practically solves itself.
Elements of a Proper Problem
Description
A structured problem description contains eight key elements.
None of them is optional. If you omit even one, you open the door for the wrong
solution.
1. Identity — What Is the
Object?
Not just “part” or “product.” Exactly which part? Which component? Which
operation? Which parameter? Drawing number, operation number, parameter name. Be so
specific that anyone reading your description could walk up to the line and point to
the exact piece.
2. Location — Where Is It
Happening?
Where does the problem manifest? On which line? At which station? At
which position on the part? Is it at the input, in the process, at the output? Is it
localized or scattered? A map is your best friend.
3. Time — When Does It Happen?
When did the problem first appear? When does it reappear? Is it
continuous or intermittent? Is it related to a shift change? To the time of day? To
a material batch? To a specific production sequence? A timeline is crucial.
4. Extent — How Big Is It?
How many pieces are affected? What percentage of total production? What
is the frequency of occurrence? Is it one piece out of a thousand or a hundred out
of a thousand? The extent defines urgency and prioritization.
5. Specification — What Is
Expected?
What is the required state? What is the specification? What does the
drawing say? What does the standard say? What does the customer say? Without a clear
definition of “correct,” you cannot define “incorrect.”
6. Reality — What Is Actually
Happening?
What is the actual state? What is the measured value? What are the visual
indicators? What is the deviation from the specification? Be factual. No interpretations,
no opinions. Only facts.
7. Consequence — Why Does It
Matter?
What is the impact on the customer? On production? On costs? On safety?
Why should anyone bother solving this problem? The consequence provides motivation and
context.
8. What It Is Not — The Negative
Definition
This is the most powerful and most frequently overlooked element. On which
lines is it NOT happening? On which parts does it NOT manifest? When did it
NOT occur? Which batches are FINE? What the problem is not is often
more illuminating than what it is.
Practical
Example: How It Looks in Reality
Let’s return to our color problem. Here is the difference between a typical and
a structured description:
Typical description (as 90 % of teams do it): > “We have
a problem with the color on lines 3 and 5. The customer is complaining about
poor surface quality.”
Structured description: > Identity:
Chrome decorative trim, part number DP-4421, operation C (cataphoretic
coating), parameter: color shade in CIELAB coordinates (L,
a, b*). > > Location: Line 3 and line 5,
station C-12 (cataphoretic bath). Defect location: right edge of the part,
approximately 15 mm from the edge, on the outer radius. The rest of the part is
fine. > > Time: First occurrence: March 14, 2026,
shift B (22:00–06:00). Subsequent occurrence: every shift B from March 14 to
present day. Shifts A and C: no occurrences. > >
Extent: Approximately 12 % of production on both lines during
shift B. Total of 847 defective pieces out of 7,056 produced. On shifts A
and C: 0 defective pieces out of 14,112. > > Specification:
ΔE ≤ 1.5 compared to the Masters sample (per VW TL 528). > >
Reality: ΔE = 2.8–3.4 on the right edge. Measurement:
X-Rite spectrophotometer, 3 measurements per piece. The deviation is consistently on
the right edge, never on the left. > > Consequence:
Customer (VW) has zero tolerance for visible defects. Current risk:
complaint worth €15,000, potential loss of 2 % of the order. > >
What it is not: It does NOT occur on lines 1, 2, 4, 6.
It does NOT occur on shifts A and C. It does NOT occur on the left edge. It does NOT
occur before March 14. It does NOT occur on parts DP-4422 and DP-4423
(same process, different shape).
See the difference? The second description already points you in the direction to
look. Shift B is affected, shifts A and C are not. Right
edge is affected, left is not. Only part
DP-4421, not the others. This information is like trace evidence at
a crime scene — it leads you straight to the culprit.
IS/IS
NOT Matrix — The Simplest Tool for the Hardest Step
One of the most effective ways to build a structured problem
description is the IS/IS NOT matrix. It’s a simple table that forces you to
think about what the problem is and what it is not.
| Dimension | IS (Problem Is) | IS NOT (Problem Is Not) |
|---|---|---|
| What | Chrome trim DP-4421, color shade | Parts DP-4422, DP-4423 |
| Where | Lines 3 and 5, right edge, shift B | Lines 1, 2, 4, 6; left edge; shifts A and C |
| When | From March 14, 2026, only shift B | Before March 14; shifts A and C |
| Extent | 12 % of production, ΔE 2.8–3.4 | 88 % of production, ΔE ≤ 1.5 |
This matrix does two things at once: it narrows the search
space and prevents premature conclusions. When you
see that the problem only affects shift B, you immediately eliminate all
factors that are the same across all shifts — bath temperature, chemical
composition, part type. What remains are only the differences between shifts.
When It Happens in the Real
World
In one automotive plant in Slovakia, a team had a problem with cracking
plastic engine covers. For three weeks, they analyzed pressure conditions,
temperature cycles, and material composition. No solution was in sight.
Then someone asked the right question: “On exactly which
parts is this happening, and on which ones is it not?”
The answer was surprising: only covers from one specific mold
(mold #4, cavity 3) were cracking. The other 11 cavities were fine. The problem
wasn’t in the material, the process, or the design. The problem was in the
wear of one specific cavity, which was causing internal
stress in that particular geometry.
The team spent three weeks solving a global problem that was actually
local. If they had spent three days on a structured problem description,
they would have been there in an hour.
How
to Implement Structured Problem Description in Your Organization
Implementing this discipline isn’t about a new form or template.
It’s about a change in mindset. Here are four steps that
work:
Step 1: The “No solutions for the first 24 hours” rule.
When a problem arises, for the first 24 hours, no one is allowed to ask, “What are we
going to do about it?” The only question permitted is: “What is actually
happening?” This simple rule eliminates 80 % of premature solutions.
Step 2: A standard problem template. Create
a simple form with the eight elements described above. Require it to be
filled out for every problem that goes beyond a single defect. Not as
bureaucracy — as discipline.
Step 3: Verification by an independent eye. Before the
team begins analyzing the problem, have the description read by someone who isn’t
involved in the problem. If that person can go to the line and point to the
problem, the description is good. If not, the description is inadequate.
Step 4: Post-solution review. When the problem is solved,
return to the original description and ask: “Did we solve what we
defined? Or did we change the definition along the way?” This is
the most important learning moment of the entire process.
Five Mistakes That
Kill a Good Problem Description
Mistake #1: Embedding causes into the definition. “The problem
is that the supplier is sending bad material, which causes cracking.” No.
The problem is the cracking. The fact that it’s because of the supplier is your hypothesis,
which still needs to be verified.
Mistake #2: Vague quantification. “Many pieces are
defective.” How many is “many”? 5? 500? 5,000? Without a number, you don’t have
a problem — you have a feeling.
Mistake #3: Ignoring what works. If a defect
appears on 3 out of 10 lines, then 7 lines are doing something right. Studying
what works is often a faster path to a solution than studying what doesn’t.
Mistake #4: One problem, five definitions. Every team
member has a different version of what’s going on. Before you start analyzing,
you must have one approved definition that everyone
agrees on.
Mistake #5: Defining once, forever. The problem description is
a living document. As you gather new information, update it. The first
version is a working hypothesis — not something carved in stone.
Connection to Other Methods
Structured Problem Description is not a standalone island. It’s the foundation
for every subsequent method:
- 8D: Step D2 (Problem Description) is directly
a structured description. Without it, D4 (Root Cause) is a lottery. - A3: The left half of an A3 is essentially a visual version
of a structured description. - Ishikawa Diagram: Without a precise description, you don’t know
which bones of the diagram are relevant. - 5 Whys: The first “Why?” must be based on facts from
the description, not on assumptions. - DOE: Design of Experiments requires precise
definition of factors and levels — that comes directly from the problem description.
Conclusion:
The Most Important Minutes of the Entire Process
The next time your team receives a complaint, do one thing:
stop. Don’t let anyone propose a solution for the first
twenty-four hours. Instead, sit down together and write a
structured problem description. With all eight elements. With an IS/IS NOT matrix. With
verification by an independent eye.
It will feel slow. It will feel unnecessary. It will be frustrating for
people who want to “already be doing something.”
But then — in three days, not three weeks — your team will look at that
description and see the solution. Because a well-described problem is like a well-mapped
terrain. The path suddenly becomes obvious.
And when it happens, you’ll remember this article and think:
“We were right. We should have stopped.”
The most important minutes of problem solving aren’t the ones where you propose
a solution. They’re the ones where you ask: “What is actually
happening here?” — and have the discipline to wait for the answer.
Peter Stasko is a Quality Architect with over 25 years of experience
in the automotive and manufacturing industries. His passion is translating
complex quality concepts into practical language that everyone can understand — from the
operator on the line to the CEO in the boardroom. He believes that quality isn’t
about documentation — it’s about discipline that starts with asking the right
question.
