Introduction to RCA

Root Cause Analysis (RCA) as a structured business analysis methodology has been in vogue for quite some time, and used for problem-solving in organizations in diverse industries.

This approach towards problem-solving takes a holistic view of the problem, rather than tinkering with its manifest symptoms. A typical knee-jerk reaction in most management situations is to temporarily repair, rework, redesign, modify or fortify things so that the
problem is "dealt with" at the earliest and with the least damage -till the next time. There is no guarantee that the problem will not
crop up again.

RCA, on the other hand, looks at the underlying, first-principle,
cause(s) that cascaded into a cause-effect-cause chain, culminating
in the cropping up of the problem. This approach, if handled in a
structured and professional manner, can result in totally
eliminating, or at the least, minimizing the recurrence of the
problem. RCA, thus, is not a corrective process, as much as it is a
preventive process.

Broadly speaking, RCA takes the problem-solver through the
following stages:

• Collection of information that surrounds the problem – this
  could include the actual broken-down equipment in a manufacturing
  scenario, or the letter of cancellation of a near-confirmed order
  from an important customer. In the case of a jet-crash,
  information collection would include scouring the rubble for the
  black-box device that contains audio recordings of the cock-pit.
  Personnel who are directly or indirectly a part of the process are
  also viewed as a source of information. This collection has to be
  as objective as possible.
• Analysis of the information. There are various methods using
  which the information available above is analyzed & the root
  cause(s) uncovered. These methods include, but certainly are not
  limited to, the following:
  • Events & Causal factor analysis
  • Change analysis
  • Barrier analysis
  • MORT (Management oversight & risk tree)
  • HPE (Human performance evaluation)
  • Kepner-Tregoe analysis

• Suggesting solution(s) that will resolve the problem either
  permanently, or minimize its recurrence. A few experts go a step
  ahead and also include implementing the solution(s); collecting
  feedback, and fine-tuning the analysis further, if required.

Inherent subjectivity in RCA & Software Design

Simple though the above stages sound, there are quite a few
pitfalls that an analyst adopting this methodology may fall into,
most of which are related to preconceived notions about the problem
at hand, coupled with a tendency to short-circuit the process. For
instance, while collecting the information and proceeding with the
analysis, the presence of a dominant personality might skew the
direction of the investigation in an altogether undesirable
direction. This could result in not all root causes coming to light.
Similarly, some of the analysis methods can take up a lot of time and
effort, resulting in a perception that the solution is costlier than
the problem it was trying to solve.

It is with this backdrop, therefore, that the complexity inherent
in deploying software that would assist an analyst in investigating
root causes should be appreciated.

BENCHMARK METRICS FOR SOFTWARE

There are quite a few vendors that offer software for the purpose
of conducting root cause analysis – PROACT, REASON, Tap-Root,
PHA-PRO, Apollo are a few of the well-known ones. Each of this
software has its own pros and cons, and one may be more suited over
the others in specific contexts.

The ideal software that purports to take its users through the
process of root cause analysis should also be a learning tool for
novices of this methodology. It has to be borne in mind that the
people who would be using the software are experts in their chosen
fields and part of the process where the problem is manifested, but
may not be trained in the discipline of Root Cause Analysis. Both the
inductive line of thinking – features in the software encouraging
creativity & brainstorming – and the deductive line of thinking -
the software on its own strength, prompting and cueing at the
appropriate stage, which the users can select – would help in a
comprehensive solution be arrived at.

Further, in order for the software to justify itself, it has to
succeed on the following parameters:

• It should reduce the time required in the analytic
  process;
• The validity of the process should increase through
  consistency in procedures; &
• Facilitate in data collecting, analysis and presentation.

And, of course, the software has to be flexible enough to allow
its analyses to be generated in as any formats of reports as
possible.

A precaution that users deploying such software should bear in
mind is that the set of conclusions that are arrived at, as an
end-result, must be credible and thorough. For this purpose, it may
be pertinent to even document all the causal factors that have been
left out of the analytic process, with details of their impact having
been explored (or not explored, as the case may be).

Perhaps, a benchmark for appraising particular software would be
to take up an already-completed root cause analysis case and use it
as a guide to work through the software. This allows a realistic
assessment of how aligned the underlying logic of the software design
is, with human thinking.