The Problem Statement

Problem Solving always begins with a well written problem statement. Always. You want to remove any confusion and ambiguity about the issue you face by describing with detail exactly what occurred.

This keeps your team focused precisely on your issue. It will also help your teams consistently resolve the concerns within your organization and keep the dreaded "scope creep" at bay.

Your problem statement should never detail a cause for the issue at hand. After all, if you knew the cause, you wouldn't need to create this statement. You wouldn't have a need for this methodology. You'd take action to eliminate the cause. One last tip... remember that it is unlikely that an individual caused your issue. It is more likely that the issue is a result of a poor process. Deming has determined that 85% of issues are a result of a poorly defined or inadequate processes and only 15% of issues are truly operator error!

Poorly Written Examples-

The widget is too long.

There are too many errors in our reports.

Our delivery time is horrible.

These examples do not adequately detail the depth of the problem. All 3 are a decent beginning, but more information is required before your team jumps in to find out what happened. The addition of how your company failed to meet requirements is a must in problem statements.

Good Examples-

The widget exceeds the customer requirement of 38cm (defines the requirement and how the organization failed to meet it).

The monthly quality reports (defines where the issue is located) contain more than 2 errors on average, greater than the 0 errors expected (defines the internal requirement)

On-Time Delivery has averaged 92%, less than the target of 98.5% (again, this defines the failure to meet the requirement).

Better Examples-

The last 10 production runs (defines when the issue occurs) show the widget measured an average of 41cm (the issue), which exceeds the customer requirement of 38cm +/- 2cm.

The past 2 months (when) the quality reports contain more than 2 errors on average, greater than the 0 errors expected.

On-Time Delivery to Customer X (where the issue occurs) has been only 92% for the last 4 months, less than the required 98.5%.

These better examples give your teams the detail necessary to investigate the issue, and define where your team should focus its resources. For example, there’s no need to search beyond the last 10 production runs in the widget investigation. The team’s preliminary findings indicate that the issue does not exist prior to those runs.