Root Cause Analysis

[RR1]

Just wondering how others handle getting to the "root cause" of errors in their labs. I've tried the '5 whys' technique- but we are still experiencing repeat events, which obviously means we are not identifying the correct root cause.

One of my team is very enthusiastic about using 'fishbone' analysis and has suggested a number of different solutions. I have also read about the "is-is not" technique for analysing problems.

It would be really helpful to hear from others who have routinely used these techniques for corrective/ preventive actions and for more tips on using these tools.

Many thanks!

Edited July 25, 2009 by RR1

[Malcolm Needs ☆]

Just wondering how others handle getting to the "root cause" of errors in their labs. I've tried the '5 whys' technique- but we are still experiencing repeat events, which obviously means we are not identifying the correct root cause.

One of my team is very enthusiastic about using 'fishbone' analysis and has suggested a number of different solutions. I have also read about the "is-is not" technique for analysing problems.

It would be really helpful to hear from others who have routinely used these techniques for corrective/ preventive actions and for more tips on using these tools.

Many thanks!

I must admit that I have had trouble with the "5 whys" technique - not least trying to think of 5 questions beginning "why?".

I can usually get one question in my mind that drives out all the others, namely,

"Why did we ***** up?".

:confused::confused:

[RR1]

I thought that when you use 5 whys, you just carry on asking why? after you think you have reached the possible cause for the initial problem.

It's similar (but the reverse ) to asking your children to do something, and they reply.... ..but why????, so you respond because of the following reasons... and you get another.. but why??? etc...until you get a headache and give up, or give them a choice of even more chores to do.

[Malcolm Needs ☆]

Oh, I know what it means, it's just that the first question drives all the others out of my mind!

[Malcolm Needs ☆]

I didn't know ***** was a swear word in the USA????!!!!!!!!!!

:redface::redface:

[RR1]

Oh, I know what it means, it's just that the first question drives all the others out of my mind!

I know- but usually we all jump to the most obvious conclusion, and that is usually trying to blame a member of staff for not doing something.

I have come across something called 8D problem solving which looks really useful in systematically working through errors to get to the root cause, and formally documenting the process.

[Malcolm Needs ☆]

I know- but usually we all jump to the most obvious conclusion, and that is usually trying to blame a member of staff for not doing something.

Ah, you've come across my managerial style.

If everything goes brilliantly well, it's down to me.

If something goes wrong, it's time to blame somebody else.

It's worked so far!

:D

[RR1]

So have you heard of 8D problem solving Malcolm, and do your Q.A people use this?

[Bill]

FishBone analysis works well as does very detailed flowchart of your process. I have staff member do very detailed flowchart, then match it to flowchart of SOP. Check for differences, and while your at it, check to see if SOP flowchart can be simplified--the KIS principle.

[Malcolm Needs ☆]

So have you heard of 8D problem solving Malcolm, and do your Q.A people use this?

Is that the one that goes:

1. Use a team approach.

2. Describe the problem.

3. Implement and verify interim containment actions

4. Define and verify root causes.

5. Verify the corrective action(s).

6. Implement permanent corrective actions.

7. Prevent problem recurrence.

8. Congratulate the team.

???????

No, never heard of it!

Yes, we do use a version of this, but I always get stuck at 7. I can never bring myself to go on to 8!!!!!!!!!!!!!!

:rolleyes:

[RR1]

I think I need a more structured approach to performing the RCA and have found the following document on the web used in manufacturing problem solving- but easily adapted for lab use. This follows the 8D structure.

8D worksheet.doc

[adiescast]

Looks like the 8D method uses both fish bone and 5 whys. Those are both good methods, although I like the structure of the fishbone better. The flowchart of the actual occurence compared to the SOP, mentioned by Junior Member, is also an excellent method. The biggest barrier to finding the root cause is getting the human factor figured out. Often you don't get the complete story, either because people don't accurately remember the sequence of events or because they don't want to admit that they didn't follow the procedure...

[tbostock]

Ever try a FMEA (failure mode effect analysis)? Essentially you write every single step of a process, no matter how small. Then you grade each one according to:

How easily/often is there a problem at that step?

How severe would the consequences be to the patient at that step?

You multiply these two numbers, and you pick the top few items that have the highest score to work on for corrective action. It's not hard to do, and works pretty well.

[RR1]

Thanks Bill, Adiescast and Terri, lots of good ideas to work through.

The FMEA suggested by Terri sounds very similar to what Bill has written, but with values given-I like the sound of this approach, and it seems the important part is to perform the process map.

many thanks!

[ar_confederate]

I've used the 5 Whys and the fishbone for our RCAs. Of the two, I think that the fishbone works better for us since it is visual. I've started using a flowchart of the process for some of the RCAs and it has also worked pretty well. It often will show a gap in the process flow that might not be recognized as readily with some of the other tools.

[GaryCheung]

Is that the one that goes:

1. Use a team approach.

2. Describe the problem.

3. Implement and verify interim containment actions

4. Define and verify root causes.

5. Verify the corrective action(s).

6. Implement permanent corrective actions.

7. Prevent problem recurrence.

8. Congratulate the team.

???????

No, never heard of it!

Yes, we do use a version of this, but I always get stuck at 7. I can never bring myself to go on to 8!!!!!!!!!!!!!!

:rolleyes:

We use 8D for higher severity incidents/non-compliances.

Qpulse has an 8D template installed as standard & it has a few sub-stages within the ones you list above.

within 3 there is a stage to Validate that Actions identified actually worked (the idea being to require someone to sign off the containment actions have done their job before moving on to the next stage)

Within 4 RCA there are:

Analyse and Identify tools for investigation (e.g. 5 whys, fishbone etc - the thinking being that some tools suit some problems better than others)

Generate Action Plan (i.e. the QM's Action Plan that deals with root causes)

Instead of 5 (Verify CAs) the template has Identify Corrective Action with instruction to "Document and verify Permanent Corrective Actions" (this is the bit where responsible manager's decide how to translate the QM's Action Plan into a real local plan with responsiblities, time-scales & mechanisms for measuring success.

I have altered 7 to Preventive Action (to keep CPA happy) with sub action "Identify similar systems with the potential for the same defect." (i.e. a Lessons Learned communication to other areas or identification of similar systems within the same area).

I'm told that it is actually Stage 1 that is supposed to make the difference with the 8D approach. The rationale being that you need to involve all stakeholders at the very start to get buy-in for subsequent proposed changes & actions and to capture suggestions for improvement from as wide a group as possible, but particularly from within the staff group who are actually performing the procedure/process.

[RR1]

Thanks for your helpful post Gary- as I have said before...I wish I had QPulse, it would make my life so much easier!!!.

[dferia]

Ever try a FMEA (failure mode effect analysis)? Essentially you write every single step of a process, no matter how small. Then you grade each one according to:

How easily/often is there a problem at that step?

How severe would the consequences be to the patient at that step?

You multiply these two numbers, and you pick the top few items that have the highest score to work on for corrective action. It's not hard to do, and works pretty well.

FMEA works pretty well, and really, using all of these together tends to work best as there are always inherent weaknesses in everything and mixing/matching tends to compensate for a weakness in the RCA method used. Granted, one can over do it if common sense is lost and obsession sets in. Not that any of us have time for obsessive paperwork on top of everythign else.

Regarding FMEA, I've always been a big fan of one more value in addition tot he two mentioned: How likely is it that if an error occurs, you will notice it. The value for this is inverted compared to the other two values mentioned: low number for an error being super easy to discover (such as you push the red button and the machine explodes) and a high number for an error not likley to be noticed until its too late (and I wish I had a witty joke for this one, but I'm still working on my first coffee, so we'll have to settle for disappointment, or relief since I know how bad my jokes are).

As above, multiply them out and target the highest items.

As always, mileage may vary.

[bmsjbatt]

have tried several methods of RCA none of which easily lead you into a deep enough analysis, I have been using the following for a few months now and although the first time I used it I was someone hesitant, I have come to like its systematic approach.

http://www.msnpsa.nhs.uk/idt2/(jg0xno55baejor55uh1fvi25)/usethetool.aspx?JS=1 is the link for the NPSA incident decision tree, we have to use this as standard at our trust, very useful website allows you to either do a very quick analysis or you can use the secure version and store it on your hard drive for further reference.

I am enclosing a paper copy of how the incident decision tree works.

Incident decision tree.doc

Edited August 3, 2009 by bmsjbatt

[Franklyn]

Your post doesn't elaborate on what kinds of issues you are trying to perform a root cause analysis on, but just as an aside I must express an opinion that a root cause analysis is really only a useful endeavor when you are trying to locate and correct a system problem. Unfortunately, some errors are completely biological in nature and do not lend themselves well to a detailed 'root cause' process. I do not perform such analysis on every error reported but rather do so only when a pattern of error emerges. If one tech makes the same error over and over then that tech has a problem. If several techs make the same error (repeatedly) then I may have a system problem that will benefit from such an analysis.

Just my two cents worth...

[Malcolm Needs ☆]

Your post doesn't elaborate on what kinds of issues you are trying to perform a root cause analysis on, but just as an aside I must express an opinion that a root cause analysis is really only a useful endeavor when you are trying to locate and correct a system problem. Unfortunately, some errors are completely biological in nature and do not lend themselves well to a detailed 'root cause' process. I do not perform such analysis on every error reported but rather do so only when a pattern of error emerges. If one tech makes the same error over and over then that tech has a problem. If several techs make the same error (repeatedly) then I may have a system problem that will benefit from such an analysis.

Just my two cents worth...

And a good two cents worth too in my opinion.

Where I work, we have to do a root cause analysis if we breathe too noisily (an obvious exaggeration, but not that much of an exaggeration). Quality are scared stiff of the GMP inspectors.

[MAGNUM]

maybe if you used *%$@ it would be more readily understood in the USA

[Marilyn Plett]

Thank you, Franklin, for a breath of fresh air. I share your attitude.

[Tonyd]

Your post doesn't elaborate on what kinds of issues you are trying to perform a root cause analysis on, but just as an aside I must express an opinion that a root cause analysis is really only a useful endeavor when you are trying to locate and correct a system problem. Unfortunately, some errors are completely biological in nature and do not lend themselves well to a detailed 'root cause' process. I do not perform such analysis on every error reported but rather do so only when a pattern of error emerges. If one tech makes the same error over and over then that tech has a problem. If several techs make the same error (repeatedly) then I may have a system problem that will benefit from such an analysis.

Just my two cents worth...

Completely agree, Franklyn - some folk would have you doing a RCA for wearing odd-coloured socks these days, it seems and you have to wonder about the time and resources allocated to some of these.

(On the other hand of course, some are not being done for serious incidents that really do warrant a full investigation..)

[bmsjbatt]

As the quality manger for all of Pathology at my trust, I am responsible for ensuring that suitable amounts of RCA are carried out, but I am also a pragmatist who recognises that you can take all of these things too far. My recommendations are that in most instances the decision tree RCA can be done in your head asking 4 questions,

1. Did the individual involved intend to do this?

2. Are they ill, under the influence of drugs (prescription or other), over tired, etc?

3. Did they follow agreed protocols, processes, procedures? Were these available to them?

4. Would another person in the same position, same qualifications/experience have done the same thing?

If the answers come up to a system errror, then you have a system error, More in depth RCA can be carried out if the answers show failure in the system or someone has stepped outside of the system, then obviously record it

Agreed sometimes errors do "just occur", but you can simplify processes and procedures to reduce the number of steps, thereby reducing the likliehood of errors occuring.

Occasionally I recommend that a single RCA is carried out on a group of similar errors, I have the advantage that I can see trends across the trust where individual departments may only see a very narrow view.