December 7, 2009

A Design Failure Mode and Effects Analysis (FMEA) is a way to identify potential failures in a product and document the risks associated with these failures. The FMEA is also used to prioritise action plans that can be put in place to reduce the potential failures. Design FMEAs should be used throughout the design process - from the initial design to when the product goes into production. Design FMEAs identify failures associated with the product that could cause product malfunctions and or shortened product life as well as to address issues which may hinder a successful production process.

For the document to have the most impact, we should assemble a diverse team comprised of the product's design engineers, key process engineers, the project manager, and representation of the customer's requirements and/or marketing information.

Now let's talk about the Design FMEA's columns and their content. For the purpose of this discussion, we'll consider a layered desert cake as our product.

Item / Function - List all key features of the product being designed. For each feature, list all functions that feature offers. Usually an engineering drawing is used to ensure consistent language throughout and that all key features are noted.

Example: Using the cake example, "Layer of jam" should be listed as an 'Item' for a cake.
The jam's function "Provides adhesion between top and bottom layer of cake" should be listed as a 'Function' of the jam in our FMEA.

Failure Modes - This column identifies possible ways the item does not perform its function. In most cases, this column is the "opposite" of each of the functions or requirements from the previous column.

Example: In our example, "Does not provide adhesion between top and bottom layer of cake" should be listed as a 'Failure Mode' of the jam in our FMEA.

Potential Effects - This column answers the question "What is the result should the failure mode happen?�

Example: "Top layer will slide off bottom layer" should be listed as a 'Potential Effect' of the jam in our FMEA.

Severity - Prior to beginning the document, your team should agree on a numeric severity ranking scheme (usually a scale between 1 and 10 is used). Although it is not necessary, it is good practice to rank each effect as you go. The highest severity value for the listed effects is the value that should go in the severity cell to the left of the related effects. Low numbers signify less severe effects while higher numbers would indicate more severe or very severe effects (often safety related).

Example: Because we feel our customer experience is key, we ranked the effect as an "8" on our scale.

Class / Criticality - If the current feature is a key feature in the product design or related to safety, it should be noted with a symbol in this column. Also, if the failure mode has an adverse effect on the 'process', it may be worth noting here for special consideration in implementing the production process and noting in subsequent documents.

Potential Cause - This column is used to brainstorm what may cause the failure mode. Use of other tools such as 5-Why or Fishbone analysis may be useful for determining all potential causes.

Example: "Jam that was selected does not spread evenly" could be a cause of the jam not adhering the layers as intended and so is noted as such in the 'Potential Cause' column dFMEA.

Occurrence - A numeric scale (usually between 1 and 10) should be used to rank the likelihood of the Potential Cause actually happening. This could either be based on previously recorded data or an "educated guess". A low Occurrence number signifies a cause that is not very likely to happen. A high number is given to causes that are almost certain to happen.

Example: In our example, we said that perhaps the jam used does not spread evenly could occur rather frequently so it was given a "5"

Control Prevention - This column is used to list how you plan to prevent the Potential Cause from occurring.

Example: This may be a new design for us so a "Variety of jam types will be used to determine one with best consistency" for the design and we'll note this in the 'Control Prevention' column.

Control Detection - This column is used to list how you plan to detect if the Potential Cause has occurred. Detecting a failure may be more expensive than preventing the failure as detecting it means that the it has already happened and may result in scrap, rework, etc..

Example: "Prototype validation testing" will be used in our example so we'll note it in the 'Control Detection' column.

Detection - Numeric detection ranking should be applied to all of your Prevention and Detection methods--with lower numbers given to better detection methods and higher numbers given to less effective methods.

Example: In our example, we are only able to detect the failure at the prototype validation stage which may require a design change so we've noted this with a ranking of "5"

RPN (Risk Priority Number) - This number is simply the multiplication of the Severity, Occurrence, and Detection ranking for the row. Your document should have one RPN value for every Potential Cause.

Example: In our example, a Severity ranking of '8', Occurrence of '5', and Detection of '5' yields an RPN of 200 (8x5x5=200).

At this point, it is good practice to review your document and select the areas which should be improved. This is usually done by analyzing RPN values, using Pareto Charts, and identifying areas with high severity rankings. The next columns on the FMEA are used to document actions needed to address these areas.

In our example document, '200' is quite high when compared to our other RPN values. So we've addressed this with actions and re-evaluated the risk following the completion of those actions. The next few sentences explain how that was documented.

Recommended Action - This column is used to document the action(s) which will be completed to attempt to reduce the Occurrence or improve the Detection methods. Severity rankings are usually only able to be decreased through design changes which eliminate or reduce the related effect(s).

Example: In our dFMEA, we'll be looking to reduce the occurrence and improve our detection by "Selecting jam that is thin enough to spread evenly and adding it to Approved Ingredients List".

Responsibility & Target Completion Date - Specifically identify who (or which team) is responsible for completing the Recommended Action and by when the action should be complete.

Example: In our case, the head chef will be responsible for selecting the best jam.

Action Taken - Once the action has been completed, document what actually took place and re-evaluate the Severity, Occurrence, Detection, and RPN after the action was completed.

Example: Selected the jam and adding it to the Approved Ingredients List, reduced the frequency which and improved our prevention methods. However, we were not able to change the Severity of the effect by selecting a jam and adding it to the list because, even if it is rare, if a customer's cake does not stay together, it is still just as severe of an effect as before.

It is important to follow up on open actions. Once the actions have been completed, incorporate the lessons learned from those actions back into the document. Then re-evaluate the RPN and Severity numbers and repeat the Recommended Actions steps to improve your product.

QA Assistant Studio™ makes it easy to format the borders, helps ensure the document language is consistent, analyze the document's data, and track the recommended actions. You will save as much as 80% of your current time spent creating and managing this documentation. The exmple document (which you may download using the link above) was created in about 15 minutes using QA Assistant Studio™ and was exported to Adobe PDF in just one click!

Now that you know how easy it is to complete an FMEA and understand what needs to go under each column, why not try it yourself?