Problem Statement

Quick reference

• 00:05 Hi, I'm Ray Sheen and it's now time to move to the measure phase.
• 00:09 The first thing to address here is writing the problem statement.
• 00:13 >> Now writing the problem statement may take a little time and
• 00:17 you may have to refine it several times.
• 00:19 But during the measure phase,
• 00:20 you'll be collecting information that will help you to clarify the problem.
• 00:24 The problem statement is one of the primary items reviewed with your
• 00:27 stakeholders at the end of the measure phase.
• 00:30 As we develop the problem statement,
• 00:32 we need to understand how big the problem really is.
• 00:35 The magnitude. On Lean Six Sigma projects, we'll do this with data,
• 00:39 not guess work or intuition.
• 00:42 That means we need to measure the problem.
• 00:44 We gather data about the problem conditions.
• 00:47 Often during the define phase, we will have assumed a problem.
• 00:51 This helps us to set the boundaries.
• 00:53 Now we collect data to see if our assumptions were correct.
• 00:57 If the data sends us in a different direction, we go that direction.
• 01:01 This can be a challenge with stakeholders sometimes when they are firmly convinced
• 01:05 that they know what the problem is and the data doesn't bear this out.
• 01:09 However, fixing a non-problem is definitely a waste of effort and
• 01:12 many times it makes things even worse.
• 01:14 That is why we want to collect plenty of data so
• 01:17 that there is no question about the problem.
• 01:20 This is also Why I don't recommend writing a problem statement during
• 01:23 the define phase, or even early in the measure phase.
• 01:27 I want to make sure I fix the real problem and not an assumed problem.
• 01:31 As an aside, that is one of the problems I've seen with some of the other process
• 01:35 improvement and problem solving methodologies.
• 01:38 The problem statement is written before there's any day Data to tell us
• 01:41 what the problem truly is.
• 01:43 The team then wastes countless hours chasing the wrong thing.
• 01:47 So let's talk for a minute about what goes into a problem statement.
• 01:51 As the name implies, it is a statement of what is wrong.
• 01:54 The defect the complaint, the problem.
• 01:57 Make sure when creating your problem statement that you are describing
• 02:00 the Problem from the customer point of view.
• 02:02 Our goal is to increase customer value.
• 02:05 So we need to fix the problem the customer experiences.
• 02:08 The description needs to be stating the facts that you have actually measured.
• 02:13 The problem description will often have the root cause or
• 02:16 causes explicitly or at least implicitly stated.
• 02:19 And this is appropriate when it is a special cause, meaning some unusual or
• 02:24 totally unpredictable event was the cause.
• 02:27 However, if there isn't that clear event causing the problem,
• 02:30 don't put one into the problem statement.
• 02:33 That just means that we will need to do a little more work in the analysis phase to
• 02:37 determine the root cause or causes.
• 02:39 The problem statement.
• 02:40 Payment will drive the work and the rest of the project.
• 02:42 So we want to get it right.
• 02:44 Don't rush, collect your data and let it lead you to the problem.
• 02:48 Remember, I said that we would review the problem statement with
• 02:51 the stakeholders at the end of the phase.
• 02:54 That is when we finally tell them what needs to be fixed.
• 02:57 I mentioned in an earlier module, but this is worth repeating again,
• 03:01 Lean Six Sigma projects are different from most other projects.
• 03:04 There is not a clear statement of work and
• 03:07 scope definition at the beginning of a Lean Six Sigma project.
• 03:10 It isn't until the end of the measure phase that we know what the problem is.
• 03:14 And won't be until the end of the analysis phase that we know the root cause of
• 03:19 that problem, we can write the problem statement.
• 03:22 We can also set a measurable goal for project success.
• 03:26 We know the magnitude of the problem, so it is possible to
• 03:29 make a realistic estimate concerning how much improvement is possible.
• 03:34 You may be getting the idea that the problem statement is more than a little
• 03:37 six-word statement.
• 03:39 You are right.
• 03:40 There are many different Formats for problem statements and
• 03:42 most of them are quite good.
• 03:44 The key is not the format rather it is what is said in the problem statement,
• 03:48 it should address the following questions.
• 03:51 What is the product or service performance results?
• 03:53 That is not meeting the customer expectation.
• 03:56 What is the complaint?
• 03:58 This question you probably knew by the end of the Define Phase When does it occur and
• 04:02 where does it occur?
• 04:04 You'll need some data from the measure phase to answer this.
• 04:08 Does it happen all the time or only part of the time?
• 04:11 Does it occur everywhere the process is used or only in certain locations or
• 04:15 situations?
• 04:17 And who is affected, which customers, which operators?
• 04:20 Again, All or some, and if only some,
• 04:23 do you know the characteristics of those who are affected?
• 04:26 Also, if there are some obvious characteristics that accompany the problem
• 04:30 occurrence, include them.
• 04:32 You may not know all of the characteristics, and in fact,
• 04:35 we will try to find them all in the analyze phase.
• 04:37 But if something is already known, include it.
• 04:41 >> A problem statement is not an optional tool.
• 04:44 You need one.
• 04:45 Otherwise, you don't know what it is to analyze and improve.
• 04:48 Take the time to get it right, and it will help you manage your project.

Lesson notes are only available for subscribers.