qualityg says ...: Root Cause Analysis - Part III

Root Cause Analysis - Part III

Breaking Down and Defining the Four Phases -
Preparation, Analysis, Verification and Implementation

Root Cause Analysis - Part I - Introduction http://qualityg.blogspot.com/2006/07/quality-tooltechnique-root-cause.html

Planning a Root Cause Session - Part II
http://qualityg.blogspot.com/2007/05/root-cause-analysi-part-ii-planning.html

Part III - Breaking Down and Defining the Four Phases

PHASE I - PREPARATION

Before the group actually conducts a Root Cause Analysis Session, the following activities must be done:

Schedule a half or full day session with all major process players in attendance.

Reserve a room that is large enough for group movement and is equipped for hanging charts, easels, etc.

Set up room the previous afternoon with the following

- Post Agenda and any instructional overview material
- Hang Process Flow Map (must be done prior to meeting)
- Hang Associated Charts - Pareto, Checksheet, Histogram, etc.
- Post Problem Statement (see below for example)
- Set out appropriate supplies - pencils, stickys, name cards, tape, markers, handouts, etc.
- Hang blank easel sheets for each major process of the Process Flow Map
- Post Action Plan and Probable Solutions Matrix

PROBLEM/OPPORTUNITY STATEMENT

I. Identify the Effect (output/customer pain) of the process and create an opportunity/problem statement from previously collected data and information.

II. Verify the problem/opportunity statement meets the following criteria:

DESCRIPTION: This is a technique for probing an area of opportunity in order to arrive at the clearest possible definition for increasing customer satisfaction. A good problem/opportunity statement describes, in specific, concrete terms, what the data has revealed.

INPUTS: - Process Map(s)
- Data Collection Forms Results
- Pareto Analysis Results
- Historical Attribute/Variable Data(if available, if not collect at
at least a months worth for reference only)
- SME Subjective Data Results (historical)

PROCESS: Evaluate the effectiveness of a proposed problem/opportunity
statement by considering the following:

- What is the effect (outcome/customer pain)?
- Is the statement measurable?
- Is it specific?
- What is the gap between "what is" and "what should be"?
- Is it not asking a question?
- Why is this an opportunity to increase customer satisfaction?

OUTPUT: Creates Effect that is used as input for Diagnostic/Root Cause Analysis. If
above steps not completed do not go any further.

Note: If someone tries to convince you that a Root Cause Diagram is required to capture analysis pack up and go home because they do not know what ther are doing. The Root Cause Diagram was originally created as a presentation diagram, not for the actual excercise. Sadly, it was (and still does) was introduced from American Consultants.

III. Develop Main Categories for your charts (not root cause charts) by one of the following methods:

Note: Unfortunately the 6Ms and 5Ps is/was introduced by American Consultants that really serve no purpose except to widen the scope of your Problem Statement and allow people who know nothing of the process in question a chance to screw things up!

6 M's (Mfg) 5 P's (Service)
Methods Policy
Money People
Manpower Price
Materials Procedures
Machinery Plant
Misc

The most practical and best method to use is a critical event process flowchart. That is, break down an existing process flowchart or create a critical event process flow by major events/steps or categories. This will help identify and prioritize the first category to tackle when starting the Root Cause Analysis. The biggest payback to this method is that it forces the group to focus on the process and not on people or training issues. Training has often proved not to be a root cause but rather a countermeasure to a root cause as to why training is not effective or what causes an employee to not be trained consistently according to a standardized process.

PHASE II - ANALYSIS

IV. Brainstorm Probable Causes to the Problem Statement using the following process (cover with group):

Reminder: "Brainstorming is not the answer."

GENERATION PHASE

1) Clearly state the opportunity/problem statement to be analyzed in specific, precise terms and make it visible on the chart with one of the Process Flow Categories.

2) Select a recorder to list ideas for each process flow category one idea at a time on a blank easel page.

3) Each group member takes a turn, in sequence, around the room. Use the stickys provided to record your probable causes (not guesses) when it's not your turn.

4) Present one thought/idea at a time. The facilitator may probe for additional information (ask "WHY") by using the "Process Flow Categories and Probing Questions"

5) Build on ideas of others, but do not interrupt or finish others statements.

6) Do not criticize or discuss any probable causes during this phase.

7) It's "OK" to pass, you will get another chance.

CLARIFICATION PHASE

8) Group members review the list to make sure everyone understands all of the items and to eliminate duplications.

9) Do not discuss ideas during this phase, discussion will take place during the Evaluation Phase.

EVALUATION PHASE

10) Group reviews and discusses the problems/causes to eliminate irrelevancies or issues that are beyond the scope of the Problem Statement. Issues with potential opportunities for improvement beyond the scope should be tossed not parked on another easel (stay focused).

11) Check that items brainstormed are indeed causes and not solutions. If solutions are found, move them to the Probable Solutions or Countermeasure Matrix.

V. Identify the Most Probable Causes

Ideally this should be done after an incubation period, thereby allowing for more accurate analysis of the ideas. Most RCA Teams will try to do the RC Session in 1- 3 days. This is never the cast even if you brought excellent data and information. If you have done the Analysis correctly to this point you will need additional data and information. If the time period for gathering data is too long or not possinle then blame the Process Owner because way back at the beginning someone chose this Problem Statement based on Gut (out of control conditions) feelings instead of reliable common cause data and information. - Sorry - tell them qualityg says ... pack up the tents and go home and start over.

Put a Band-Aide on the solution now, becasue that is what you will eventually come to at the end of your analysis. You will have to fudge figures and create data sources that are not neceesary and everyone will give an award and say Hooray for Six Sigma. Your problem will come back much deeper in your process because you TAMPERED.

Circle/Cloud the most likely verifiable (by data, information, facts) root causes. If you did not bring data and information go back to Step I. Start Over for not following directions.

From the group of causes circled, identify the most probable causes for verification. The way of accomplishing this is by facts, data and information (hopefully from the people who do the job) after some analysis has been done.

PHASE III - VERIFICATION

Verify the Cause(s)

Once the group has identified probable root causes, the next activity is to verify the impact the causes have on the overall problem.

There are a number of different ways for group members to verify whether they have accurately identified the cause(s) of the problem. The simplest method is observation. If cause X really is responsible for problem Y, it may be possible to witness this relationship occurring. For example, if a Process Improvement Team has decided that the problem of dissatisfied customers is caused by poor service level, two or three team members may volunteer to observe the time it takes to respond to customer requests and count/tally how often at time exceeds the stated goal or customer expectation of a 24 hour response.

The second method is to design and monitor an experiment that can verify the cause chosen as the one responsible for the problem. For example, a reprographics Process Improvement Team identified rising room temperatures as a cause for poor copies from their Xerox machine. To verify this cause, they designed a simple experiment and intentionally raised the temperature in the room by using the thermostat. They observed that the quality of the copies did deteriorate as the room got warmer. When they lowered the temperature again, the copier produced normal, acceptable copies.

A third method is to conduct a survey among the people most familiar with the problem to learn if the cause they selected is the correct one. For example, a Voucher Process Improvement Team identified lack of training as a potential cause for expense voucher forms being filled out incorrectly. They conducted a survey among the people in the marketing department (since they are the most frequent travelers) and found that not one of them had ever received instruction (verbal/written) on how or what to put on a voucher expense form. Even though training was identified as a potential cause, the real cause was the breakdown in communication as to who should be trained. The training itself is sufficient, since those that had been trained and followed the guidelines were not producing errors.

Once the causes have been verified, post the cause(s) on a Countermeasure or Probable Solutions Matrix and create an Action Plan for Implementation.

Remember, a good acid test to follow is, It is not enough to verify that the root causes exist where the problem occurs. You must also verify that the root cause does not exist where the problem does not exist.

ROOT CAUSE EVALUATION MATRIX

(CLICK ON MATRIX TO ENLARGE)

PHASE IV - IMPLEMENTATION

Once verification of specific causes has been completed it is vital to determine which has the greatest impact on the problem. For example, sometimes the root cause leads directly to a solution. However, if the root cause is generic (a cause that is not unique to this incident/problem, but is found in similar problems/incident) in nature it is usually a larger issue management system breakdown that is harder to solve.

For example, if procedures are not being followed by Front-Line workers despite a directive from management, what would be the corrective action? Traditionally it would be "Coach/Train the workers on Procedure Usage." Rarely does this type of solution get to the root cause of why procedures aren't being used. Corrective Action must take place that effectively deals with the problem of why procedures are not being used.

For example, if Front Line Workers feel that the procedures are complex, slow down work, and nobody (management) seems to care if the procedures are used or not (no follow-up) as long as management objectives are met nothing will be solved. Rather than training on procedure usage, a solution could be as follows:

1) If you have not already done “Actively Involve” your Front-Line Workers!

2) Recommend effective Just-In-Time Action Oriented training to educate the need for

"standard" procedures (assuming the procedures are effective),

3) Recommend more follow-up by management (Training, Methods, IT, Supervisors) in

terms of audits, reviews, evaluating, etc. Where management could reinforce the

importance of procedures and to see first hand what their internal customers are

saying about their product and correct any usage problems immediately.

By following the above example, simple verification, measurement and implementation of solutions can be monitored on-going for proper process system improvement.

Solutions aren't really solutions if they aren't practical, reasonable and cost effective. What good is an opportunity for improvement that can't be implemented? Remember; don't evaluate this type of criteria during the diagnostic or root cause analysis. To do so hampers the creativity of the session. After the session, the group needs to do a debrief and evaluation step. Then sort out those ideas that are not practical, reasonable and cost effective and concentrate on those that are by applying them to a Probable Solutions Matrix and then create an Action Plan for implementation.

Your Probable Soluions Matrix should include these categories:

PROBLEM SOLUTION MATRIX

The following method classifies the diagnosed/analyzed ideas into three categories:

Category 1: ideas that are practical, reasonable, and cost effective and that the team or

support group can act upon and follow through on.

Category 2: ideas that seem practical, reasonable and cost effective, but are beyond the

groups authority or resources. (These ideas can be recommended to the appropriate

management group for consideration.)

Category 3: Ideas that are not practical, reasonable or cost effective.

ACTION PLAN

A. What is an Action Plan?

1. The group's Action Plan is a technique that catalogues all the things that must be done to

ensure a smooth analysis and objective trial of the solution or improvement. It should

also lay plans for what group is accountable for on-going assurance that the solution

effectively removed/reduced the problem.

2. Although the Action Plan may have different formats, it should answer the following:

Click on Action Plan To Enlarge

B. Why is it Done?

It allows the group to explain our ideas to leadership and peers, and it ensures an organized, objective implementation of the selected solutions.

C. How is it Done?

• The proposed improvement or solution is analyzed by the group and then broken down into actionable steps.

• The hardware and numbers of people involved at each step should be considered.

• Brainstorm, if necessary, for other items of possible significance.

• Add to the list until the group feels it is complete.

D. When is it Used?

Develop an Action Plan as part of the Implementation Phase. The plan will be one of the
items that help the group obtain cooperation and approvals, and effectively implement its solutions.

Part IV - Barriers to Root Cause Analysis

http://qualityg.blogspot.com/2007/06/root-cause-analysis-part-iv-barriers-to.html