Category list

Step 1: Gain Agreement on the Problem Definition

The first step is to gain agreement on the definition of the problem to be solved . One of the simplest ways to gain this agreement is to simply write the problem down and see whether everyone agrees .

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 user describe the benefits provides additional contextual background on the real problem. In seeing the benefits from the customer's point of view, we also gain a better understanding of the stakeholder's view of the problem itself.

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 clients , an equipment manufacturer, was engaged in a major upgrade to its IS/IT system, which provided invoicing and financial reporting between the company and its dealers. The theme for the new program was to "improve dealer communications." As such, the team had embarked on a significant new system development effort.

Table 5-1. Problem Statement Format

Element	Description
The problem of . . .	Describe the problem.
Affects . . .	Identify stakeholders affected by the problem.
And results in . . .	Describe the impact of this problem on stakeholders and business activity.
Benefits of a solution . . .	Indicate the proposed solution and list a few key benefits.

An exercise in gaining agreement on the problem being solved was enlightening. The development team “defined solution envisioned a powerful new system that provided better financial reporting, improved invoice and statement formats, online parts ordering, and the like. And oh, by the way, the team eventually hoped to provide the capability for electronic funds transfer between the company and the dealer.

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 considered simply "nice to have." Needless to say, there was a substantial reorientation of the objectives of the new system, including a new problem definition that identified electronic funds transfer as the problem being solved. This reorientation also triggered the development of a different system architecture than had been envisioned, complete with the security capability consistent with the risks inherent in electronic banking.

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

graphics/05fig01.gif

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

graphics/05fig02.gif

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

graphics/05fig03.gif

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

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

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.

Buy on amazon.com >>

Leffingwell D., Widrig D.

<< Previous page

Table of contents

Next page >>