Root Cause Analysis, great tool to inspect and adapt

Today’s post about introduction to Root Cause Analysis is in English. 🙂 It’s one of many experiments that I’m gonna conduct on this blog. The goal is to get more non-Polish-speaking receivers, not loosing the Polish-speaking readers. If it works – that’s might be the way to follow. But I need some Evidence to Base further Management (if you know what I mean). 😉

As Empirical Process Control is essential in Agile – I’m always keen on doing that and learning from it. Additionally, I’m gonna show, that I’m regularly tasting the medicine I prescribe the others. 😉

I promised in some previous posts that I’ll shed more light on the RCA method (here and here), and I like keeping my promises. 🙂 Let’s begin.

Root cause analysis a.k.a. RCA – What’s all about?

Root Cause Analysis (RCA – and I’ll be mostly using this abbreviation) is a method (just like kanban ^^) of improvement. It has really simple definition, behind which is standing quite intriguing, and effective (under some conditions) content.

Wikipedia (universal source of all truth ;)) defines it as:

From my standpoint it’s OK-ish definition (covering the ‘inspect‘ part). What I’m missing is the ‘adapt‘ part. The definition I like much more is the definition from Tableau (company providing Data Visualisation software).

BTW, Tableau software is great, and has almost unlimited potential, even if you are hardcore data-miner. I used to use it for some time, and even though I barely scratched the surface of it’s capabilities, fell in love with Tableau and recommend it ever since. Oh, it’s not commercial in any way, just sincere feedback. But going back to the RCA, this definition says:

Root cause analysis (RCA) is the process of discovering the root causes of problems in order to identify [and introduce] appropriate solutions

Tableau

I underlined the previously missing part. Also added something from myself – text in brackets. After these adjustments I think, this definition is complete, and we can move further. Neat, clean and self-explanatory.

So RCA is a tool for improvement – to identify holes and fix them in a system way, usually finding much more stuff than expected at the beginning (spoiler!) 😉

So, How it landed in my toolbox?

Simply put – I had a pleasure to participate in an RCA Driver/Coach training a few years ago, when I used to work for Ericsson. 🙂 It was conducted internally by one of the experienced Operational Excellence office members. We, newly acquired members of Ericsson family were trained to perform tasks of the global unit. Performing RCAs was one of those, and so it begun.

For me – RCA clicked. Actually clicked a lot. 🙂 To be honest, it’s one of the most useful and impactful tools I ever learnt and used. And it was just the beginning.

Ericsson Approach to RCA

Ericsson is very big company, with number of Employees exceeding 100k at the beginning of 2023. Additionally, is developing extremely complicated products (hardware, software and services). Those products affect billions of people on a daily basis (you are rather familiar with LTE and 5G, right? ).

As such, it needs sufficiently reliable processes to maintain superior level of quality. Or work unnoticed – what often is best praise for a service.

But the more complexity, the more risk of committing a mistake. With such scale of operations – mistakes are inevitable. However important is, how quickly and how thoroughly mistakes are corrected both in short and in long term.

And here’s the moment, when RCA sets the stage.

RCA finds and helps removing Root Causes in the products and processes. Sounds like truly Scrum Masters’ tool? 😉 And indeed it is.

What’s worth mentioning – Ericsson treated RCAs seriously. Findings and improvements proposals were taken into consideration on a way to improve. The process and results were fully transparent – sometimes difficult, almost always surprising.

One trigger of Root Cause Analysis could have been Customer that experienced a fault and wanted explanation. The other – internal request to analyse some situation to get better. In some cases it was automatic (e.g. every field-registered fault was triggering RCA). In some other cases – ad-hoc, thoroughly considered decision to dig more into details of some sort. We expected better performance than achieved, we missed deadline, we run out of budget – you name it.

Although the details of the RCA process changed through the years, however one thing was constant – principle of continuous improvement.

From Driver to supervisor and trainer

Soon after training, I’ve got opportunity to (co)drive my first RCA. It was great opportunity to learn the field experience in the topic. Oh, and we nailed it 🙂 By WE I mean whole RCA Team – XFT (cross-functional team) and us, drivers. Findings were stunning, and the improvement ideas – feasible and to-the-point. I still use some findings from that RCA as examples in my trainings.

Organization liked it, managers liked it, so more RCA requests started coming. And while helping the company, we were getting more and more experience. Win-win situation 😉

But one day we reached a point, where we’ve become classic bottleneck. And we had more RCAs to drive, than capacity to do this. And as feedback is best provided immediately – so is RCA. So we decided to modify our approach, and start making more RCA Drivers.

And we started teaching. At first, we were teaching theory, and supervising the practice. Asking unasked (yet) questions, clarifying analysis, etc. With time, our Drivers gathered more experience and needed less supervision, so we reached our goal.

evolution of the RCA training

As I wrote at the beginning – The training I took part in was 3-day. There was a lot of material, but from my perspective – some of it (actually A LOT) was redundant. It even contained attempt of solving real Root Cause Analysis case during the training.

HOWEVER 😉 as I’m big fan of minimalism and simplification, in my version(s) of the slide deck I made ‘minor’ changes. Well, maybe not so minor 😀

Through the years, I had the opportunity to conduct dozens of trainings, from whole-day extensive workshops to 2-hour overviews. And realised, that the longer parts don’t necessarily provide greater value. So if I have the choice between two slide decks providing similar value (#Effectiveness), and one is significantly better in terms of using my time and time of my colleagues (#Efficiency) – I always go that path.

So I decided to gut it, and leave the most valuable, impactful parts, necessary for the ones that’s gonna conduct the RCA. Good enough to understand the principles, get a grip on the Way-of-working and start analyzing.

This post is a announcement. Announcement, that I’ll share with you ‘my way’ of teaching the Root Cause Analysis method. It’ll take me two posts. One will describe and explain the theory of RCA (Ericsson RCA actually). Second – will be my analysis of one real life case, showing how theory works in practice. Because it is 🙂

So expect more on this topic soon 🙂

Warm regards,

Marcin