3 simple tools to help with root cause analysis

Quickly find out why things aren’t working so you can start making sure they are

3 simple tools to help with root cause analysis

Quickly find out why things aren’t working so you can start making sure they are

Why you need to tackle the root cause

Problems in your organisation can occur for a variety of reasons and present themselves in an almost infinite number of ways. When something does go wrong it’s all too easy to make a knee jerk reaction and try and fix what seems to be the most obvious cause without taking the time to discover the real reason behind it.

This is a false economy. Although you may have a quick fix, it’s likely to be temporary and continually fixing symptomatic issues can create more complicated processes with multiple workarounds. Root cause resolution may take a little more time to find out what is really going on, but you’ll have a proper solution that contributes to overall business performance, customer satisfaction and, ultimately, revenue.

In this article you’ll discover three easy tools that can help you identify the real reasons behind business problems and pain points. You’ll then be better armed for tackling the changes that need to be made.

Tool 1: The 5 Whys

Perhaps the simplest of the tools, this technique requires you to essentially take on the persona of young child and keep asking Why?! You just keep going until asking why gives you no further information, you don’t have to stop at five. For example;

The customer won’t pay for their meal
WHY?
Because the food was late and cold
WHY?
Because the waiter didn’t bring it out in time
WHY?
Because he didn’t know it was ready for service
WHY?
Because the service bell isn’t working
WHY?
It’s battery operated and the batteries are flat
WHY?
Because no-one checks them regularly
WHY?
Because management hasn’t assigned this as a task

You can see from this example that there are several points at which the problem could be solved in some form. Ultimately, a lack of communication and poor delegation of tasks from management has much greater repercussions, such as inaccurate orders, shortages of staff, paying staff late etc.

Replacing the flat batteries in the service bell wouldn’t fix the root cause, which is no-one knows they need to check the batteries regularly. Without this extra step there’s nothing to stop this problem happening again. When fixing this problem you could also add in other safeguards, such as a process for what to do if the batteries are found to be flat when testing, and for making sure there are always fully charged batteries available to replace them.

Tool 2: Cause and Effect Analysis

Developed by Professor Kaoru Ishikawa and published in 1990, this technique used a combination of brainstorming and Fishbone Diagrams (sometimes known as Ishikawa Diagrams), to look at problems that may have multiple causes. They take longer to perform but are a lot more comprehensive than the five whys, making them more suitable for more complex business problems.

Step 1: Identify the problem

It’s crucial that you do this correctly and get the exact problem. Make a note of who is involved and where and when the problem occurs. To help you define the problem more accurately you can use the CATWOE technique, where you get a comprehensive understanding of the problem by looking at it from the perspective of;

  • Customers
  • Actors in the process
  • the Transformation process
  • the overall World view
  • the process Owner
  • Environmental constraints

When you have your problem defined, place it in a box at the left hand end of a horizontal line as shown below:

Step 2: Identify the major factors involved

Use models such as the McKinsey 7S framework (or the 10Cs of marketing) to help you identify factors affecting the organisation. They can be as diverse as systems, equipment, materials, external forces, people, customers, etc. Place a line off the spine of the diagram for each factor and label them.

Step 3: Brainstorm the possible causes

Taking each factor in turn, consider the possible causes related to each. Show these as lines coming off the bones of your fish diagram.

Step 4: Analyse your diagram

You now have a summary of all the possible causes of the problem. Each of these can be investigated in turn, using things like surveys, interviews, shadowing, etc., to see which of these possible causes are actually contributing to the problem and, if so, by how much.

Don’t forget the impact analysis!

Now you know what you need to fix make sure you understand what else will happen when you make the changes.

Think back to the example used in the 5 Whys. You’ve now put a process in place where the junior chef checks the batteries in the service bell every 15 mins to make sure they are still working. Great! You’ll always be on top of that issue and shouldn’t miss a customer order again right?

However, because your chef is having to leave his cooking every quarter of an hour to make that check, the quality of his food is decreasing and orders are taking longer to prepare. Furthermore, to check the bell he has to ring it. Since the waiters associated the ring of the bell with an order being ready they all come back into the kitchen to collect the orders – which don’t exist because this is just a test. They’re now spending less time with the customers, helping them choose their meals, and getting totally fed up with all the to-ing and fro-ing. Some have even started ignoring the bell until they’re ready, which means some customers are getting food that is late and cold.

You’re back to square one.

Tool 3 – Impact Analysis

Make sure you don’t cause more problems than solutions with your changes by carrying out an impact analysis before you make them. To be truly effective it’s best to conduct this analysis with involvement from people in all areas of the business so you understand how each of them are potentially affected by the changes. This last tip also has the added benefit of making stakeholders feel engaged with and open to the change, which can make it more effective.

Step 1: Prepare for impact analysis

Make sure the team you use are well briefed and have access to all the right information sources. The change project should be clearly defined and everyone should understand what problem this is aiming to address and the ultimate aim of the project.

Step 2: Consider all areas affected and evaluate the impact

Don’t just think about the processes in the department where the change is going to happen, follow the affected processes both upstream and downstream to see if there will be an impact elsewhere. For example, if you need more information to get invoicing procedures correct how will this impact the sales team who have to collect that information?

Step 3: Evaluate the impact

Once you have a list of what will be affected you need to make an evaluation of the consequences of making the change, and of not making it. With the invoicing example you may find that gathering the information means the sales time not only have to change the way they collect the data, you’ll need to make changes to the software to accommodate it and develop systems integrations to make sure the data is passed to accounts without the need to rekey it. Aside from the extra costs all of these factors introduce, the sales team will be spending more time entering information leaving them less time to actual sell your products, so your revenues are likely to fall just as you are having to increase your outlays.

So, whilst the change would mean invoicing errors would reduce, saving you £5,000 per year – the cost to sales increases is over £10,000 per year. In this case, the cost of the change does not justify the potential benefits so alternative solutions would need to be found and analysed.

Conclusion

The tools presented here are very simplistic but they can help you take that first step towards problem identification and process optimisation. When you know the scope of your problems it’s easier to create a case for a more comprehensive optimisation project that is going to deliver real value to your business.

This post was originally written by: Jo Bennett

You might also like