Root Cause Analysis and Problem-Solving

We are working in a more complex environment, and being able to piece together what has happened when something goes wrong or understand how to solve a new problem has become increasingly challenging.

Bcorp Logo

Root Cause Analysis and Problem-Solving

It's about more than just the tools.

What specific traits are necessary now for effective problem-solving in the workplace? Are there any common pitfalls to avoid when conducting root cause analysis? How can an organisation or team culture impact the effectiveness of root cause analysis?

Relying on just tools will get you so far, but having a better understanding of how to glue those tools together can reap the rewards.

When researching introducing a course to give a structured approach to Root Cause Analysis, it quickly became apparent that there are numerous methods, tools and strategies for analysing what may have happened to cause a problem. When looking back at the experience of solving many production issues, some trivial, some critical, it was clear that tools played a minor part than imagined.

Root Cause Analysis and Problem-Solving

One of the critical inputs into the process is you.

Have you ever met anyone who seems natural at problem-solving within your workplace? Were they good communicators, naturally curious, structured, and tenacious? You might recognise a few key characteristics they have, and when coupled with an environment or organisation that supports it, which results in a great result.

Root Cause Analysis and Problem-Solving

Being more aware of some of these traits that you can improve as an individual or ideas that you can implement and support from within your team or organisation will reduce time spent identifying problems.

Having multiple approaches and tools also gives options; some will be very formal and may suit a regulated environment, and others may be more lightweight and suit a faster-moving environment where you still want control and consistency.

All are generally based on a standard approach and will often require a shift towards supporting a learning environment where you capture data to help understand the problems, allow time for the analysis, and then make changes based on that analysis.

Don't underestimate the Importance of learning.

Learning is necessary for any root cause analysis tool to avoid becoming a moot point. It might give you a cause, but if the action is purely cursory, you are more than likely doing incident management, i.e., getting the system back up and running as quickly as possible or doing a project 'lessons learned'.

Root Cause Analysis and Problem-Solving

The challenge to these is that they often focus on the short-term view. Data may is lost if a server is re-started too quickly or an opportunity to ask a user what they were trying to do is missed. Data capture is a critical element in performing practical root cause analysis.

It's usually not just one thing.

It's common to have multiple causes or smaller non-related events that, when given the right conditions, will cause an issue. These various causes are why trying to 'test' for every eventuality can be a challenge. So often, when we come up with a root cause, the question, 'Why didn't we test for that' becomes a bit redundant as it implies, that we could have predicted this.

It might not even be the system.

One thing to be aware of when digging around for that elusive root cause is that it might be a little harder to fix. For example, if a user input causes a problem, you might start with why did the system allow it, well the user didn't input other data needed, why? "We weren't told to." Why? "They had no training." Why? "The trainer was out." etc. As you can see, a very quick five whys (a standard root cause tool) drives down that the ultimate problem was down to training (or lack of) or that training could have been given offline initially, for example.

The blame game.

Unfortunately, one of the critical detractors to understanding why things go wrong is naming individuals or teams in your root cause. It doesn't mean that we can't hold to account for repeated human error, but it is all about context. It does mean, though, that if we have a culture of fear, it's more likely that people will hide things. Adapting the organisational/team culture might be challenging. Still, it's worth reviewing if it is blocking practical root cause analysis and you do not see any change or reduction in incidents.

Root Cause Analysis and Problem-Solving

Finally, Root Cause Analysis is not just for incidents.

Root Cause Analysis is about more than just solving issues or things that are broken or of poor quality. Instead, these techniques and approaches can help to solve many other problems, facilitate workshops or identify system or process improvements. They do this because they focus on generating ideas and encouraging curiosity.

Let's start of however, by considering some of the questions that you might ask of any programming language that you are interested in including:

  • Do I have to pay for it or is it free?
  • What development environments are available for it and are they free?
  • What resources are available (free) online to help me learn.
  • Is the language a low level or high-level language? Lower-level languages tend to be closer to the underlying machine code which is the language of the computer and higher-level languages tend to be more English like with higher level constructs.
  • Is there employment in this language (although this may not be relevant at the moment for you it is still worth considering)?
  • How complex a language is it – in general lower-level programming languages tend to be more complex than higher ones although this is not necessarily a given.

Would you like to know more?

If you found this article interesting you might be interested in our Root Cause Analysis Training Course.

Share this post on:

We would love to hear from you

Get in touch

or call us on 020 3137 3920

Get in touch