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.
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.
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.
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.
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'.
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 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.
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.
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 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:
If you found this article interesting you might be interested in our Root Cause Analysis Training Course.
