* The Risk Priority Number (RPN) is calculated by multiplying together the values of the severity, occurrence, and detection risk assessment
* The RPN provides an indicator of the relative seriousness and priority of each failure mode. The higher the RPN, the more relatively serious is the failure mode.
RPN = Severity x Occurrence x Detection
Although some FMEA instruction manuals say the RPN values are used to rank and compare the seriousness of failure modes, the scoring is actually done for each cause. The Corrective/Preventive Actions will be generated for the higher priority causes. The purpose of generating the RPN scores is to prioritize for which causes there should be Corrective and/or Preventive Actions developed and completed.
Note: the absolute values of the RPN do not mean anything. As long as you are consistent in applying the criteria, then their RPN scores can be used
for relative ranking and prioritizing of the causes and their actions within the project. It is notadvised to compare/rank actions between projects from separate FMEAs unless the teams followed the same ranking criteria scales, and did so very consistently.
* The Recommended Corrective/Preventive Actions for the root causes of the prioritized failure modes should be described specifically and briefly.
* The intent of any recommended action is to reduce the severity, occurrence, and then detection rankings.
* It should be stated in a positive way, e.g., “Increase spring wire diameter by .001 in.” or “Conduct trials to identify the optimum annealing method” or “Develop a more robust engagement tab design”.
To reduce a severity ranking, a design revision will be required. A design revision will also be required to reduce an occurrence rating, by removing or controlling one or more of the failure mode’s causes. Increasing DV actions only is not as desirable since it does not address the severity or occurrence of the failure mode.
The solutions should either be based on data, or they should call for a trial or investigation to generate the necessary data for determining the best solution(s) to solve the root causes. One of the risks in the FMEA process is for the team to generate Corrective/Preventive Actions that are not proven with observed data. The Actions should end up calling for revised tolerances, specifications, etc.
The responsible party should usually be someone on the project team, even though the person(s) actually doing the tasks may be someone else.