Retired course

This course has been retired and is no longer supported.

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 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 of 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 waste resources, 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 upon the impact from the customer 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 was 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.
  • 00:06 And it's now time to move to the Measure phase.
  • 00:08 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:20 But during the Measure phase,
  • 00:21 you will be collecting information that will help you to clarify the problem.
  • 00:25 The problem statement is one of the primary items reviewed with
  • 00:28 your stakeholders at the end of the Measure phase.
  • 00:31 As we develop the problem statement,
  • 00:33 we need to understand how big the problem really is, the magnitude.
  • 00:37 On Lean Six Sigma projects, we will do this with data, not guesswork or
  • 00:42 intuition.
  • 00:43 That means we need to measure the problem.
  • 00:45 We gather data about the problem conditions.
  • 00:48 Often during the Define phase, we will have assumed a problem.
  • 00:52 This helps us to set the boundaries.
  • 00:54 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:02 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 bare this out.
  • 01:09 However, fixing a non problem is definitely a waste of effort and
  • 01:13 many times it makes things even worse.
  • 01:15 That is why we want to collect plenty of data, so
  • 01:18 that there is no question about the problem.
  • 01:20 This is also why I don't recommend writing a problem statement
  • 01:24 during the Define phase or even early in the Measure phase.
  • 01:27 I wanna make sure I fix the real problem and not an assumed problem.
  • 01:32 As in aside, that is one of the problems I have seen with
  • 01:35 some of the other process improvement and problem solving methodologies.
  • 01:39 The problem statement is written before there's any data to tell us what
  • 01:42 the problem truly is.
  • 01:44 The team then waste countless hours chasing the wrong thing.
  • 01:48 So let's talk for a minute about what goes into a problem statement.
  • 01:52 As the name implies, it is a statement of what is wrong, the defect,
  • 01:56 the complaint, the problem.
  • 01:58 Make sure when creating your problem statement that you are describing
  • 02:01 the problem from the customer point of view.
  • 02:04 Our goal is to increase customer value, so
  • 02:06 we need to fix the problem the customer experiences.
  • 02:09 The description needs to be stating the facts that you have actually measured.
  • 02:14 A problem description will often have the root cause or causes explicitly or
  • 02:18 at least implicitly stated.
  • 02:20 And this is appropriate when it is a special cause meaning some unusual or
  • 02:24 totally unpredictable event was the cause.
  • 02:28 However, if there isn't that clear event causing the problem,
  • 02:31 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
  • 02:37 to determine the root cause or causes.
  • 02:40 The problem statement will drive the work and the rest of the project, so
  • 02:43 I want to get it right.
  • 02:45 Don't rush, collect your data and let it lead you to the problem.
  • 02:49 Remember I said that,
  • 02:50 we would review the problem statement with the stakeholders at the end of the phase.
  • 02:55 That is when we finally tell them what needs to be fixed.
  • 02:58 I mentioned it in earlier module but this is worth repeating again.
  • 03:02 Lean Six Sigma projects are different from most other projects.
  • 03:05 There is not a clear statement of work and
  • 03:07 scope definition at the beginning of a Lean Six Sigma project.
  • 03:11 It isn't until the end of the Measure phase that we know what the problem is,
  • 03:15 and it won't be until the end of the Analysis phase
  • 03:18 that we know the root cause of that problem.
  • 03:21 So now that we can write the problem statement,
  • 03:23 we can also set a measurable goal for project success.
  • 03:27 We know the magnitude of the problem, so it's possible to make a realistic estimate
  • 03:31 concerning how much improvement is possible.
  • 03:35 You maybe getting the idea that the problem statement is more than a little
  • 03:38 six word statement, you are right.
  • 03:41 They're maybe different formats for problem statements and
  • 03:43 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:49 It should address the following questions.
  • 03:52 What is the product or
  • 03:52 the service performance result that is not meeting the customer expectations?
  • 03:57 What is the complaint?
  • 03:58 This question you probably knew by the end of the Define phase.
  • 04:02 When does it occur and where does it occur?
  • 04:05 You will need some data from the Measure phase to answer this.
  • 04:09 Does it happen all the time or only part of the time?
  • 04:12 Does it occur everywhere the process is used or only in certain locations or
  • 04:16 situations?
  • 04:18 And who is affected?
  • 04:19 Which customers?
  • 04:20 Which operators?
  • 04:21 Again, all or some, and
  • 04:23 if only some, do you know the characteristics of those who are affected?
  • 04:27 Also, if there's some obvious characteristics that accompany the problem
  • 04:30 occurrence, include them.
  • 04:33 You may not know all of the characteristics and
  • 04:34 in fact, we'll try to find them out in the Analyze phase.
  • 04:38 But if something is already known, include it.
  • 04:44 A problem statement is not an optional tool, you need one,
  • 04:47 otherwise you don't know what it is to analyze and improve.
  • 04:51 Take the time to get it right and we'll 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