Guide: Is/Is Not Problem Definition
- Last Updated:
In Lean Six Sigma, clarity is important. Defining the scope of a problem accurately is key for effective resolution, and that’s where the “Is/Is Not” Problem Definition comes into play. Especially useful in complex scenarios, it hinges on two pivotal queries: “What exactly is the problem?” and “What exactly is it not?” Let’s delve into the systematic approach that sharpens problem-solving focus and simplifies complexity.
Table of Contents
What is the “Is/Is Not” Problem Definition?
The is/is Not problem definition is a method used for clarifying the scope of a problem. It is usually used in the define stage of DMAIC. The systematic approach helps to create a clear understanding of what is the actual problem and what is not the problem, which could be symptoms or non-issues. The is/is not method is particularly useful when approaching complex or ambiguous problems where the true root cause is not initially obvious.
Applying the method involves two activities:
Defining the Is: This involves capturing the attributes of the problem as it presents itself. Such as: What is happening? Where is it occurring? When does it occur? By answering these questions, you can create a detailed understanding of the problem.
Defining the Is Not: This is the same process, but asking for the opposite. You ask questions: where, when, and under what conditions does the problem not occur? By identifying the Is Not, you can clarify what is out of scope.
Why Use the “Is/Is Not” Problem Defintion?
The “Is/Is Not” problem definition can be used for many reasons, each contributing to a more efficient and effective problem-solving process:
By applying this method, you can ensure the team has a clear understanding of the problem and bring focus to the team on what is in scope and what is out of scope. Regularly, when I facilitate projects, the tendency is for the project team to go off on tangents and start talking about different machines, equipment, products, etc. By referring to the Is/Is Not definition, I can bring the team back to the focus of what is in scope by pointing out those areas that are out of the scope of this focus. Additionally, another scenario is that different team members can have different understandings of the problem if the problem definition is too vague.
By using the Is/is not method, you also make problems less complex. On particularly big and difficult projects, it can be confusing where to start, but by breaking down the problem of where it is and where it isn’t, for example, you can start to simplify the problem down into something more manageable.
How to Use the “Is/Is Not” Problem Definition
Step 1: Describe the Problem
The initial step in using this method is to first describe the problem in as much detail as possible. This goes beyond just stating what the problem is but also understanding what the symptoms are and the impact of the problem.
Key questions you can ask at this stage are:
- What exactly is the issue we’re observing?
- When do we notice the issue occurring?
- Where is the issue observed within the process or system?
- What are the symptoms and consequences of the problem?
This description should be clear, concise, and free of assumptions or solutions. It’s about what is known and observed.
Step 2: Identify the “Is”
The next step is to document the characteristics of the problem. This part of the process can usually include collecting data and facts about the problem.
We recommend using a template to break up and section this stage such as the one below.
Problem Definition – is / is not template
You should consider:
- What is happening? Describe the specific actions, behaviors, or outcomes that are considered problematic.
- Where is it happening? Identify the physical or organizational location where the problem occurs.
- When is it happening? Determine the time frame or conditions under which the problem arises.
- The extent of the problem: Measure how often the problem occurs and the magnitude of its impact.
These questions help in identifying the actual occurrences that need to be addressed.
Step 3: Identify the “Is Not”
The next step is to do the same with the is not stage and this time you are clarifying what is out of scope.
Key questions in this stage might include:
- What is not happening? Consider what one would expect to happen that is not happening.
- Where is it not happening? Determine locations where the problem could occur but doesn’t.
- When is it not happening? Identify times when the problem could arise but does not.
- Extent to which the problem is not observed: Evaluate the frequency or conditions under which the problem is absent.
This step is crucial for contrasting and narrowing down the root causes.
Step 4: Compare and Contrast
You now need to compare and contrast the information collected in steps 2 and 3. By analyzing the factors that are in scope and those that are not, patterns may start to emerge that can point to the potential causes or factors that are impacting the problem. It could also highlight any inconsistencies in the data or understanding by the team, which could need further investigation.
Step 5: Narrow Down the Scope
Using the understanding gained from the comparison, the next step is to begin to narrow down the scope of the problem. This may involve discarding certain aspects that are not central to the issue or focusing on areas that have the most significant impact. The goal is to create a refined view of the problem that can be addressed effectively.
Step 6: Formulate the Problem Statement
Finally, with a clear understanding of what the problem is and is not, you can formulate a problem statement. This statement should:
- Incorporate all relevant “Is” and “Is Not” factors.
- Be specific, measurable, and verifiable.
- Set the boundaries for what will (and will not) be addressed in the problem-solving process.
A well-defined problem statement is critical for the problem-solving process; it keeps the team’s efforts aligned and focused on addressing the right issues.
Example of “Is/Is Not” Problem Definition
A manufacturing company experiences unexpected machine downtime, which affects productivity and delivery times. The issue is reported to occur on Line 1.
“Is” Analysis:
- Machine Downtime on Line 1:
- What is happening? Machine stops functioning correctly, requiring unscheduled maintenance.
- Where is it happening? Specifically on Line 1, which handles a portion of the production process.
- When is it happening? The downtime is spiking during the third shift, which is from 11 PM to 7 AM.
- Extent of the problem: It is reported to occur most frequently when running Product A, perhaps indicating that the problem is related to the specific requirements or setup for this product.
“Is Not” Analysis:
- Downtime Not Occurring on Lines 2 and 3:
- What is not happening? The other lines do not experience the same issue, suggesting that the problem may be isolated to equipment, personnel, or processes unique to Line 1.
- Where is it not happening? On Lines 2 and 3, indicating that these lines might have different maintenance schedules, machinery, or operating procedures.
- When is it not happening? During the first and second shifts, indicating that shift-specific factors, such as operator expertise or machine load, could play a role.
- Extent to which the problem is not observed: There is no reported downtime when running Products B or C on any lines, which suggests that the problem might be related to the complexity, machine settings, or raw materials used for Product A.
Comparative Analysis:
By examining the “Is” and “Is Not” aspects side by side, the company can start to pinpoint potential causes for the downtime:
- Product-Specific Issues: Since downtime occurs with Product A and not B or C, the issue may be related to the machinery’s configuration, the complexity of Product A, or the raw materials used.
- Shift-Specific Issues: The fact that downtime spikes during the third shift raises questions about factors unique to this time period, such as lower staffing levels, operator fatigue, or end-of-day maintenance practices.
- Line-Specific Issues: The problem’s isolation to Line 1 suggests that there may be something about this line that is different from Lines 2 and 3 – it could be the age of the machinery, the maintenance routine, or even environmental factors like temperature or humidity, which might differ from area to area within the facility.
Problem Statement Formulation:
With this analysis, the company can create a focused problem statement:
“During the third shift, Line 1 experiences an increase in machine downtime, specifically when running Product A, leading to production delays. This issue does not occur during the first or second shifts, nor does it affect Lines 2 and 3 when running Products B or C.”
Next Steps:
With a well-defined problem statement, the company can now proceed to root cause analysis, where they might look into:
- The specific differences in the setup for Product A versus B and C.
- Environmental and operational conditions of Line 1 during the third shift.
- Training, expertise, and fatigue levels of third-shift staff compared to other shifts.
By applying the “Is/Is Not” problem definition method, the company effectively narrows down the scope of its investigation, thereby using its resources more efficiently to find a solution.
Conclusion
The “Is/Is Not” Problem Definition is more than just a problem-solving step; it’s a strategic compass that guides teams through the complex process of understanding the problem. By dissecting the issue into “Is” and “Is Not” components, teams can pinpoint the heart of the matter with surgical precision. The example of the manufacturing company with machine downtime on Line 1 illustrates this.
By distinguishing the specifics of the issue, the company could craft a focused problem statement, setting the stage for a targeted root cause analysis. This method isn’t just about solving what’s in front of us; it’s about ensuring that our solutions are not lost in the vast sea of potential problems, making our journey towards improvement both efficient and effective.
References
- Marin-Garcia, J.A., Garcia-Sabater, J.J., Garcia-Sabater, J.P. and Maheut, J., 2020. Protocol: Triple Diamond method for problem solving and design thinking. Rubric validation. WPOM-Working Papers on Operations Management, 11(2), pp.49-68.
Q: What is the primary purpose of the "Is/Is Not" problem definition technique?
A: The primary purpose is to clearly define the boundaries of a problem by distinguishing between what is known about the problem and what isn’t. This separation helps in focusing efforts on the actual issue and not on unrelated areas.
Q: Do I always need both the "Is" and "Is Not" columns?
A: Yes. While the “Is” column helps in identifying the characteristics of the problem, the “Is Not” column is equally important in setting the boundaries, ensuring that efforts aren’t directed towards unrelated areas.
Q: Can I use the "Is/Is Not" technique for any type of problem?
A: The technique is versatile and can be applied to a wide range of problems, from technical issues to organizational challenges. It’s especially useful for complex problems where the boundaries are not immediately clear.
Q: How is the "Is/Is Not" method different from other problem-solving techniques?
A: “Is/Is Not” specifically focuses on defining the problem. While other techniques might dive into root cause analysis or solution brainstorming, “Is/Is Not” ensures you have a clear understanding of the problem before moving forward.
Q: Can I use the "Is/Is Not" technique in combination with other methods?
A: Absolutely. In fact, it’s often beneficial to pair “Is/Is Not” with other techniques, such as the 5 Whys or Fishbone Diagram, for a comprehensive approach to problem-solving.
Q: How detailed should my "Is/Is Not" table be?
A: Aim for as much detail as possible, but ensure that the details are relevant and observable. The goal is to provide clarity, so unnecessary information can be counterproductive.
Q: What if the problem evolves or changes over time?
A: It’s essential to revisit and update the “Is/Is Not” table as new information emerges. The technique is dynamic, allowing for adjustments as you learn more about the problem.
Q: Is the "Is/Is Not" technique only for technical or business problems?
A: No. While often used in technical or business contexts, the technique can be applied to any situation where there’s a need to clearly define a problem, from personal challenges to community issues.
Author
Daniel Croft
Daniel Croft is a seasoned continuous improvement manager with a Black Belt in Lean Six Sigma. With over 10 years of real-world application experience across diverse sectors, Daniel has a passion for optimizing processes and fostering a culture of efficiency. He's not just a practitioner but also an avid learner, constantly seeking to expand his knowledge. Outside of his professional life, Daniel has a keen Investing, statistics and knowledge-sharing, which led him to create the website learnleansigma.com, a platform dedicated to Lean Six Sigma and process improvement insights.
Download Template
Free Lean Six Sigma Templates
Improve your Lean Six Sigma projects with our free templates. They're designed to make implementation and management easier, helping you achieve better results.
