RCA – Past, Present, and Future (a three-part series) Part 2

  • warning: Parameter 2 to securepages_link_alter() expected to be a reference, value given in /var/www/sologic.com/www/includes/common.inc on line 2892.
  • warning: Parameter 2 to securepages_link_alter() expected to be a reference, value given in /var/www/sologic.com/www/includes/common.inc on line 2892.
  • strict warning: Non-static method view::load() should not be called statically in /var/www/sologic.com/www/sites/all/modules/views/views.module on line 879.
  • strict warning: Declaration of views_handler_argument::init() should be compatible with views_handler::init(&$view, $options) in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_argument.inc on line 745.
  • strict warning: Non-static method views_many_to_one_helper::option_definition() should not be called statically, assuming $this from incompatible context in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_argument_many_to_one.inc on line 36.
  • strict warning: Non-static method views_many_to_one_helper::option_definition() should not be called statically, assuming $this from incompatible context in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_argument_many_to_one.inc on line 36.
  • strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_filter.inc on line 589.
  • strict warning: Declaration of views_handler_filter::options_submit() should be compatible with views_handler::options_submit($form, &$form_state) in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_filter.inc on line 589.
  • strict warning: Declaration of views_handler_filter_node_status::operator_form() should be compatible with views_handler_filter::operator_form(&$form, &$form_state) in /var/www/sologic.com/www/sites/all/modules/views/modules/node/views_handler_filter_node_status.inc on line 14.
  • strict warning: Non-static method view::load() should not be called statically in /var/www/sologic.com/www/sites/all/modules/views/views.module on line 879.
  • strict warning: Non-static method views_many_to_one_helper::option_definition() should not be called statically, assuming $this from incompatible context in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_argument_many_to_one.inc on line 36.
  • strict warning: Non-static method views_many_to_one_helper::option_definition() should not be called statically, assuming $this from incompatible context in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_argument_many_to_one.inc on line 36.
  • strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /var/www/sologic.com/www/sites/all/modules/views/handlers/views_handler_filter_boolean_operator.inc on line 149.
Brian Hughes, Senior VP

August 16, 2017

This is the second part in a three-part series.  If you haven't yet, read Part One.

In my blog about RCA Past, I focused exclusively on the two most popular historical RCA methods:  1) The 5-Whys, and 2) The Ishikawa Fishbone diagram.  I discussed the fact that both methods are attempts to methodically discover the preceding causes of any event and that both do so via different branches of logic.  The 5-Whys employs conditional “if-then” logic and the Fishbone harnesses syllogistic logic (the logic of sets).  Both offer means of deducing causal predecessors with a degree of confidence.  

In follow up comments, it was pointed out to me that I omitted other methods that have been around for a long time such as Kepner Tregoe, MORT, and fault tree analysis.  I did not mean to imply that these were not historically important.  However, I did intend to focus on 5-Whys and Fishbone because they have propagated so much further in so many different disciplines and applications.

Now, let’s travel back three or four decades to the period of main-frame computers, pocket protectors, and ashtrays in the office.  Engineers at the DOE, NASA, and a variety of other organizations were working on problems of enormous complexity.  The failures were therefore equally complex.  But persistent failure was simply not an option, so they urgently developed, and utilized, what were at the time new ways of thinking to help manage this complexity.

Not surprisingly, they discovered deficiencies in these methods.  That’s because when we use something, we find out where it works as well as where it doesn’t.  Deficiency combined with practical application drives innovation and improvement.  And at that time, the field (if you could call it that) of root cause analysis was ripe for it.

Smart people like Mark Paradies, Dean Gano, Robert Nelms, William Corcoran, Charles Latino, and many others distinguished themselves first by being foot soldiers in the effort to solve complex problems using the available toolsets - and then by improving them once their deficiencies were exposed.  If the first round of structured problem solving models could be termed “RCA 1.0,” this next generation of innovators brought “RCA 2.0” to the world.  This led to many successful consulting companies, including Decision Systems (Taproot), Apollo, Reliability Center (Proact), Reason, and others.

Some of those that brought forth RCA 2.0 also forced RCA out of its initial isolation.  Naturally, a combination of causes was required for this to occur.  Probably the most obvious cause is that problems happen in every organization, not just nuclear power plants or rocket shops.  Hospitals have complex problems, as do chemical companies, utilities, and pharmaceutical companies.  Another cause was that RCA 2.0 innovators discovered they could develop a viable business model around teaching people their improved methods of RCA.  This provided a profit incentive to develop new markets.  I came into the business much later (in 2000) and remember an early conversation discussing what I did for a living.  After my explanation, the person (a lawyer) was amazed:  “You can make a living doing that?” she asked.  Indeed, I can (so far, anyway) – and I have the RCA 2.0 innovators to thank for it.

These RCA 2.0 consultancies were built on a simple business model.  It goes like this:

  1. You (no matter who you are) have problems
  2. Some of those problems are worth solving
  3. Any structured root cause analysis process solves problems better than none
  4. MY (insert your favorite) method of root cause analysis is better than the others

By the early 1990s, there was a burgeoning market segment for root cause analysis.  Consultancies specializing in RCA were now competing to develop new markets and win clients.  With a few exceptions there was very little open collaboration.  From a client’s perspective, the differentiators were communicated as “My method is totally different and vastly better!”  And while it’s true that there were differences, whether one was “vastly better” than another was subjective.  What can be safely said is that each of these methods was an improvement on its predecessor, and these predecessors were certainly better than nothing.  Progress!

As I mentioned above, I came to the RCA business in the latter half of RCA 2.0, which I’ll affectionately call the “Guru era” because each of the consultancies was still run by an RCA 2.0 guru.  They had written books, been referenced in documents, were recognized at conferences, cited in standards, and they argued ad nauseum on private message boards. Their companies and methodologies were (and in some cases still are) largely the embodiment of their personalities, and the other way around.

But by 2000, the information age started catching up with the RCA 2.0 consultancies.  Advances in programing languages and processor capacity made RCA-specific software possible.  RCA software was a major game-changer because it provided a new way to differentiate.  

It also brought a new set of risks.  Software is very expensive to create and maintain.  It’s also complicated.  And the Gurus weren’t programmers.  While they could write their own books and articles, they could not write their own RCA software.  Finally, the market was skeptical.  But with fits and starts, a few companies would knuckle through to develop the first round of RCA software applications.  This period of viable RCA software was the beginning of the RCA 3.0 era.

I was lucky enough to be at Apollo during the rise of RCA 3.0.  I experienced first-hand what it was like to go from a company who sold books, training classes, and consulting gigs to one that also developed and supported software.  Those at Decision Systems, Reliability Center, Kepner Tregoe, and Reason did it too – and while I haven’t compared notes with them, I’m sure their experience was similar.

RCA 3.0 also welcomed the addition of new competitors (like ThinkReliability) to the pool.  Some came from splits with existing companies, while others sprouted organically. We launched Sologic in 2011.  And there are a host of others that entered into the RCA market as well.  RCA 3.0 not only was characterized by RCA-specific software, but also by choice.  You could even say that the market became increasingly fractionated.  But one thing is certainly true – as time marches forward, acceleration of change will be the most important variable.  

Where will our little niche be in five years?  In the final installment of this series, I’ll discuss where I think RCA is headed in the not-so-distant future.

Note:  I hesitated to include names and companies in this entry, but then I did it anyway.  Want to add to (or correct) my take?  Feel free to do so in the comments below...

Post new comment

The content of this field is kept private and will not be shown publicly.