Zen and the Art of Root Cause Analysis
Bob Koonce
Helping oil and gas leaders reduce major process safety incidents and improve operational performance using proven lessons from the US Nuclear Navy. Founder & President at High Reliability Group LLC | Keynote Speaker
When Robert Pirsig took off in 1968 from Minneapolis - St. Paul on his Honda CB77 Superhawk with his son Chris on back, he was searching for the meaning of quality. I don't know that he ever found it nor have I. But search on we must. This article is just one more step on that journey for me.
It's been many years since I read Zen and the Art of Motorcycle Maintenance and while I don't remember all the details, some of it has stuck in my mind when I reflect on quality and the search for solutions in the work that we do..
This short article is not meant to address the Metaphysics of Quality as Robert Pirsig was doing - I am just not that smart or crazy (don't comment on that). I simply want to share some thoughts and reflections on the quality of root cause analysis of all things.
Why Root Cause Analysis? Because it is at the heart of High Reliability Organization success. It is the leadership and feedback mechanism that allows organizations to develop resilience and improve efficiency - to continuously improve themselves and avoid catastrophic incidents in a high risk environment. If I had to chose one thing from my twenty years operating US nuclear submarines, I strongly believe that the root cause analysis process we did on board submarines, and the ability to do it well, was the key to successful high risk operations. If done properly it is not great fun, but the impact and insights that come from the process, not to mention the solutions that are born from this effort, are worth the time.
In the Zen book, the author describes the value in understanding how things work. He describes the beauty in the physics and science and engineering designed into his motorcycle's engine. He contrasts his self sufficiency in repairing his old bike to his riding partner, John Sutherland, who simply rides a new BMW motorcycle and has little understanding of how it works. If the BMW breaks down, John must turn to a mechanic to identify and fix the problem. Pirsig goes on to describe how Sutherland's disdain for understanding the science and physics of this physical world has led to an entire "throw away" society... and this was written in 1974! Imagine what Robert Pirsig would think of today's society.
What does any of this have to do with High Reliability Organizations and Root Cause Analysis? Well, I believe many leaders treat their organizations and operations similar to John Sutherland. As long as the bike starts up when they push the start button, runs down the road without problems, and stops when the brake is pressed, then who cares how it really works? Who really wants to know all the details of the inner workings of the machine? If something goes wrong, just send it to the specialist mechanic. The mechanic will diagnose the problem and then explain what needs to be done using some mechanical and engineering jargon that the owner doesn't understand. The owner will nod his or her head and just hope it doesn't cost too much. They don't really want to know what a connecting rod or valve stem guide seal does or how they make the engine work. Just get me back on the road please.
That's how some leaders treat their operations and the organizations they lead. When they have a problem, whether it is safety or productivity, they hand the problem over to a specialist to do "Root Cause Analysis" and determine what to do. The specialist uses specialized jargon concocted by the Root Cause Analysis method creator and after a lengthy deliberation they send back a long report that is usually glossed over and filed with little follow up because the Operational Leader has already moved on to the next "fire" they need to put out. Very few lesson are drawn from the issue and the corrective actions to prevent recurrence are many times lost for lack of follow up. Months later, the leader finds herself wondering why we had another incident just like the last one. "Didn't we have this problem last quarter? I thought we fixed it."
Now before I start getting nasty comments from the creators and owners (and sellers) of these Root Cause Analysis programs (and I personally know a few of them), I want to say these programs do have great value. They are useful for putting a structure in place for complex, complicated, large incidents that involved a fatality or large costs. These incident investigations require a sophisticated approach and therefore a sophisticated framework to conduct a thorough and proper investigation. Some incidents are large enough or complex enough that require this approach. If Robert Pirsig threw a connecting rod through his engine block, he did not have the tools to cast or repair an engine block on the side of the road and would have turned to a machine shop for that. There are some incidents that require specialists with experience and the right tools. Same with major incidents. I get it.
But those type of incidents, hopefully, are few and far between compared to the daily and weekly near misses and mishaps that can be leveraged with a "fit for purpose" root cause analysis approach. Instead, operational leaders tend to miss the opportunity to learn from a small mishap because they don't have a process to quickly get to the root of what happened and fix it.
What we have seen with our clients and what we lived in the submarine force was a different kind of root cause analysis. In fact, I am going to stop calling it root cause analysis so some people don't get their undies in a bunch because maybe it's not "pure" root cause analysis. Let's just make up a name...c'mon, everybody is doing it...
I will call our program SORTS: Simple Operational RCA in less Time Solution... okay yes I know it still has Root Cause Analysis in there but now I can hide it, sorta. SORTS...see what I did? I am not very clever, sorry. The right side of my brain never fully developed. Damn those engineering classes.
This SORTS process is what was used by submarine leadership teams at least during the two decades I served and as far as I can tell it was the method going back to at least the early Rickover days and I hope is still being used. We have modified it a bit for our clients and actually added some structure to help people who are first learning it. Over the last 4 years we have taught our clients how to implement it with great results. As we work with clients and watch their results, we improve the process.
The search for quality is not dead. Robert Pirsig was not born with the ability to repair his motorcycle engine. He failed at first when he tried to make minor repairs and adjustments. He learned. He made mistakes. Learned more. It was a journey and he took it one step at a time.
Are you on the same journey? Are you searching for QUALITY?
Me, too. Let's go
Bob Koonce served for over 20 years in the U.S. Submarine Force and retired from active duty in 2011 after commanding USS KEY WEST (SSN 722), a nuclear submarine based in Pearl Harbor, Hawaii. Bob frequently speaks and writes on Operational Excellence and High Reliability Organizations based on the leadership and culture of the U.S. Nuclear Navy. He is co-author of Extreme Operational Excellence: Applying the US Nuclear Submarine Culture to Your Organization available here. You can learn more about High Reliability Group by visiting www.highrelgroup.com.
You can join Bob for a course on the SORTS process in June 2020. See details at www.highrelgroup.com/courses
President and CEO at PAC Stainless Ltd.
4 年Thank you for the plug on a great book. The path to getting an organization to go deeper into problem solving and finding root causes is to first uncover or unmask the explicit and implicit signals of problems or dysfunctions (you don't wait for the accident). Too often organizations throw overtime at an issue and consider the problem properly solved when the product or service is delivered on time and the customer is satisfied. Developing a culture of Quality engages the teams into behaviors and attitudes that help build reliability. I ran a plant in country where I had to notify unions three business days in advance and by registered mail that overtime was needed, and that we had to meet to get their approval. Needless to say... managing Quality proactively was essential.
Building Brands with People-First Strategies, Delivering Results with Passion & Precision, and Empowering Sales at Every Aspect of the Funnel
4 年Like: “Damn those engineering classes.” On the flip side, I did understand my architect last week when he started describing a moment to me.
Trainer, Educator, and Coach
4 年Not RCA but AAR. There’s something about learning how to learn, to share, and to improve. https://hbr.org/2005/07/learning-in-the-thick-of-it
"Good writing is good thinking."
4 年Anyone who spent that long in subs gets my immediate attention. There is a great line to the effect that the craftsman shouldn't fall in love with his tools.
Senior Systems Engineer at Raytheon
4 年Thanks for another fine article, Bob. Your critique is spot on - with RCA it is sometimes "simpler" to get fixated on the tool and all of the bells and whistles it provides for picking the problem apart. Unfortunately, if you think first of the tool and what it can accomplish, you may lose sight of the underlying reason for seeking root causes. A simpler approach to narrow the problem space may be all that you need - or maybe all that you can address - at a certain level of process capability. Like motorcycle maintenance, fix what is within your grasp, learn from that, and expand your grasp.