Featured Product
This Week in Quality Digest Live
Standards Features
Harish Jose
Using OC curves to generate reliability/confidence values
Phanish Puranam
Instead of blindly adopting industry best practice, companies can pilot new organizational designs
William A. Levinson
All is not gold that glitters
Grant Ramaley
IAF CertSearch now mandatory for accredited certification bodies
Megan Wallin-Kerth
MasterControl’s Matt Lowe talks competition, data, and what quality does for a company

More Features

Standards News
June 6, 2023, at 11:00 a.m. Eastern
Ensuring product consistency, quality, and adherence to federal and state standards
Omnex webinar on May 11, 2023
Digital Twin Consortium’s white paper guides strategies for building owners and stakeholders
Copper, titanium, and 304L stainless-steel powders from Desktop Metal have qualified for production
Webinars cover Automotive SPICE and carbon neutrality standards
Creates one of the most comprehensive regulatory SaaS platforms for the industry

More News

Denise Robitaille


Root Cause Analysis: Helping Us Understand Why Things Go Right

Why not use investigative tools to discover the cause of success?

Published: Wednesday, March 23, 2011 - 05:30

Every once in a while when I’m conducting training, I have the good fortune to have someone ask a particularly atypical question that gets me thinking and helps me to develop more tools and techniques. This serves to not only augment my own bag of tricks but also increases my capacity to serve my clients.


A few weeks ago during a training session on root cause analysis, one of the attendees asked: “Can we use the same technique to figure out why something worked really well?” My initial reaction reflected my skepticism as I responded with a lukewarm: “I suppose….” I had occasionally taught people how to use some of the tools to assist in preventive action. “What would cause something to go wrong—and what would cause that?” But this was different.

The gist of the conversation posited the possibility of using investigative tools to understand the cause of success. The more we talked about it, and later on as I thought about it some more, I concluded that the idea made perfect sense. Why not use the same thought process to understand why processes run smoothly and with minimal error or problems? Comprehending the nature of a process and the factors that contribute to its effectiveness should provide insight and increase the likelihood of being able to replicate desired results.

Two of the most powerful tools we can use for root cause analysis are flowcharts and the fishbone diagram. A flowchart allows us to understand the flow and sequence of a process. By looking at a stable (i.e., effective) process, we can perceive both the steps that must be taken and the sequence in which activities must be performed. We can observe the specificity of information provided for each step and the efficiency that may be inherent in the sequencing of activities. The points at which verifications (e.g., tests and inspections) occur are also denoted, providing information on the in-process controls that may mitigate errors. We can see if the sequence is the result of a well-designed work area that optimizes space and minimizes travel time between various steps. We can note the influence of good planning or rigorous and elaborate scheduling.

With a fishbone diagram we can look at the six traditional elements of a given situation: material, manpower, machinery, method, measurement, and environment. The extent to which we define, control, and utilize each of these elements has direct impact on the integrity of a process. What did we do to ensure that we had the right material, in the right quantity, at the right location on time? Was this caused by good inventory management, fostering good supplier relations, prepping components before issuing them to the floor, or packaging them on trays for easy retrieval? How about manpower? What did the organization do to optimize the skills and knowledge of employees? How did we manage absenteeism to ensure all shifts and tasks had adequate coverage?

The same questions can be asked for the other four elements. What great things did we do that have contributed to our success? And, what prompted the decisions that directed us to select specific equipment, incorporate a particular methodology, or make changes to the work environment? Was this the result of some related data analysis, new technology, or employee initiative?

There’s no denying that it would also be useful to compare an optimal process with one that has bottlenecks, defects, and reworks. By understanding the difference between the two, we can figure out what’s wrong with the problematic process. But that really is looking at the root cause of a problem from a different angle.

This isn’t about comparing good with bad. It’s about scrutinizing our successes. We don’t give ourselves enough credit for our successes. And too frequently, we don’t understand why we succeed.

Despite the fact that we do develop plans, schedules, and work instructions, there are many instances in which there’s still a sense that our success is somewhat serendipitous. “If the parts arrive on time….” “If the first article inspection is approved….” “If the machine doesn’t jam….” “If there isn’t too much traffic en route to the field installation….” “If the server doesn’t crash….” We cross our fingers, stroke our lucky rabbit’s foot, and invoke the help of our chosen deities. And when everything falls into place perfectly, we thank our lucky stars. We often fail to ask. “Why did things go so well this time?” “What did we do, what plans did we develop, and what resources did we acquire that allowed us to achieve our goal?”

So, I guess using root cause analysis tools should help us understand why things go well. It should help us to understand what factors contribute to our success so that we can learn and make optimum use of that knowledge to bring consistency and sustainability to our success stories. We’re too eager to ask, “Why did something go wrong… and who should we blame?” instead of, “Why did everything go so well, and who can we thank?”


About The Author

Denise Robitaille’s picture

Denise Robitaille

Denise Robitaille is the author of thirteen books, including: ISO 9001:2015 Handbook for Small and Medium-Sized Businesses.

She is chair of PC302, the project committee responsible for the revision to ISO 19011, an active member of USTAG to ISO/TC 176 and technical expert on the working group that developed the current version of ISO 9004:2018. She has participated internationally in standards development for over 15 years. She is a globally recognized speaker and trainer. Denise is a Fellow of the American Society for Quality and an Exemplar Global certified lead assessor and an ASQ certified quality auditor.

As principal of Robitaille Associates, she has helped many companies achieve ISO 9001 registration and to improve their quality management systems. She has conducted training courses for thousands of individuals on such topics as auditing, corrective action, document control, root cause analysis, and implementing ISO 9001. Among Denise’s books are: 9 Keys to Successful Audits, The (Almost) Painless ISO 9001:2015 Transition and The Corrective Action Handbook. She is a frequent contributor to several quality periodicals.


Process and event Root Cause Analysis

In conducting various RCA projects, there has been a tendency to only use Dr Ishikawa's first Cause & Effect Diagram. Some even still use "Manpower" which many organizations including QCI International showed me to use "People" way back in the early eighties (thanks Don Dewar). Dr Ishikawa had three (3) types of C&E and as Denise's article correctly stated, that most use the "Event" C&E. However, Ishikawa (page 24 'Guide to QC' 1971) says the third type is the 'Process Classification C&E' - QCI called it simply Process C&E.  With so many problems/effects coming from the process (all work occurs through process aka P Cosby) and for Lean and Six Sigma folk think they invented 'SIPOC' - well I contend that most RCA's are sub-optimised if they do use Process C&E. Denise's article well describes the use of a 'diagram' like a C&E and can be said for Process C&E as to why something went well. Similarly for ISO9001:2008 folk and QMS implementations, they were meant to be documented by Processes and not by the Clauses of the Standard (ISO9001 2010 Forum is now recommending reinforcement of this for the revision under TC176) – all Lean, TOC, RCA, Six Sigma process analysis work and activities by individuals and teams should have started with diving into the said processes that should have been documented within these QMS’ – that is difficult if not written under the business processes. There is RCA fast tracking available if we go to the QMS Processes to do the “Should-Be” and then consider RCA for why the process is not stable then not capable, instead of pushing the As-Is and To-Be process analysis as yet another consultancy piece which when finished or Lean Six Sigma and RCA projects completed, are hardly embedded within the QMS process documentation. Many Organisational Change and Behavior lectures in MBAs use the Ishikawa Diagram not so much for the C&E but for why change worked and drivers for Change. A nice and timely reminder Denise as sometimes we get too stuck on strict use of some techniques and we should as Dr Ishikawa said "We should adapt then adopt these Tools and Techniques". See you in Australia again soon Denise, Michael

Michael W McLean Managing Director McLean Management Consultants Pty Ltd Embedding Strategic Change (Established.1988) PO Box 917 North Ryde BC 1670 NSW Australia M: +61 419 225 996 P: +61 2 9706 8566 F: +61 2 9706 8366 E:michael@mclean-mc.com.

RCA for Positive Events

As an international provider of RCA training and services, Apollo consultants address this question often.  Thank you Denise for bringing this to attention!  Problems are adverse events.  A good root cause analysis process analyzes the causes of any event, regardless of whether the outcome is deemed to be good or bad.  If you want more (or less) of an outcome, the only way to do it is by controling causes.  So RCA on positive events is a terrific idea.  A couple of things to consider:  1)  Managers should analyze causes of positive events.  But they should do a lot of things... and in today's lean employment environment, it's often hard to get them to analyze anything at all simply because they don't have the resources.  I would be interested in reading a case study where this was done successfully, including how the effort was sold to decision makers.  2)  The fishbone process may not be the best choice.  While good at identifying a range of causes, it comes up short in part because it doesn't do a great job at uncovering and documenting causal relationships.  Understanding these relationships is important because they show how/which causes interact to create effects.  This gives the investigative team better opportunities to come up with creative ways of controling those causes, as well as controling the way they interact.  Brian Hughes
Vice President
Apollo Associated Services, LLC
bhughes@apollorca.com, @brian_hughes