Examining Carrots and Potatoes
March 22, 2009 12:08 PM Subscribe
Root Cause Analysis: recommendations?
There seem to be quite a few versions of RCA out there. And quite a few organizations, each peddling their own 2 or 3 day acronym-and-buzzword-filled training session.
Are there any you like or dislike? If you've seen more than one, how do they compare? Are any emerging as the standard ones? Which training sessions are worth sending someone to? Thanks.
There seem to be quite a few versions of RCA out there. And quite a few organizations, each peddling their own 2 or 3 day acronym-and-buzzword-filled training session.
Are there any you like or dislike? If you've seen more than one, how do they compare? Are any emerging as the standard ones? Which training sessions are worth sending someone to? Thanks.
Are you sure you need training sessions or other organizations involved? At bottom, root-cause analysis is just what it sounds like: finding the root cause of something. In software, this generally means trying to find the root cause of a defect by reproducing it and demonstrating that fixing the defect eliminates the symptoms. Is there really more too it than that besides writing checks to consultants?
posted by fatbird at 12:45 PM on March 22, 2009
posted by fatbird at 12:45 PM on March 22, 2009
Coming from a manufacturing angle....Are you looking for tools like 5 Why, or Fishbone/Ishikawa charts? If you're in the United States any training offered by the American Society for Quality Sorry, I'd link more specifically but their site is down for maintenance at the moment. And if you want to just get an idea of some of the standard Quality tools and concepts 'Quality Control for Dummies' (yes they really have a Dummies book for everything now) actually has a fairly solid grounding in the basics.
Personally I'm not a big fan of the 5 Why approach, which the idea that digging deeper will get you to the True root cause. The idea being that you ask why five times. For instance, Why did my cake taste terrible? Because I used salt instead of sugar. Why did I use salt instead of sugar? Because I mistook one for the other. Why did I make that mistake? Because I use identical plastic canisters for both. and so on and so forth. My real root cause in this case wasn't the salt, it was the canisters. But unless you're asking exactly the right questions it's easy to go off in the wrong direction. And it doesn't take into account contributing factors.
Personally I like combining that with the Fishbone/Ishikawa method, where you brainstorm about all your possible causes. And you can ask your 'whys' from there. Wikipedia has 6M listed, but I'm only used to 4 Man, Method, Machine, Material. So using my cake example, mistaking the salt would be 'material.' But maybe my recipe told me to taste test the batter, and I forgot to do that. So I had 'man' issues in following my directions.
There are plenty more where those come from, but those are ones I see a lot in my line of work. Also, depending on your field, your customers might have suggestions on training or certain methodology. Don't hesitate to ask them, anything where you're proactively doing something to improve your quality is going to look good in their book.
posted by Caravantea at 12:50 PM on March 22, 2009
Personally I'm not a big fan of the 5 Why approach, which the idea that digging deeper will get you to the True root cause. The idea being that you ask why five times. For instance, Why did my cake taste terrible? Because I used salt instead of sugar. Why did I use salt instead of sugar? Because I mistook one for the other. Why did I make that mistake? Because I use identical plastic canisters for both. and so on and so forth. My real root cause in this case wasn't the salt, it was the canisters. But unless you're asking exactly the right questions it's easy to go off in the wrong direction. And it doesn't take into account contributing factors.
Personally I like combining that with the Fishbone/Ishikawa method, where you brainstorm about all your possible causes. And you can ask your 'whys' from there. Wikipedia has 6M listed, but I'm only used to 4 Man, Method, Machine, Material. So using my cake example, mistaking the salt would be 'material.' But maybe my recipe told me to taste test the batter, and I forgot to do that. So I had 'man' issues in following my directions.
There are plenty more where those come from, but those are ones I see a lot in my line of work. Also, depending on your field, your customers might have suggestions on training or certain methodology. Don't hesitate to ask them, anything where you're proactively doing something to improve your quality is going to look good in their book.
posted by Caravantea at 12:50 PM on March 22, 2009
If you want the good stuff you have to go back to the Japanese Quality Engineering movement of the 1950's and 1960's, Ishikawa et al. (On preview: eponymous inventor of the diagram Caravantea mentions.)
That's the scientific end of it, because RCA was originally a super-heavyweight statistical analysis technique (like, for people with PhD's in Industrial Statistics), but this is all very generic and designed to be applicable within almost any industry, so you would have to read lots of stuff and experiment to get a good regimen working for yourself.
Also, as fatbird points out, it's not some magic wand: no one can tell you a secret that will make all of your troubleshooting go better or faster. In the end only careful hard work and discipline and careful planning will get you anywhere.
But... if the source of this question is that you have a training budget you've got to get rid of or something, one book I was always pretty impressed with was The Team Handbook. It manages to convey things in a familiar and lucid way while still staying in line with scientific quality engineering principles and without dumbing things down too much. It's on the quality management / project management side of things moreso than quality engineering where root cause analysis would be, but its author-publisher Oriel Incorporated might be a good place to start looking for training products and services.
posted by XMLicious at 1:32 PM on March 22, 2009
That's the scientific end of it, because RCA was originally a super-heavyweight statistical analysis technique (like, for people with PhD's in Industrial Statistics), but this is all very generic and designed to be applicable within almost any industry, so you would have to read lots of stuff and experiment to get a good regimen working for yourself.
Also, as fatbird points out, it's not some magic wand: no one can tell you a secret that will make all of your troubleshooting go better or faster. In the end only careful hard work and discipline and careful planning will get you anywhere.
But... if the source of this question is that you have a training budget you've got to get rid of or something, one book I was always pretty impressed with was The Team Handbook. It manages to convey things in a familiar and lucid way while still staying in line with scientific quality engineering principles and without dumbing things down too much. It's on the quality management / project management side of things moreso than quality engineering where root cause analysis would be, but its author-publisher Oriel Incorporated might be a good place to start looking for training products and services.
posted by XMLicious at 1:32 PM on March 22, 2009
This thread is closed to new comments.
posted by Houstonian at 12:29 PM on March 22, 2009