As you can imagine with working in the technology field, Lee has attended quite a number of courses over the past 30 years. Some of these were purely technical, others project or service management oriented; However, the course that has stayed with him the most and he believes has more than proven its value, was a course aimed at Root Cause Analysis (RCA).  

Being proficient in troubleshooting is one of the most valuable & transferrable skills you can have, but one that doesn’t come naturally to everyone. 

It certainly helps to understand the fundamentals of a particular technology, process or procedure. This allows you to understand and isolate factors that could possibly have an influence upon outcomes. Specialist subject matter knowledge is helpful, but it isn’t critical, logical thinking on the other hand is paramount to a quick efficient identification of true cause. 

Far too often teams make changes they “think” may resolve the problem, without actually knowing what caused the problem or even why it is a problem.  This sort of troubleshooting process (used in the loose term as it’s actually a lack of process) generally leads to uncontrolled change, which could actually compound and obscure the original issue and increase both downtime and cost to the business. 

RCA should be taught as early as possible to ensure the process of identifying true cause is second nature.  This not only helps to minimise impact to organisations when the tolerance of normal operation is compromised, but can also lead to improved research and development (R&D), which in turn can result in positive benefits in relation to sustainability, reliability and innovation. 

Being able to correctly identify true cause allows the re-evaluation of the defective part/process/procedure.  Start by establishing a timeline with facts and metrics that support the conclusion, so that you can communicate the findings.  This will enable the development of a plan that not only provides the solution to the immediate issue, but also allows collaboration on an improved design to ensure there is no repeat of the failure. 

An easy mistake to make when dissecting the problem is to only look at what is wrong and ignoring what isn’t wrong. 

Identify the window of change i.e., the time in which something went from working to not working,  

• Identify the last documented time the part/process/procedure worked correctly. 
• Identify when the issue was first noticed/reported. 

There is now a window of opportunity where you can ascertain what changes were made to the environment that could have resulted in the undesired outcome or issue.  

The importance of logging and auditing systems cannot be overstated, this provides a forensic trail of activity immediately before and during the window of change.  

If the organisation has implemented an effective change management process, you should be able to gather information on all changes that occurred during the “window of opportunity” and assess the potential impact of these changes against the symptoms of the issue i.e., could change x have resulted in the symptoms of the issue? No? move onto the next change and then the next until there is something that warrants further investigation.  

Of course, this approach is predicated on everyone in the workforce adhering to the change process, however, outside of an authorised change, you’d generally be aware of who would implement the type of change that could result in the outcome experienced and therefore, another source of information to assist in the troubleshooting is available.  

Root, Cause, Analysis fits perfectly into the TGG approach of “What does success looks like to you?”, Check back later to learn how.