Page 25 - Root Cause Failure Analysis

16 Root Cause Failure Analysis
should be recorded and used as part of the investigation. In many cases, one or more
of the opinions will hold the key to resolution of the event. The following are some
examples where the initial perception was incorrect.
One example of this phenomenon is a reported dust collector baghouse problem. The
initial report stated that dust-laden air was being vented from the baghouses on a ran-
dom, yet recurring, basis. The person reporting the problem was convinced that
chronic failure of the solenoid-actuated pilot valves controlling the blow-down of the
baghouse, without a doubt, was the cause. However, a quick design review found that
the solenoid-controlled valves nomZZy are closed. This type of solenoid valve can-
notfail in the open position and, therefore, could not be the source of the reported
events.

A conversation with a process engineer identified the diaphragms used to seal the
blow-down tubes as a potential problem source. This observation, coupled with inad-
equate plant air, turned out to be the root cause of the reported problem.

Another example illustrating preconceived opinions is the catastrophic failure of a
Hefler chain conveyor. In this example, all the bars on the left side of the chain were
severely bent before the system could be shut down. Even though no foreign object
such as a bolt was found, this was assumed to be the cause for failure. From the evi-
dence, it was clear that some obstruction had caused the conveyor damage, but the
more important question was, Why did it happen?

Hefler conveyors are designed with an intentional failure point that should have pre-
vented the extensive damage caused by this event. The main drive-sprocket design
includes a shearpin that generally prevents this type of catastrophic damage. Why did
the conveyor fail? Because the shear pins had been removed and replaced with Grade-
5 bolts.

Event-Reporting Format
One factor that severely limits the effectiveness of RCFA is the absence of a formal
event-reporting format. The use of a format that completely bounds the potential
problem or event greatly reduces the level of effort required to complete an analysis.
A form similar to the one shown in Figure 3-2 provides the minimum level of data
needed to determine the effort required for problem resolution.

INCIDENT CLASSIFICATION

Once the incident has been reported, the next step is to identify and classify the type
of problem. Common problem classifications are equipment damage or failure, oper-
ating performance, economic performance, safety, and regulatory compliance.