Step 2: Understand the Root Causes-The Problem Behind the Problem

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 cost of nonconformance , which is the cost of all the things that go wrong and produce waste, scrap, and other excess costs. This cost includes rework , scrap, customer dissatisfaction, employee turnover , and other factors that are negative-value activities. As the company quantified its cost of nonquality, it suspected that production waste, or "scrap," was one of the largest contributors. This problem of excess scrap, then, is the next problem the company is trying to solve since it directly affects the larger problem of the cost of nonconformance, which in turn affects profitability .

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 fishbone diagram (see Figure 5-1) to identify the problems behind the problem. In our specific analysis, the company identified many sources that contributed to scrap. Each source was listed as one of the "bones" on the diagram.

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 comfort , it may be necessary to perform a detailed investigation of each contributing problem and to quantify its individual impact. This could vary from perhaps simple brainstorming by participants who have knowledge of the space to a small data collection project or, potentially , to a more rigorous experiment. In any case, the goal is to quantify the likely contribution of each root cause.

Addressing the Root Cause

Quality data demonstrates that many root causes are simply not worth fixing.

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 discovered that a single root cause ”"inaccurate sales orders" ”produced half of all scrap. If, in turn, the existing sales order system was found to be a poor example of legacy code, complete with a user -vicious interface and nonexistent online error handling, there may indeed be opportunity to cut scrap through development of new software.

Figure 5-2. Pareto chart of root causes

At this point, and only at this point, is the team justified in proposing a replacement for the existing sales order entry system. Finally, we have discovered a root cause problem that we can directly fix. Further, the cost justification for such a system is readily quantified by determining the estimated cost of development and the return on this investment through a reduction in scrap.

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

Element	Description
The problem of . . .	Inaccuracies in sales orders.
Affects . . .	Sales order personnel, customers, manufacturing, shipping, and customer service.
And results in . . .	Increased scrap, excessive handling costs, customer dissatisfaction, and decreased profitability.
Benefits of a solution . . .	That creates a new system to address the problem include Increased accuracy of sales orders at point of entry Improved reporting of sales data to management Ultimately, higher profitability

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 members of the project team so that everyone is working toward the same objective.