Jump to content
  • 0

Go to solution Solved by vishwadeepak.choudhary26,

Risk Priority Number (RPN)


Risk Priority Number (RPN) is a numeric assessment of a risk to help identify critical failure modes in a process or a design. It ranges from 1 to 1000. It is calculated while doing Failure Modes and Effect Analysis using the below formula 
RPN = Severity (S) x Occurrence (O) x Detection (D). 



An application oriented question on the topic along with responses can be seen below. The best answer was provided by Vishwadeepak Choudhary on 24th August 2017. 




Q. 86 This question refers to FMEA and has reference to the following link - 



As per part of our November’17 Episode, in Q51 at the link above, we discussed the limitations of FMEA as a technique for Risk Assessment. In FMEA for each failure, we calculate a Risk Priority Number (RPN) which is a product of severity of failure (S), the likelihood of occurrence (O), and difficulty of detection in advance (D). These RPN values are used to rank the failures to eliminate/reduce risk, starting with the one with the highest RPN. Other than subjectivity involved in assigning a rating, what according to you are the limitations of using RPN values?


Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.


Link to post
Share on other sites

7 answers to this question

Recommended Posts

  • 0
  • Solution

A deep intrinsic problem with FMEA is how we calculate RPN (Risk priority number) by performing a mathematical operation on three ordinal scale data. Severity, occurrence and detection are purely ranked numbers and we never get to see the absolute difference between two ranks so any mathematical operation like addition, subtraction or multiplication don’t hold true however they can definitely throw a mathematical number. We calculate RPN in the similar fashion and then use this number to prioritize risks. Moreover, three building blocks of RPN are not on the same scale. They have different priorities in different organization. Severity should definitely be considered of top most importance. Let’s look at a scenario. We will try to calculation RPN for two earthquakes with different magnitudes. One at Richter scale of 2.0 and another at 6.0.

1.       Richter scale 2.0 earthquake:

Severity = 2 (as per Richter scale reading)

Occurrence = 5 (assuming that this occurs very often)

Detection = 4 (we would use same detection for both scenarios)

RPN = 2 * 5 * 4 = 40

2.       Richter scale 6.0 earthquake:

Severity = 6 (as per Richter scale reading)

Occurrence = 1 (very less frequent)

Detection = 4 (we would use same detection for both scenarios)

RPN = 6* 1 * 4 = 24

If we simply go by prioritizing risks as per RPN, then the first risk would get prioritized however practically that’s a lot safer than Risk 2. Richter scale 6.0 earthquake is rare but if it occurs for once, it’s a disaster. The RPN calculation doesn’t take care of such individuality which makes a great sense in practical scenarios.

One way to overcome above problem could be to use weighted count method for calculating RPN. Severity should get highest weightage (may be 3), followed by Occurrence (may be 2) and then Detection (may be 1). Let’s redo the above earthquake scenario and we would call our metric as Weighted Ordinal RPN (WO-RPN).

1.       Richter scale 2.0 earthquake:

Severity = 2 (as per Richter scale reading) – we would consider it as count 2 and multiply it by weightage 3: gives the value of 6

Occurrence = 5 (assumption that this occurs very often) – Weightage 2, so count gives 2*5 = 10

Detection = 4 (we would use same detection for both scenarios) – Weightage 1, so count gives 1*4 = 4

WO-RPN = 6+10+4 = 20

2.       Richter scale 6.0 earthquake:

Severity = 6 (as per Richter scale reading) – Weightage 3, count = 3*6 = 18

Occurrence = 1 (very less frequent) – Weightage 2, count = 1*2 = 2

Detection = 4 (we would use same detection for both scenarios), Weightage 1, count = 4*1 = 4

WO-RPN = 18+2+4 = 24

And this weighted ordinal RPN brings second risk as top priority which is the cause of the concern.

I welcome your thoughts on this subject further.


Link to post
Share on other sites
  • 0

I wouldn't want to go back to the points that have already been covered by various Excellence Ambassadors for the previous question relating to the limitations of FMEA. Here  i will limit my discussion to the limitations in the usage of RPN.


1. The most known aspect while using RPN number is that even if we may rank the priorities based on descending order of the RPN, the severity has to be given very serious attention. 

Lets examine the below 2 scenarios:


Severity 10 refers to Hazardous effect without warning

Severity 4 refers to low effect such as fit / finish issues that may not impact functionality or safety.

Occurrence 3 refers to low frequency such as 1 in 10000

Occurrence 7 refers to high frequency such as 1 in 100

Detection 3 refers to controls having good chance of detection

Detection 8 refers to controls having poor chance of detection


In the above case, prioritizing scenario 2 over 1, just based on RPN number may be disastrous.


2. Often, it would be difficult to obtain the reasonably correct rating numbers for occurrence. Especially when we are dealing with new product / processes, relevance of arriving at occurrence ratings based on existing processes may have limitations. Another risk would be that the occurrence frequencies would have been based on the data for a particular period, but in reality the occurrence frequency for a particular cause could change and alter our risk prediction and priority.

3. Where detections have a human dependency there is a possibility that when the occurrence for a particular cause becomes very low, there would be chance for reduced human alertness and actual detection could be lower, though a low score might have been assigned to it.

Link to post
Share on other sites
  • 0

What is RPN ?

Risk Priority Number , known as RPN, in abbreviated form, is a product of the values laid out by three factors viz., Severity, Occurence and Detection.


Why RPN is needed and how is it used ?
RPN prioritizes the risks, that are specified through the FMEA technique. In a typical project scenario while using the FMEA technique, where RPN is the deciding factor in addressing the risks , a risk with a higher RPN value is placed above the risk with a lower RPN in the Risk Register of a project. The Risk with the highest RPN value is the most sought after risk to be addressed and the risk with the lowest RPN value is the least sought after risk for addressing. Advantage of having RPN is that we are able to quantify the risks (with a numerical value which is easier to portray to any interested stakeholder) . Having said that there are some constraints/challenges in the usage of RPN, that need to be taken into account, which we shall discuss now.     


What are the challenges/Limitations in RPN
In my view, there are quite a few challenges that i would like to highlight.


1. Arriving at RPN (value) requires a bit of experience in usage of FMEA technique. Having an incorrect RPN list may result in picking a lesser risk first than a much more important risk.In quite a few industries, SMEs might be there to define the RPN values.


To elaborate more on this : Rating scale for the three factors Severity, Occurence and Detection would be from 1 to 10. But the specified value for each rating(1-10) can vary from Organisation to Organisation.Using RPN, requires bit of experience. So a lesser experienced person(in terms of FMEA technique usage) in a team, may not

provide the right RPN simply  because he/she might misinterpret or cannot take into consideration the impact/probablity of a risk and therefore can choose the right severity or Occurrence or detection factors. Putting a wrong or indifferent RPN value can make the risks incorrectly prioritised. Therefore some experience is required

in FMEA technique for a person to effectively prioritize the risks.    


2. RPN will require recalibration over a period of time. Hence its a moving value as risk prioritization would invariably keep changing based on the severity, occurence , detection factors and also the ability of the team/organisation (involved/affected in/by the risks) to address those relevant risks. Therefore constant monitoring of the RPN value is needed.


To elaborate more on this : For instance, in the beginning/initial phase of a IT testing project, there may be quite a number of risks, such as a non availability of separate testing environments for System Integration Testing (say , for the testers of service providing company) and User Advanced Testing(Customer testing) but that

as the project progresses that risk might have been addressed/mitigated or a timeline would have been known for that to be resolved. Or there could be a particular feature/functionality which cannot be done by using a specific technology or there could a niche-skill for which a resource might not be available at a given point of

time. These sort of issues could be addressed by replacement technologies/making use of a specialized human resource (for the niche skill) for a particular time and thereby mitigate that risk. In such cases, the RPN value gets recalculated as the addressing/mitigating of the risks modify the values of the severity or occurrence



3. Calculating RPN value is time-consuming and slightly complex. Why ?


To elaborate more on this : Apart from the fact that this requires an experienced person who is well-versed in using FMEA technique, its also needs to be calculated multiple times (frequency of which depends on factors such as risks getting addressed, efficient addressing of risks, and so on...) . Its always an ongoing process.  


In general , the structure would be that RPN is calculated first , during the "AS-IS" state (when it is calculated before we act upon the RISK associated with our activities - project or wherever you apply the Risk Mgmt through FMEA) and next, when it is calculated after we act upon the RISK. As mentioned in #2, because this is a moving value, its imperative that you need to know the RPN values for both "AS IS" (Existing one when you are yet to address the risk)  and the "To-Be" one which ideally would be the state when existing risks are addressed.  This RPN calculation activity would keep happening and due diligence need to be given for this critical



In a typical six sigma project, the Measure phase would have the "AS IS" state (RPN value)   and in Analyse/Improve phase, the RPN value might vary after actions are being established/put in place.  


Conclusion : We saw the need for RPN in FMEA technique and we also saw the challenges/limitations that it provides. Using RPN requires a bit of expertise and prior knowledge to get the right prioritization of your risks. RPN can also challenge a person's thought process on cases, where the RPN for two or more risks have identical (equal)  

RPN value. In such cases, we need to have threadbare analysis of those risks (with the same RPN value) and see which should be picked first. The 3 factors- Severity, Occurrence (Frequency) and Detection factors will come into play. With a proper experience cum expertise, and with right set of actions, such risks and all other risks should be addressed effectively and efficiently. RPN would be an effective tool if the right combination of team and expertise is available within the teams, in an organisation.  


Link to post
Share on other sites
  • 0

Most of the times, the idea will be to reduce RPN number by addressing any of the S, O or D. The limitation of RPN is that it does not specify which of the factors has more weightage. It is not a weighted value in true sense. As an example, during FMEA review of a parameter if the person / people working on it decide to give ratings of 8 for S, 5 for O and 1 for D, the multiplication still results in a low number of 40. In most organizations, RPN above 100 is considered as priority. In this case, Irrespective of having high severity and 50% probability of occurrence, this parameter may not be addressed at all.

The 2nd limitation is that occurrence and detection of a fault is downstream in a process which means that though the fault exists, the question of addressing the fault is pushed to the downstream process to handle it. For example, in DFMEA of a component, O and D of a fault is pushed to manufacturing or field to manage it. In PFMEA of a mfg process, O and D is left to end of line quality check. It should in fact point to the process for weeding out or addressing the fault instead of pushing the fault detection downstream.

Link to post
Share on other sites
  • 0

Severity, occurrence and detection are subjective while calculating RPN values. RNN values by itself will not mitigate risk.

There is no definitive RPN threshold to decide the area which to looked into.There is problem in regrouping the team for assessment of process RPN for before and after results. RPN values may be biased in some cases and if detection cases are not detected frequently then there will be no meaning to calculate RPN values and FMEA may not be effective to create a corrective of preventive action.

Link to post
Share on other sites
  • 0

This is a very difficult one to answer for me as I have always been a follower of the concept of quantifying all measures and criteria including Risk and its priority. To me, it is as difficult as trying prove that the sun rises in the west.


It is very easy to criticise any measure as being academic including the Risk Priority Number. The RPN by definition has already captured the most relevant features of risk in terms of whether it would materialise at all (Likelihood), if mateialised, whether it would matter at all (Impact) and if it is possible to have an advance warning (Detectability). Then is there any feature of Risk that is not covered in the RPN? Nothing that atleast I am able to think off.


Is it difficult to calculate and use the RPN? The potential problems in calculation has already been de-scoped from the question as, "other than subjectivity in rating". Therefore, there does not appear to be any other problem in calculation and use of the RPN for prioritising Risk Treatment Actions.


One problem related to group dynamics when assessing risk rather than the RPN per se, is that in a cross-functional team, it may be a bit difficult to get a very diverse group to converge on a view that is converted to a rating. As a result, when a potential risk is assessed and the likelihood, impact and detectability are discussed and rated, some participants may not feel quite satisfied with the conclusion as they would think that this is not what they had in mind or what they had expected. Ofcourse, not all participants would have the same or similar experience, especially in risk assessment.


Can only conclude that despite my best efforts, am unable to really fault the RPN on any account except the possible subjectivity in rating, which (thankfully) is out of scope.



Link to post
Share on other sites
  • 0

It is great to see detailed answers for a question on a tool deemed as complex by many Six Sigma experts. The question sought answers to what apart from subjectivity in the rating scale is the limitation with using RPN. Most answers bring out one key point that RPN does not draw your attention towards the severity number. This is explained very well in several answers - hence making it complex to choose the best answer.


Breaking the tie is the "suggested treatment" to this limitation which is provided by Vishwadeepak Choudhary, hence chosen as the best answer. I do recommend everyone reading all the answers to get a well rounded understanding.

Link to post
Share on other sites
This topic is now closed to further replies.
  • Who's Online (See full list)

    There are no registered users currently online

  • Forum Statistics

    • Total Topics
    • Total Posts
  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
  • Create New...