Failure Modes and Effects Analysis

Failure modes and effects analysis (FMEA) is a simple, cheap and systematic way of previewing your ultimate deliverable (product, process etc...) in terms of how it might fail.

In all projects people will naturally be trying to produce a high quality output but failure is usually only discussed as a reaction to a proposal.  E.g. If some one suggests putting a flag on top then some one else might suggest that it will get knocked off when you go through a tunnel.

The other time failure crops up in an intuitive project process is during 'testing' when testers will try and dream up scenarios where failure might occur.  This can be effective but changing things at the end is a lot more expensive than at the start.

FMEA actively and systematically anticipates failure in the design and planning stages  when changes are cheap.   The process involves a number of meetings in which failure is discussed and recorded in a prescribed format.  Naturally it can not catch all possible failures but the ones it does catch will save money and increase the quality of the final output.

The mechanism of FMEA is simple.

1. Block Diagram

Create a block diagram of all the components of the product.  Draw annotated lines between the components to represent linkages where they exist.

2. Use Cases

Create a list of all the possible uses to which the product might be put.  Notice that this should include uses not intended by the designers; people will still return stuff (or sue you) even if they did not use the product or process properly.

3. Failures

Using the use cases as a starting point list all the possible failures that might occur for each component in the system. E.g.

The buffer could get full.
The skin could brake.
The canister could explode.

For each failure trace thru the effects on all the linked components dependant on that component and record these as well.

4. Causes

For each failure list all the possible causes of that failure. E.g.

Blockage in the down pipe.
Hit too hard .
Exposed to sunlight.

Also look at the chain of components feeding each failure and consider what failure in that component might cause the failure in the dependant one.

You might notice an ambiguity between failures and the causes of failure.  Failure in one component could be the cause of failure in another.  Don't worry about this. By working forward (consequences) and backwards (causes) from each failure you identify the complete causal chain regardless of weather you originally identified something in the start, middle or end.

5. Results

For each failure specify the negative impact on the end user.

6. Rationalize

By now the whole thing could be quite a rat's nest so spend some time rationalizing it. Identify all the causal chains so you can clearly see what initial cause led to which ultimate impact on the end user.  You should end up with a list of initial causes each of which leads to one or more end user results via a tree of components.

7. Probabilities

For each initial failure list

the likely hood of it occurring
the chance of it being discovered during testing

For each end user result assign a value which indicates the severity of its negative impact.

Multiply all three things together and deal with the failures with highest values first.

The use of probabilities is a bit uncertain but it prompts discussion and it gives you some kind of metric.  The key to this system is not the numbers it is the quality of the discussion which identifies possible failures and their consequences.