The application of a root cause analysis is an effective way to solve problems that occur. Problems with complex sub-issues and causes make identification of an apparent problem difficult. For instance, one can use this method to solve problems related to delays in processing orders or missing orders in a customer order process with a well-defined process for accepting, processing, and shipping customer orders. The problem could lie in any of the many sub-processes, or an apparent cause of delivery tracks which are unable to track the orders properly, may have a core issue of poor software capability.
Not all problems, however, make for good cases. Identifying the root cause for a direct cause and effect problem is unnecessary and very often counterproductive. For example, the most expedient thing to do when faced with a leaky pipe is to fix the pipe rather than waste time trying to identify the underlying causes such as high water pressure or faulty design that caused the pipe to leak. Of course, identifying the root cause might prevent the leak from reoccurring, but is not the most expedient or appropriate situation. If the leak persists, even after repair, then it may make for a case of using the root cause analysis.
At times, cost-benefit analysis plays a major role. If the cost to identify and fix the root cause is greater than letting things be, then managerial expediency may require accepting the problem and working around it. Assume the root cause of delivery staff missing orders is the lack of software functionality to list pending orders. If the cost of adding the functionality to the software is greater than a quick-fix of simply asking the staff to note down all orders in a slip and destroy the slip as delivery takes place, then the root cause may remain unresolved.
At other times, this method may be unnecessary regardless of the circumstances. For instance, trying to identify the root cause for destruction to a data center caused by hurricane is foolhardy.
Systems-based organizations using automated problem resolution support systems such as SolutionBuilder can easily identify such problems, whereas for others, determining when to use a root cause analysis depends on subjective managerial decision making. Many companies leave the process to the committee that regularly monitors operations. As a rule of thumb one-off situation with minimal impact on customers or operations rarely require such an analysis.