Locked lesson.

Upgrade

About this lesson

The problem statement clarifies the goals and activities of the Lean Six Sigma project by specifying the issue to be resolved. It's an excellent communication tool for the team to use with stakeholders.

Exercise files

Download this lesson’s related exercise files.

Problem Statement.docx
60.8 KB Problem Statement - Solution.docx
61.2 KB

Quick reference

Problem Statement

The problem statement clarifies the goals and activities of the Lean Six Sigma project by specifying the issue that's to be resolved. It's an excellent communication tool for the team to use with stakeholders.

When to use

Every Lean Six Sigma project must have a problem statement. It is completed during the Measure phase of a Lean Six Sigma project and is referred to again when reporting results at the end of the project.

Instructions

The problem statement describes the problem from the customer's viewpoint. However, the Lean Six Sigma problem statement does not rely on the voice of the customer comments, rather it collects data and describes the impact of the problem on the customer using the real data of what happened. By using real data, the team and stakeholders are less likely to assume what the core problem or solution is. Fixing the wrong problem not only wastes resources, but it can often make the real problem even worse.

The next module will provide a number of tools for gathering the data used to write the problem statement. In this module, the focus is on the result – the problem statement. There is no one right way to write a statement. I have seen many formats which were quite good. The key is that several questions are answered, and these answers must be from the perspective of the process customer or user, not process operator.

  • What is the product or service performance result that is not meeting expectations?
  • When does it typically occur?
  • Where does it typically occur?
  • Who is affected?
  • What contributing factors are present – how does the problem manifest itself?

You may not have answers yet for the last question and that is acceptable. The Analyze phase of the Lean Six Sigma project will provide those answers. But sometimes, if the problem was due to a special or unusual cause, the contributing factors, or even the root cause(s) are obvious.

Make sure that your problem statement is fact-based with no embedded assumptions. Also, make sure it's based on the impact from the customer's perspective. Finally, the problem should be stated with a measurable component. When the Lean Six Sigma project nears completion, the team will need to demonstrate the impact of their improvement. It's much easier to explain impact when there is a measurable problem described in the problem statement.

Hints & tips

  • Take your time and don’t rush the writing of the problem statement. A poorly written statement, or worse yet, one that describes a non-problem, will waste the team’s time and effort and not satisfy the customer.
  • Don’t jump to conclusions, use facts.
Login to download
  • 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.

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

Gift this course