Six Sigma For Dummies
Book image
Explore Book Buy On Amazon

The problem statement serves several purposes in a Six Sigma project. First, it significantly clarifies the current situation by specifically identifying the problem and its severity, location, and financial impact. It also serves as a great communication tool, helping to get buy-in and support from others. When problem statements are well written, people readily grasp and understand what you’re trying to accomplish.

Write the problem statement with the audience in mind. Keep in mind that you probably have to both convince management to provide resources to solve the problem and enlist team members to assist you; you don’t want to spend your precious time explaining over and over what you’re trying to accomplish.

A problem statement should be concise and include the following:

  • A brief description of the problem and the metric used to describe the problem

  • Where the problem is occurring by process name and location

  • The time frame over which the problem has been occurring

  • The size or magnitude of the problem

You must be careful to avoid under-writing a problem statement. A natural tendency is to write a problem statement too simplistically because you’re already familiar with the problem. If you’re going to recruit support and resources to solve your problem, others have to understand the context and the significance in order to support you.

Following are examples highlighting the depth and quantification of a Six Sigma project definition. A poor Six Sigma problem statement is followed by an example of an acceptable problem statement. First up: a statement with too little information:

Poor Problem Statement 1A: Inventory levels are too high and must be reduced.

How many times have you heard a problem statement like this one before? Yes, having high inventory levels is a problem, but a problem statement containing so little information significantly reduces your ability to take specific action, enlist support, and obtain improvement.

The problem statement must not include any indication or speculation about the cause of the problem or what actions will be taken to solve the problem. Never attempt to solve the problem or steer the solution at this stage. For example, the following problem statement is more detailed than Poor Problem Statement 1A, but it’s still, well, problematic:

Poor Problem Statement 1B: Having too few forklifts is making inventory levels too high.

By saying “Having too few forklifts” in Poor Problem Statement 1B, you’re purporting that you know what the solution is. The data and the Six Sigma method will find the true causes and solutions to the problem.

Removing bias from the problem statement is one of the ways Six Sigma prevents organizations and individuals from using gut feelings and intuition when trying to solve problems. Problem statements such as the following are effective at enlisting peoples’ attention, energy, and support:

Better Problem Statement 1: Inventory levels at the West Metro inventory storage process in Scottsdale are consuming space, taking up asset management time, and creating cash flow issues. Inventory levels are averaging 31.2 days, with a high of 45 days. These levels have exceeded the target of 25 days 95 percent of the time since January 2012. $250,000 could be saved per year if inventories were at the targeted level.

Look at the amount of information that is available in this example. You know where the problem is occurring, you know how long it has occurred, you know the magnitude of the problem, and you know how much it’s costing. Here’s another example of a problem statement with insufficient information, along with a rewritten Six Sigma alternative:

Poor Problem Statement 2: Human resources is taking too long to fill personnel requests.
Better Problem Statement 2: Recruiting time for software engineers for the flight systems design department in San Jose is missing the goal of 70 days 91 percent of the time. The average time to fill a request is 155 days in the human resources employee recruitment process over the past 15 months. This delay is adding costs of $145,000 per month in overtime, contractor labor, and rework costs.

And one more:

Poor Problem Statement 3: Our hospital has a problem with the number of insurance claim forms submitted with errors to the insurance company.

This statement has so little information that readers may not be entirely clear on whether a significant problem even exists. Nobody thinks that having claim forms with errors is good. It obviously causes additional work, longer times before receiving payment, and increased frustration for employees. But is this problem worthy of being worked on as stated? Maybe; maybe not. Other problems may be giving you worse headaches than this one.

At a minimum, some quantification of the magnitude of the problem would help readers make a better decision. Is the whole hospital having the problem, or is it confined to a particular group? Writing the problem statement to the standards of Six Sigma provides the level of information needed to make an informed decision:

Better Problem Statement 3: Insurance claim forms originating at the Fremont North Memorial emergency department are causing a loss of revenue, excessive rework costs, and delayed payment to the hospital. Forty-five percent of the claim forms have errors, with an average of 2.3 defects per form.
This problem has existed since claims processing was moved to Kansas City in March 2012. Billings could increase by $3.5 million per month, rework cost could be reduced by 50 percent, and an additional 1.3 percent of revenue could be recovered if errors were occurring less than 5 percent of the time. Achieving this level of performance would increase profits by $395,000 per year.

About This Article

This article is from the book:

About the book authors:

Craig Gygi is Executive VP of Operations at MasterControl, a leading company providing software and services for best practices in automating and connecting every stage of quality/regulatory compliance, through the entire product life cycle. He is an operations executive and internationally recognized Lean Six Sigma thought leader and practitioner. Bruce Williams is Vice President of Pegasystems, the world leader in business process management. He is a leading speaker and presenter on business and technology trends, and is co-author of Six Sigma Workbook for Dummies, Process Intelligence for Dummies, BPM Basics for Dummies and The Intelligent Guide to Enterprise BPM. Neil DeCarlo was President of DeCarlo Communications.

This article can be found in the category: