ISHIKAWA (CAUSE & EFFECT DIAGRAM) :

Problems arise on many projects. A proactive project manager should have a set of
problem resolution techniques that can be applied in different instances. One technique
for analyzing complex problems that appear to have many interrelated causes is called
a “cause and effect” diagram. Because of its shape, this technique is also called a
Fishbone Diagram. (Another name you might hear for this technique is an Ishikawa
Diagram. This is named for Professor Kaoru Ishikawa, a Japanese professor who
pioneered the diagram in 1943.) Some benefits of a Fishbone Diagram include:

* It allows various categories of causes to be explored.

The following description and examples show how the problem-solving technique works.

First, describe the problem on the far right side of the diagram. This may be the actual
problem or it may be a symptom — at this point you’re not exactly sure.

Draw a long horizontal arrow pointing to the box. This arrow will serve as the backbone
from which further major and minor causes will be categorized and related. (See Figure
A.)

Figure A

Identify potential causes and group them into major categories along the “bones” of the
Fishbone Diagram. You should brainstorm to identify the major categories; at this point,
you shouldn’t be concerned if there’s disagreement about whether a category holds the
potential cause — just put them all up. Make sure to leave enough space between the
major categories on the diagram so that you can add minor detailed causes in later.
(See Figure B.)
 Figure B

Continue to brainstorm the causes by looking at more detailed explanations for each of
the major cause categories identified above. The team should ask whether each
category is a cause, or if it is a symptom. If it’s a symptom, try to identify the more
detailed causes on slanted lines that hook up to the appropriate major category lines.
(See Figure C.)

Figure C

Sometimes, the detailed causes will have other, more granular causes coming off of
them. If so, connect additional lines to the detailed lines. Three levels of detail is usually
the practical limit for this diagram.

When you finish brainstorming major causes/symptoms and more detailed causes and
symptoms, the team can begin analyzing the information. Evaluate each major cause
and the potential detailed causes associated with it. Remember that the original list was
compiled by brainstorming where all ideas are included. Now, you must determine
which items seem more likely to be the cause (or one of the causes). Circle the items
that are most likely and need to be investigated further.

If there’s not an obvious consensus on the top areas to investigate, use some sort of
voting system to formally narrow down the top choices with the biggest chance of
success. For each item circled, discuss how the item impacts the problem.

Once you circle the causes that appear to be the most likely, you should create an
action plan for attacking these causes. This will most likely involve some high-level
actions and assigning the cause to a team member to be analyzed outside of the
meeting.

Remember that this technique is used for complex problems with multiple causes and
allows you to identify potential causes for the problem and determine which ones are
most likely to be resolved.
PARETO ANALYSIS

A few years ago, in the implementation of a major Enterprise Resource Planning (ERP)
implementation. The implementation team knew that there would be problems--
hundreds of them--and they were not disappointed. After the application went live, the
ERP helpdesk was inundated with problem calls. One way to resolve the problems was
simply to use a problem-by-problem approach. The team could have taken the first
problem and solved it, then the second, then the third, and so on. Since many of the
problem calls were related, this approach would have ultimately led to the resolution of
all the problems.

But the team decided that the approach was not the best use of their scarce time and
resources. It wouldn't have made sense to spend resources solving the first call if that
was the only occurrence of that problem. It made more sense to solve the problems
that were causing the most frequent errors. The team decided to use Pareto Analysis to
help make more intelligent decisions.

As mentioned, the support tickets were coming in fast and furious. The team attempted
to solve the problems they could, but they also set up a process to start counting and
categorizing each problem. Within a very short time, they started to notice the patterns.
The purpose of Pareto Analysis is to observe the problems and determine their
frequency of occurrence. This, in turn, gives you the information you need to prioritize
your effort to ensure you are spending your time where it will have the most positive
impact. Pareto Analysis is based on the classic 80/20 rule. That is, 20 percent
of the instances usually cause 80 percent of the problems.

Let's assume for our ERP implementation, that the team noticed that there were five
major categories of errors. (This example is simplified. On the actual ERP project, there
were dozens of distinct categories of errors.) Let's further say that the distribution of
the errors looked something like this:

* Error #1 -- 5 occurrences
* Error #2 -- 25 occurrences
* Error #3 -- 70 occurrences
* Error #4 -- 15 occurrences
* Error #5 -- 50 occurrences

Notice that this gives you important information. Even though there are five total
problems identified, it probably makes most sense to try to resolve Error #3
first, and then Error #5 second. If you solve these two problems, you have
actually solved over 70 percent of the total occurrences (120/165 total
errors). Under the first approach, the time you would have spent solving problem #1
first would have had a negligible impact on the total occurrences.

Of course, you might ask, "What if error #4 would only take an hour to solve?" In that
case, solve it by all means. It's low-hanging fruit. However, the Pareto Analysis now
gives you some facts to know what the impact is of solving that particular error.

You can see that Pareto Analysis doesn't help you resolve all problems. It works
especially well when you have multiple problems that can be counted and categorized.
The benefit of the technique is that it provides you with important information to
determine which problems to resolve first.