CEM Toolbox: Root Cause Analysis

futurelab default header

A new series that I’m starting for 2013, in addition to continuing my “Customer Experience Lessons from…” series, is “CEM Toolbox.” I’ll try to keep these Tool posts short and sweet, but occasionally I’ll drill deeper and add more color and detail. I promise the posts will get more refined over time. The first tool that I’ll write about is Root Cause Analysis.

I’ll stay away from politics (I feel like I’ve said that in a few posts now! How am I doing?), but my first Tool was prompted by the aftermath (politically) of the recent senseless shootings in Newtown, CT. First off, my heart goes out to the families of the victims; as a mom, I am reminded daily, and especially by such tragedies, that life is precious and too short – and there’s nothing more important than our loved ones, especially our kids.

But I do have a takeaway from some of the follow-up conversations on where the blame lies and what needs to be fixed. I think these discussions are a great reminder that we cannot overstate the importance of using Root Cause Analysis, in our daily lives and, especially, in our customer experience work. And, obviously, that’s where this Tool takes us.

What does Root Cause Analysis (RCA) do for us? It provides us with answers – not off-the-cuff answers but drill-deep-down answers – to product or service issues. Sometimes the answers are not the obvious. We need to step back and think deeper about why things are the way they are.

Why do we need this in our CEM Toolbox? We get feedback about the customer experience. Some experiences are great, while some are not so great. We need to understand the reasoning behind the “not so great.” RCA is an effective Tool to identify where process or other improvements need to be made.

One of the approaches used for RCA that I like, especially for its simplistic nature, i.e., easy to explain, is 5 Whys. How it works: State the problem and then ask “Why?” five times to drill down to the ultimate cause. It seems there‘s a human problem behind every (technical) issue. The good news is that you can adapt this process to your needs; sometimes asking “Why?” five times is too many, and sometimes you need to ask it more than five times.

In this video from HBR, Eric Ries explains the theory:

Please accept targeting cookies to see this content


 

Here’s an example of how that works.

Problem: The customer is unhappy.

Why is the customer unhappy? We didn’t deliver the product when we said we would.
Why didn’t we? It took longer to make than we estimated.
Why did it take longer? We didn’t realize how much effort it would take to make it.
Why didn’t you realize that? We didn’t scope it properly.
Why not? Because we were overworked and didn’t have enough time.
Why? We’re short-staffed right now.
Why are we short-staffed? The company down-sized recently. 
Etc.

This example could go on and on. But you get the point. 

This particular approach may not work in every scenario, but it’s certainly a good place to start. There are several techniques to use for Root Cause Analysis, and I may come back and revisit this topic in the future. But for now, find an approach that best suits your needs. When there’s a problem, don’t jump to conclusions. You will waste time and effort on the wrong thing and end up with the same issue happening again. Ultimately, the goal is to identify the root cause and then determine how you’ll correct it so that it doesn’t happen again.

If you only have a hammer, you tend to see every problem as a nail. -Abraham Maslow

Click here for the original post.