Locked lesson.

Upgrade

About this lesson

There are numerous tools to assist the Lean Six Sigma team in the creation of the problem statement. Different tools work better in different applications, but all of them help the Lean Six Sigma team focus on the root cause problems and not chase symptoms.

Exercise files

Download this lesson’s related exercise files.

Problem Definition Tools.docx
60.6 KB Problem Definition Tools - Solution.docx
237.7 KB

Quick reference

Problem Definition Tools

There are numerous tools to assist the Lean Six Sigma team in the creation of the problem statement. Different tools work better in different applications, but all of them help the Lean Six Sigma team focus on the root cause of problems and not chase symptoms.

When to use

The problem definition techniques are used during the Measure phase to develop the problem statement and assist in root cause identification.

Instructions

The four techniques listed below are excellent in a team brainstorming environment. They are all easy to understand and easy to apply, yet can quickly lead to very valuable insights concerning the problem and the potential root causes. I normally use several techniques, selecting them based on the nature of the problem and the team I am working with.

Cause and Effect Diagram

This is a graphical technique that shows all the root cause categories that may be contributing to a problem. The high-level problem is placed at one end of a horizontal line. The categories are drawn as branches off of the horizontal line. Sub-categories are drawn as branches from the category lines. This technique can be used to track which categories and sub-categories have been measured and the results of that measurement. This technique is also known as the Fishbone diagram and the Ishikawa diagram.

Six M’s

The six M’s are a mnemonic for six potential categories of root causes; each category begins with the letter M. I often use these six categories for my major branches on a cause and effect diagram. This technique helps a team look for all potential root causes and not jump on the first likely cause they find while overlooking others that are significant. The six M’s are: Materials, Manpower, Machines, Methods, Measurements, and Mother Nature.

Why’s

The Why technique is used to move from symptoms to root causes. It's as simple as asking Why multiple times. The technique assumes that there is an underlying cause for each problem symptom. That underlying cause had its own underlying cause. It normally takes anywhere from four to eight Why questions to reach a root cause. This technique is very helpful when trying to understand an unexpected problem.

Is / Is Not

This technique is a series of declarative statements about the problem. First, a statement about something that is associated or related to the problem followed by something that is not associated or related to the problem. After the first statement is made, an additional statement is added to further explain something associated with the occurrence of the problem and the Is Not statement is expanded to further clarify what is not associated. This continues for several more statements until there is a clear boundary between when or how the problem occurs and when it does not. This technique is very useful with inconsistent or intermittent problems.

Hints & tips

  • Use multiple techniques. If one is helping your team gain understanding of the problem, move on to the next technique.
  • The techniques often work best when someone is acting as a facilitator. This is a good time for your Black Belt to assist the team.
  • Save the results of your analysis using these tools, they are great reference points if the team gets stuck in the Analyze phase.
Login to download
  • 00:05 Hi, I'm Ray Sheen, and we've already talked about the problem statement.
  • 00:06 And there are several techniques that I have found to be very helpful during
  • 00:11 the measure phase to understand the problem and prepare the problem statement.
  • 00:17 The first technique is the cause and effect diagram,
  • 00:21 sometimes referred to as the Fishbone diagram or the Ishikawa diagram.
  • 00:25 This is a visual tool to aid in brainstorming the potential contributing
  • 00:28 factors to the problem.
  • 00:30 I use this with every project.
  • 00:32 The other tools that I will mention are complimentary, and I normally use one or
  • 00:37 two of them with the cause and effect diagram.
  • 00:39 The great thing about this tool, is that it organizes your thoughts and
  • 00:43 documents the work you are doing.
  • 00:45 You can add multiple branches based upon what your team has
  • 00:49 discovered in the measure phase.
  • 00:51 As data rules something in or
  • 00:52 something out of the analysis, the branch is terminated or extended.
  • 00:57 Start with a high level statement of the problem as provided by the stakeholders
  • 01:02 in the define phase and then we draw the backbone of the diagram.
  • 01:07 Then as you investigate and collect data,
  • 01:09 you can identify the attributes that are contributing to the problem.
  • 01:13 I will start with an initial brainstorm set of these to measure.
  • 01:16 These are the major branches.
  • 01:18 We measure those and if there is no data to support that branch, we terminate it.
  • 01:22 But if there is a lot of data supporting the branch,
  • 01:25 we break it into sub-branches and gather more data to get better insight.
  • 01:30 Once you have a handle on the basic data, you can write the problem statement.
  • 01:34 If the problem was due to a unique or special cause,
  • 01:37 this technique will often expose that, and
  • 01:39 you can move quickly through the analyze phase to the improve phase.
  • 01:44 If there's no special cause, just lots of negative impacts happening from normal day
  • 01:48 to day stuff, you'll at least have identified many of the parameters that
  • 01:52 you'll be studying in the analyze phase.
  • 01:55 The next technique is the why's technique, sometimes referred to as the five
  • 02:00 why's because the team is to ask why question at least five times.
  • 02:05 This is a great approach for moving from symptoms to likely root causes.
  • 02:09 Just keep in mind, whatever you come up with for
  • 02:12 your answer to the why question you will still need to confirm with data.
  • 02:16 In this technique, you start with that high level problem from the define phase.
  • 02:20 And then ask the question, well, why did that happen?
  • 02:23 You check all the potential answers to that question for data and if data
  • 02:27 supports an answer as being at least part of the problem, you ask why again.
  • 02:32 This continues multiple times until you reach root cause or causes.
  • 02:36 There is an example on the box at the right.
  • 02:39 We start with the symptom, our suppliers are delivering late, why?
  • 02:43 They don't have sufficiently time to fill out our orders.
  • 02:46 Why don't they have the lead time?
  • 02:48 Purchasing did not place the order on time.
  • 02:51 Well, why was purchasing delayed?
  • 02:52 Purchasing hadn't received approvals from other organizations.
  • 02:55 Why were the other organizations holding things up?
  • 02:59 Other organizations didn't know that they were delaying purchasing.
  • 03:02 Why didn't they know that they were causing the delays?
  • 03:05 The Purchase Order Tracking System does not involve three of
  • 03:08 the six organizations needed for approval.
  • 03:12 Next is the M's category.
  • 03:15 The M's categories are possible causes for a problem.
  • 03:18 Many problems have multiple causes.
  • 03:20 The M's help us to identify all of them not just jumping to fix one only to find
  • 03:25 that there are still five more.
  • 03:27 Now there are several lists of M's, the 5 M's, the 6 M's, the 7 M's.
  • 03:32 Since the IASSC likes to use the 6 M's, we will use that one.
  • 03:36 The first M is materials and
  • 03:38 these are potential problems with the materials used in the process.
  • 03:42 Another M is machines, the equipment used in the process.
  • 03:46 This includes any tooling or equipment, fixtures or systems and
  • 03:49 the software that goes with it.
  • 03:52 Manpower is another M.
  • 03:54 This addresses the people or staffing and the skills and training that they have.
  • 03:58 Methods are the procedures that are followed both formal and informal.
  • 04:02 It would also include any forms or checklists that are used.
  • 04:05 Measurements is the measurement system.
  • 04:08 Are we measuring the wrong things?
  • 04:09 Are we measuring anything?
  • 04:11 Are the measurements timely and who sees the results?
  • 04:14 Finally, there's the M for Mother Nature.
  • 04:17 These are any environmental effects that may impact the process performance or
  • 04:21 create the problems.
  • 04:23 I like to start the major branches of my cause and effect diagram with the M
  • 04:27 categories, and then use the why questions to expand those branches.
  • 04:32 The last tool I want to discuss is the is, is not assessment.
  • 04:36 This technique works really well with sticky or complex problems that seem to
  • 04:41 have numerous unrelated factors impacting the process performance.
  • 04:45 It helps to clarify the problem boundaries and to focus the team.
  • 04:49 It is also very helpful if the data seems to be inconsistent or intermittent.
  • 04:54 Let me talk us through this process.
  • 04:57 You start with a declarative statement about when or how problem is occurring.
  • 05:01 Then you make another statement about when or how it is not occurring.
  • 05:06 Add details to the first statement to try to narrow it down a bit.
  • 05:09 Add or expand the second statement to fill in where the problem doesn't occur.
  • 05:14 Continue until the boundaries are clear.
  • 05:16 I have another example shown in the box on the right of your screen.
  • 05:20 The problem occurs on product line XYZ.
  • 05:23 The problem does not occur on all the other product lines.
  • 05:27 The problem occurs on product line XYZ on the second shift.
  • 05:31 The problem does not occur on first or third shift.
  • 05:34 The problem occurs on product line XYZ on the second shift during the last weekend
  • 05:38 of the month.
  • 05:40 The problem does not occur on the first three weekends of the month.
  • 05:43 Now, I have been able to narrow down an intermittent problem and
  • 05:47 can focus our data collection to understand what is actually happening
  • 05:50 during that last weekend of the month.
  • 05:55 I love these techniques.
  • 05:56 They're simple and easy to use and you don't need to go buy software or
  • 06:00 take some three day course to learn them.
  • 06:02 Most of all, they work.
  • 06:04 Use any or all of them to help you prepare your problem statement and
  • 06:08 guide your data collection.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course