Defining the Problem and Setting Boundaries
Too many teams jump straight into a Fishbone diagram with a vague statement like “Our process is broken.” That approach leads to wasted time, misaligned efforts, and often, no real insight. I’ve seen this happen in manufacturing, software delivery, and healthcare—dozens of times. The real danger isn’t the diagram itself, but the assumption that a poorly defined problem will yield useful results.
The truth is, any RCA effort begins not with tools, but with clarity. A precise, measurable, and scoped problem statement is the foundation. Without it, you’re not investigating—you’re guessing.
This chapter walks you through how to define the problem with rigor, set firm boundaries, and avoid common pitfalls that derail investigations. You’ll learn how to transform vague complaints into focused, actionable challenges. By the end, you’ll have a method to ensure every RCA project starts with the right question—so you end with the right answer.
Why Problem Scoping Is Your First Real Step
A weak problem statement invites ambiguity. A strong one prevents it.
Consider this: “The customer is unhappy.” Vague. Open to interpretation. You could spend hours investigating shipping delays, billing errors, or poor support—when the real issue might be a single failed feature in the app.
Now consider: “Customer retention dropped 18% in Q2 due to login failures on mobile devices.” That’s specific. Measurable. Time-bound. It tells you where to focus.
Problem scoping in RCA isn’t about being overly restrictive. It’s about being precise. A poorly scoped investigation wastes energy chasing symptoms instead of uncovering causes.
Common Pitfalls in Problem Definition
- Too broad: “Our operations need improvement.” No clear target. No way to measure progress.
- Too narrow: “The error log shows line 42 failed.” Missing context. May lead to fixing a symptom, not the root cause.
- Blaming language: “The team didn’t follow protocol.” This invites defensiveness and distracts from systemic issues.
- Emotion-driven: “The system keeps crashing and it’s driving me crazy.” Emotion clouds objectivity.
Instead, use objective, data-backed language. Ask: “What exactly changed? When? Where? How much?” These questions help isolate the real issue.
Setting Investigation Boundaries
Boundaries define the “what” and “where” of your investigation. They prevent scope creep and ensure your team stays focused.
For example: “Why did the monthly audit fail?”—is too broad. “Why did the June 2024 compliance audit fail for the logistics branch in Denver?”—is specific. You can now define the boundary: only that location, only the June 2024 data, only compliance-related processes.
Think of boundaries as a fence. They don’t limit your insights—they channel them. Without them, a team can spend two days drawing Fishbone branches that apply to a different project entirely.
Key Questions to Set Boundaries
- What is the exact event or failure?
- When did it occur (or how often)?
- Where did it occur (location, system, process step)?
- What is the measurable impact (e.g., downtime, cost, error rate)?
- What is NOT in scope (to prevent drift)?
Answering these ensures consistency. It also makes reporting and follow-up far easier.
Using the 5W1H Framework for Clarity
I’ve used this framework in over 100 RCA sessions. It turns ambiguity into precision.
| Question | Example | Use in RCA |
|---|---|---|
| What? | Customer order processing fails after 2 PM | Defines the failure mode |
| Who? | Field service team in Chicago | Identifies responsible unit |
| When? | Every Tuesday and Thursday between 2:00–5:00 PM, June 1 to June 15 | Pinpoints timing and frequency |
| Where? | Order Entry System (OES), version 3.4.2 | Specifies system and environment |
| Why? | Failed to validate customer status in real time | Prepares for cause analysis |
| How? | System timeout after 30 seconds of inactivity | Provides observable behavior |
Use this to draft your problem statement. Example:
“The OES fails to process 12% of orders from 2:00–5:00 PM on Tuesdays and Thursdays (June 1–15), due to a 30-second timeout when verifying customer status, impacting the Chicago field service team.”
This is measurable, traceable, and focused—exactly what a root cause project definition requires.
When to Expand or Narrow the Scope
Some problems are interconnected. You may need to break a large investigation into phases.
For example: “Our customer satisfaction score dropped.” This could involve support, delivery, billing, and product quality. Don’t tackle all at once.
Start with the highest-impact area. Use data to prioritize. If delivery delays explain 60% of the drop, focus your initial RCA there. Once resolved, expand to other areas.
That’s how you turn a mountain into manageable steps. It’s not about doing everything—it’s about doing the right thing first.
Template: Building a Strong Problem Statement
Use this format to standardize your RCA start:
What happened? [Specific event or failure]
When? [Date, time, or frequency]
Where? [System, location, team, or process]
Extent? [Impact: % failure rate, cost, downtime, error count]
Why it matters? [Business or operational consequence]
Example:
What happened? Failed to generate invoices for 147 customers.
When? Between June 3 and June 5, 2024.
Where? Finance system, batch job #124.
Extent? 147 of 1,200 customers affected. 2.3% error rate.
Why it matters? Delayed payments, customer complaints, and potential audit risk.
Use this template to ensure every RCA begins with clarity. It prevents wasted time, ensures alignment, and sets the stage for effective analysis.
Frequently Asked Questions
How do I know if my problem statement is too broad?
If your investigation requires more than three weeks to complete, or involves five or more departments, you likely need to narrow the scope. Ask: “Is this one issue, or a cluster of issues?” Split it into smaller, focused problems.
Can I change the problem statement during the RCA?
Yes—but only if evidence shows the original was incorrect. Never change it to fit a desired outcome. Document the shift and why it happened. This maintains integrity and transparency.
What if multiple teams are affected?
Start with the most impacted area. Use the 80/20 rule: focus on the 20% of causes that explain 80% of the impact. Once resolved, address secondary issues.
How do I avoid blame when defining the problem?
Use neutral, system-focused language. Instead of “The team didn’t update the form,” say “The system rejected 42 forms due to missing validation fields.” Focus on process, not people.
Is it okay to include multiple issues in one RCA?
Only if they are causally related. If two issues have different root causes, separate them. Trying to solve both at once leads to confusion and incomplete solutions.
What if the data is incomplete or conflicting?
Be honest. State: “The data is limited. We are investigating under uncertainty, with the goal of validating assumptions.” Document gaps. Don’t speculate. Let the investigation proceed with transparency.
