Technique: Root Cause Analysis

Root cause analysis is a technique used to assess the symptoms of a problem and find the ultimate cause. Often, problems are not clearly studied and inappropriate solutions are recommended. An analyst should not make a solution recommendation until he or she understands the underlying cause of the problem. Finding the root cause is the first step in solving a problem. The fishbone diagram (see Figure 7.1) is one visual technique for structuring root cause analysis. Major categories of possible causes are connected to the “backbone” of the fishbone diagram. Brainstorm in each category and document the causes in each category. Another technique for root cause analysis is the five whys.

Figure 7.1: Sample Fishbone Diagram

The Five Whys

The why question is one of the most valuable tools in the BA’s tool kit. It is used to help dig down to the root cause or underlying reason for a problem or opportunity. The why question can be used at any point in analysis work and is often used to help a business or IT stakeholder better explain their requirement. The five whys technique recommends that the analyst ask why in response to reasons five times to get to the root reason. Sometimes the root cause is found after only a couple of whys (GOAL/QPC, 2000).

Case in Point

“I want a red Ferrari!” Why? “Well, it looks good.” But why? “Because I would look good in it!” But why? “My friends would be very impressed if they saw me driving it.” Why?

“Because it is a very expensive car so, they would know that I must have sold a large number of books!” Why is that important? “If I sold a large number of books, then my book must have contained some really important information, so I must be very smart!” So—you want a Ferrari so that your friends will know that you are very smart? “When you put it that way, I don’t want the Ferrari so much anymore.”

Although the why question is very powerful and useful, you must use it carefully. It can be very annoying to keep asking the same question over and over again. When you ask the why question the first time, you need to listen carefully to the answer. Does this answer seem to be the true reason? In many cases, the question needs to be asked only once to get to the correct answer. If you feel there is more information, you need to elicit using different words (for example, “For what reason do you . . .?”) or pose a scenario question (“What would happen if . . . ?”). Varying the type and format of questions will be less tedious for stakeholders. Explain the technique to the stakeholders to help them understand your line of questioning.

Uses for the five whys include:

• Get to the true reason/objective for a project

• Get to the root cause of a problem

• Get to the true reason for a requirement

• Find the true essential business process (see Chapter 4)

The following two scenarios are projects where the monetary justification may not be initially obvious. The five whys will be used to get to the root cause of the project.

Scenario A

Project Statement of Purpose

The purpose of this project is to upgrade our XYZ payroll software from version 1.0.3 to version 1.1.0. This upgrade is being undertaken because the vendor of the XYZ software will discontinue support of version 1.0.3 at the end of the calendar year. All customized screens and reports that are currently available must be available in the new version. New functionality must be analyzed and considered. If any new functionality will be implemented, user procedures must be updated and users must be trained. (See Table 7.3 for the why questions and answers.)

Table 7.3: Five Whys for Scenario A
	Question	Answer
Why #1	Why do you think the organization is funding this project?	The software vendor is discontinuing support of the current version of the software.
Why #2	Why does it matter if the vendor discontinues support?	Because if the vendor does not support the soft-ware, it will have to be supported internally or another software package must be purchased and implemented.
Why #3	Why not maintain it internally?	No internal developers (current employees) are familiar with the underlying architecture or the development environment.
Why #4	Why not hire experienced developers or train internal developers in this technology?	Because developers with this experience are rare and very expensive. Training developers would also be expensive and time consuming.

Ah ha! It only took four whys to “find the money” in this case. Although undertaking this project is going to cost the organization some money, the expectation is that if the project is not funded, the organization will spend more money on developers. Thus the underlying justification for the project is to save costs.

Notice that the project is not being done to provide more functionality or better usability. Understanding and remembering that this project is focused on saving money are critical. It may be tempting to add functionality or improve usability “while we are making this change anyway,” but those tasks do not support the fundamental objective of the project. Always remember the reason for project initiation.

Teams sometimes try to add features and functionality that were not requested. The phrase gold plating was used by McConnell (1996) to describe this behavior. This is not a positive activity for an organization. Deliver on business needs as quickly and inexpensively as possible.

Scenario B

Project Statement of Purpose

Convert the customer database from the ABC DBMS to the XYZ DBMS. This conversion will not have any impact on the user interface to the application software. The change should be transparent to the software users. (See Table 7.4 for the why questions and answers.)

After asking why five times, the BA uncovers the true reason for the project: increase sales. “Buy more products” translates to receive more revenues, which translates tomore profit! If you go back to the statement of purpose, you won’t see anything about increasing sales, but this is the underlying business driver. You may consider revising the statement of purpose when you discover the true “why.”

Table 7.4: Five Whys for Scenario B
	Question	Answer
Why #1	Why do you think the organization is funding this project?	The XYZ DBMS is a more current technology.
Why #2	Why do we want to be using a more current technology?	Because we want our systems to be state-of-the-art.
Why #3	Why do we want our systems to be state-of-the-art?	Because we don’t want customers or outside competitors to think that we are using old technology.
Why #4	Why don’t we want customers or outside competitors to think that we are using old technology?	Because we want to be perceived as being on the leading edge of technology.
Why #5	Why do we want to be perceived as being on the leading edge of technology?	Because if we are perceived as having lead-ing-edge technology, our customers will buy more products from us.