Step 1: Gain Agreement on the Problem Definition
The first step is to gain agreement on the definition of the problem to be
As part of this process, it is often helpful to understand some of the benefits of a proposed solution, being careful to make certain that the benefits are described in the terms provided by the customers/users. Having the
The Problem Statement
You may find it helpful to write your problem down in a standardized format (Table 5-1). Filling the table in for your application is a simple technique to help ensure that all stakeholders on your project are working toward the same goal.
Spending the time it takes to gain agreement on the problem being solved may seem like a small and insignificant step, and in most circumstances it is. But sometimes it is not. For example, one of our
Table 5-1. Problem Statement Format
An exercise in gaining agreement on the problem being solved was enlightening. The development team “defined solution
During the problem statement exercise, company management had the opportunity to provide input. Management's vision was substantially different: the primary goal of the new system was to
provide electronic funds transfer that would improve the cash flow of the company
. After a raucous discussion, it became clear that the first-order problem to be addressed by the new system was electronic funds transfer; other dealer communication features were
Step 2: Understand the Root Causes ”The Problem Behind the Problem
Once you have an understanding of the larger problem, your team can use a variety of techniques to gain an understanding of its causes. One such technique is root cause analysis , which is a systematic way of uncovering the root, or underlying, cause of an identified problem or a symptom of a problem.
For example, consider a real-world example: a mail-order catalog company, which we'll call GoodsAreUs, manufactures and sells a variety of inexpensive, miscellaneous items for home and personal use. As the company addresses the problem of insufficient profitability, it uses total quality management (TQM) techniques for problem solving learned in its quality program. Based on this experience, the company quickly focused on its
But we are not yet done, for we must still understand the root cause, or the problem behind the problem in scrap, so we can discover a problem that we can directly fix. To do so, it is necessary to determine what factors contribute to the scrap problem. TQM teaches us the use of the
(see Figure 5-1) to identify the problems behind the problem. In our specific analysis, the company identified many sources that
Figure 5-1. Fishbone diagram of root causes
OK, so how do you determine the root causes? Well, it just depends. In many cases, it's a simple matter of asking the people directly involved what they think the root cause is. It's amazing how much people do know about the problem behind the problem; it's just that no one ”by which we usually mean management ”had taken the time to ask them before. So, ask them, and then ask them again .
If the problem is more serious and simply asking those affected doesn't create a sense of
Addressing the Root Cause
Of course, the engineer in all of us would like to fix all of the root causes on the "bones" of the diagram. This seems like the right thing to do. But is it? Often, it is not ; quality data routinely shows that a number of root causes are simply not worth fixing , as the cost of the fix exceeds the cost of the problem. How do you know which ones to fix? You must determine the materiality, or contribution, of each root cause. The results of this investigation can be plotted as a Pareto chart or a simple histogram that visually exposes the real culprits.
Back to our example. Let's suppose that the data gathering produced the results shown in Figure 5-2. As you can see, the team
Figure 5-2. Pareto chart of root causes
At this point, and
only at this point, is the team justified in
Lest we lose the forest for the trees, however, let's look at the problem analysis sequence that got us here (Figure 5-3).
Figure 5-3. Applying different problem analysis techniques as a problem unfolds
A further fishbone analysis could then be used to determine what specific types of errors contribute to the inaccurate sales order problem. This new, more detailed data can then be used to define the features of the software system to address those errors. For our purposes, however, we can conclude our analysis by agreeing that a replacement of the sales order system can be at least a partial solution to the problem of too much scrap.
Once we have identified inaccurate sales orders as a root cause of a problem worth solving, we can create a problem statement for the sales order entry problem, as seen in Table 5-2.
Table 5-2. Sales Order Problem Statement
Once written, the problem statement can be circulated to the stakeholders for comment and feedback. When finalized, the problem statement communicates the mission to all