Risk assessment using Failure mode and effects analysis

Revision as of 09:17, 19 April 2023

Author: Niels Peter Lindegaard - s194473

Abstract

Failure mode and effect analysis (FMEA) is a risk assessment tool used in project management. It is used to systematically identify and eliminate known or potential failures in complex systems to provide data and information for risk management decisions. The tool can be traced back till the 1940’s where it originated in the US military and were used for complex development projects. Originally it was developed to assess failures in equipment and systems but has also been applied in different forms to address projects risks. The tool identifies possible failure modes, causes and resulting effects in relation to either a product, process, or service. It then evaluates the causes and proposes proper countermeasures to overcome these effects. The tool is a qualitative method but has quantitative traits and provides the user with a numerical output value. The way of doing this is using the risk priority number (RPN), which in the aspect of risk assessment is a vital part of the FMEA. In brief the 3 parameters of the RPN are discussed: severity (the consequence of the failure happening), occurrence (probability/frequency of the failures occurrence) and detection (the likelihood that the failure is detected before the impact of it happens), these numbers can all be between 1-10. The scale of these numbers has been criticized in other articles (such as Garcia et al., 2005) and therefore a standard scale for evaluation of the parameters is presented ^[1] .

Before diving into the specifics of the tool the article will explain the purpose of risk assessment, its placement in the risk management process and hereby also the purpose of the tool usage. This is followed by a thorough explanation of the application of the FMEA tool as well a discussion of the limitations of the tool, based on when and how it is applied. ^[2] . As the knowledge of the people using the tool also effects the RPN number, a discussion of diversity in relation to the tool is made to help project managers get the most effective tool usage.

FMEA and its placement in the risk management world

Depending on what organization one consults the major steps to be taken in the process of analyzing and managing risks is somewhat inconsistent. ISO has one approach, Society for Risk Analysis (SRA) has another and finally the Project Management Institute (PMI) has a third one. This is the one used for the following sections and is shown below in the figure.^[3].

Figure 1 - Risk management process with risk assessment steps marked with the blue area and risk analysis with the green area. ^[4]

As it has also been outlined on the figure, marked with the blue area, risk assessment is a part within risk management and makes up a few of the steps of the whole process. The risk assessment then again has a subpart which is the risk analysis. As the figure shows this can be either quantitative or qualitative. In the case with FMEA, the method is used both to identify risk, analyze them (using a mostly qualitative risk analysis) as well as proposing plans for risk response. Therefore, the FMEA covers more than just the risk analysis and can be used for risk assessments in both project management, program management (for example in terms of product development) and other cases.

Introduction to risk assessments

Before we dive into a further explanation of the FMEA tool, we begin with the purpose of the tool. This starts with a basic description of what a risk assessment is. First, we must understand what risk means. Thus, the following definition from PRINCE2 is used as a baseline for what risk is in this article. An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is measured by a combination of the probability of a perceived threat or opportunity occurring, and the magnitude of its impact on objectives. ^[5]. Other definitions exist but this is the one that will be used here. As seen from the quote PRINCE2 define risk as both threats and opportunities, however most risk assessments mainly focus on the threats. The reason for this is the negative impact threats can have for projects and thus the need to evaluate and assess risks using risk assessments arises.

Risk assessments relevant as all projects undergo phases and parts that include uncertainties in the form of risks. Therefore, part of the project managers task is to be able to manage these risks. Part of the risk management process involves assessing the threats and vulnerabilities in the project. From this information the project manager must enforce countermeasures that are to be implemented to reduce the risks. A strong basis for making these decisions is vital and this is where a good risk assessment tool plays an important role in helping the project manager to respond the best way.

An example from the world of security management gives a pretty good explanation of what risk assessments is: “A risk assessment is a quantitative, qualitative, or hybrid assessment that seeks to determine the likelihood that an adversary will successfully exploit a vulnerability and the resulting impact (degree of consequence) to an asset.” ^[6]. This is quite intuitive and the very same process that is used to make a risk assessment in a project management environment. The only difference is that the adversaries are the things that can go wrong, and the asset is the project. So, to sum up, a risk assessment is one or more methods/tools that are used to discover what can go wrong and how big the impact will be if it happens.

Qualitative and Quantitative risk assessments

So multiple types of risk assessments are used for many different industries and purposes, but all of them are either quantitative or qualitative - or a hybrid, and all seek to identify risks and implement countermeasure. The qualitative approach relies heavily on the skills and knowledge of the people performing the analysis and are very useful to identify and a gain understanding of individual risks and their probability of occurring. As it is not a number-based approach it therefore also leaves a subjective result however it is the fastest of the methods to perform. The quantitative approach is evidence based and relies on numbers to evaluate and quantify project risks. This however is only possibly if the risks have already been identified using the qualitative approach. As the quantitative methods are time consuming and resource intensive, they are usually only applied to the most critical risks and the result is a number e.g., a monetary value, time delay or similar ^[2] .

Regarding the FMEA method this is a qualitative risk assessment method ^[7]. However, some places it is described as quantitative. The tool however consists of mostly subjective input and the ranking of the identified risks is dependent on the person using the tool therefore it is qualitative. However, the tool delivers a numerical output, and this might be where the confusion arises, and some might see it as quantitative because of this. One could therefore argue that the tool might be more of a hybrid than purely qualitative.

FMEA for risk assessment

The FMEA method covers multiple steps in the risk assessment process and subsequently the risk management process. The three main things the FMEA does is: ^[2]

1. Identify potential risks/failures including their causes and effects.
2. Evaluate and prioritize identified risks/failure modes since not all risks are equally important (Qualitative risk analysis)
3. Find and suggest actions that can reduce or eliminate the chance that the potential risk/failure occurs (Plan risk response)

Thereby the FMEA covers the three main steps in the risk assessment ^[3]. It does this with a systematic approach to analyze potential failure modes aimed at preventing the failures before they happen and thus reduce the risk of a project, product, service, or system. This is intended to be a preventive action and thus the method performs best when applied early in a project or process. Using a highly skilled and diverse team consisting of team members from many different areas with multidisciplinary educational backgrounds such as engineering, design, management, manufacturing etc. with a knowledge of the project type (be it product development, construction, system implementation etc.) yields an effective FMEA that will identify corrective actions required to prevent failures/risks from reaching the project/customer/end user etc. depending on what case the FMEA is applied to. ^[7]

The way of evaluating the risk is using the RPN number that is based on ranking the severity, occurrence, and detection of each failure mode on a 1-10 scale and then calculating the RPN as: Risk Priority Number = Severity x Occurrence x Detection. The ranking of each element is based on the subjectivity of the individual ranking it. To counter this a standard scale is presented in the application section. However, the newest studies from 2021 show that performing a fuzzy hierarchical FMEA (FH-FMEA) can improve the reliability of the model, as it makes the method able to work with subjectivity in the data and evaluation process. ^[8]. For further reading about the fuzzy hierarchical mythology see the reference material. Using the fuzzy approach is however much more complex and therefore the standard approach is described in the application section.

Application

How to apply the FMEA

Applying the FMEA consist of multiple steps and results in a worksheet containing the RNP along with failure modes. A typical FMEA process is a proactive methodology that usually follows the following steps:

1. Assemble a team of carefully selected people with different job responsibilities and levels of experiences. The purpose is to bring a range of perspectives and experiences to the project.
2. Review the process steps (This could be stage gates in a project, steps in product development, parts of a service journey etc.)
3. Brainstorm and list potential failure modes.
4. List potential effects/consequences, causes and detection systems for each failure mode.
5. Assign severity, occurrence, and detection ratings for each effect.
6. Calculate the risk priority number (RPN) for each effect.
7. Prioritize the failure modes using the RPN and recommend actions to reduce or eliminate the failure mode.

In total there are 10 steps to do in the worksheet. An example of how the worksheet can look is shown in the figure below. ^[2]

Figure 2 – FMEA worksheet with explanations. ^[9]

The worksheet has 10 columns and should be filled from left to right. In the worksheet above there is an explanation on how to fill out each column. This might lead to questions about the scale used for the severity, occurrence, and detection rating. Usually, the rating is done using the scaling shown on figure 3, 4 and 5 below.

As these scales are not absolute, they are subject to some subjectivity and thus even though the RPN is a number that’s calculated it does not make the FMEA a quantitative method. The scaling definitions might defer slightly depending on what sort of context the FMEA is applied to, whether it is a product development project, construction project or other sort of project. However as seen from the scaling the model is often used in product/systems development projects. In cases where it is used on the top-level management of a project the effect scaling might simply be altered to cope with the nature of project progress instead and possible threats to the project schedule and cost. This simply must be decided upon at project startup. The definitions of the effect criteria could then instead depend on the total delay of the project schedule or budget overrun. ^[7]

Diversity

As the final RPN depends so much on the subjectivity of the team, a project manager must know the importance of assembling a skilled and diverse team. As this first step is vital for the outcome of the analysis. So here is a guide to team diversity.

There are three different ways a team can be diverse: education diversity, skills diversity, and gender diversity. This can be divided into two types of diversity: surface-level diversity and deep level diversity. The first type is the biological and physical differences as age, gender, race and ethnicity and the latter type is psychological characteristics, such as cognitive abilities, attitudes, values, knowledge, and skills ^[10]. For the FMEA both types are important but as the latter is the diversity that includes knowledge and skill this is most important as this is attributes that can help the team to identify risks and failure modes in a project. The knowledge and skill of course must be relevant to the actual project, meaning the team should not just be assembled for the sake of diversity.

When to apply FMEA

There are many cases in which a FMEA risk assessment will yield a beneficial outcome. There are however three main categories where FMEA’s are used. These are the cases that the tool was originally thought to help find failures in

1. process development
2. product development or
3. service development

As developing processes, products and services usually are projects the tool are already here a great help for the project manager to help analyze potential risks in the form of failures. This is of course part of the risk assessments in project management, but the tool can also be used to make top-level risk assessments of the projects themselves. The important thing here is however also where in the process it is applied. The FMEA is designed to be used before a change is being implemented. This means in the context of a project, the FMEA should be made in the early phases/initialization of the project. This makes sense as mistakes in the beginning of a project becomes vastly more difficult and costly to change in the late stages of a project. However, at the same time the information available is much larger in the end of a project. Therefore, once the FMEA risk assessment has been created in the beginning of the project it must be revisited and revised with new knowledge as the project moves along. Depending on the case the FMEA might also yield useful preventive actions after a project is done this is however a rarer use case. This could for example be in a product development project where preventive actions are made should there be an issue when the product hits the market. Hopefully this should however already have been resolved using the FMEA in the early stages of the product development. ^[2]

Example of FMEA application

The FMEA can as mentioned be applied in a variety of cases. To make an example of how to use the tool a case is shown. This is a case where a construction company is presented with the task of preparing a plot of land for the construction of a new apartment building. Their task is simply to prepare for the foundation of the building to be made. The building is to be constructed in a bushy urban area. The following FMEA can then be made for this project.

Figure 2 – FMEA worksheet with example. ^[11]

The company should then assemble a team of people with a variety of skills and experiences within all the sub task they are to perform and then brainstorm potential failures/risks in all steps of the process. The figure shows just a brief example of the potential failures for the main tasks. Finally, the RPN is calculated, and it shows that the machinery maintenance should be prioritized as this has the highest RPN. As the example shows the steps to include in the FMEA might be very trivial but helps people across the organizations, company, or management team to realize the risk and do something about them.

Limitations

For any tool there will be a need to think critically of how it is used and the same goes with the FMEA tool. Naturally there are more than one limitation, but one could argue that the biggest strength of the FMEA is also its biggest limitation: the team performing the analysis. They are the factor that effects the most how well the risks/fault modes are identified, ranked, and acted upon. Therefore, they are also the tools biggest limitation. As mentioned, having a diverse team is important however one must also consider that diversity can reduce team performance by negatively affecting cohesion, decision-making quality, and members commitment to the team ^[10]. The problem with having a bad team (either one that are not skilled enough or one that are not committed because of diversity) is the risk of “falsely approving” the project that the FMEA is applied to. This means if the “expert” team makes the analysis and overlooks/underestimates big risks/faults in the project/product. This could lead to the management having a false sense of security and giving the green light to projects that is going to fail or do not discover risks early on. This is of course not good, but it could even lead to the project finishing delivering a bad product. It could even lead to the product being harmful/hazardous to the user because it has flaws. Therefore, keeping this in mind when performing the analysis and assembling the team makes it a great tool for risk assessment.

Other limitations of the FMEA method that should be considered when using it is:

1. Multiple Failures: It is not possible to consider the relation between multiple failures that occur at once.
2. It is time Consuming and people dependent: I might be very time consuming to list all potential failure modes and it relies heavily in the expertise of the people identifying them.
3. Updates Required Frequently to make sure all risks are evaluated
4. Potential Waste of Resources: Conversely, it might be that the analysis is to time consuming compared to what is gained from it and resources thereby are wasted. ^[12]

As is also mentioned in the PRINCE2 guide the risk management approach should be appropriate for the size of the project. Therefore, the size scale and complexity of the project should be taken into consideration when applying the FMEA so that it does not create undue burden and bureaucracy. ^[5]

Annotated Bibliography

Below here, the titles of the most relevant references are given and a quick introduction to them

• Nuchpho, P. (2014). Risk Assessment in the Organization by Using FMEA Innovation: A Literature Review.' ^[1]

- This article explains the some of the basics of the FMEA method along with the standard way of calculating the RPN number as well as some of the limitations of the method, including what can be done about it with fuzzy approaches

• Ben-Daya, M. (2009). Handbook of Maintenance Management and Engineering ^[2]

- This book gives a thorough explanation of how to do a FMEA and in what cases it is applied. Some of the perspective of the book is in relation to production systems but gives a good introduction to the FMEA and its history.

• Project Management Institute Inc (PMI), (2019). Standard for Risk Management in Portfolios, Programs, and Projects ^[3]

- This is the standard for risk management and gives a more high-level explanation of the risk management process used for both project, program, and portfolio management. Provides good explanations on the difference between risk analysis, assessment and management

• Damnjanovic, I. (2019). Project Risk Management Fundamentals. Springer ^[7]

- Another book on managing risk that goes a bit more in depth than the PMI standard and also explains the difference between qualitative and quantitative analysis

• L. Pokoradi, S. Kocak and E. Toth-Laufer, Fuzzy Hierarchical Failure Mode and Effect Analysis, ^[8]

- Article that provides state of the art research on improvements to the FMEA method using fuzzy approaches that removes some of the issues with the RPN number that has been criticized earlier

References

1. ↑ ^{1.0 1.1 1.2 1.3 1.4} Nuchpho, P. (2014). Risk Assessment in the Organization by Using FMEA Innovation: A Literature Review.
2. ↑ ^{2.0 2.1 2.2 2.3 2.4 2.5} Ben-Daya, M. (2009). Handbook of Maintenance Management and Engineering .
3. ↑ ^{3.0 3.1 3.2} Project Management Institute Inc (PMI), (2019). Standard for Risk Management in Portfolios, Programs, and Projects
4. ↑ PMI risk management framework overview. Figure created by: Niels Peter Lindegaard on the basis of PMI risk standard
5. ↑ ^{5.0 5.1} AXELOS. Managing Successful Projects with PRINCE2, The Stationery Office Ltd, 2017.
6. ↑ Risk assessments. (2007). I: Karim H.. Vellani (Red.), Strategic Security Management. Elsevier Inc.
7. ↑ ^{7.0 7.1 7.2 7.3} Damnjanovic, I. (2019). Project Risk Management Fundamentals. Springer
8. ↑ ^{8.0 8.1} L. Pokoradi, S. Kocak and E. Toth-Laufer, Fuzzy Hierarchical Failure Mode and Effect Analysis, 2021 IEEE 19th International Symposium on Intelligent Systems and Informatics (SISY)
9. ↑ FMEA worksheet. Figure created by: Niels Peter Lindegaard on the basis of books and articles referenced here
10. ↑ ^{10.0 10.1} Garcia Martinez, M., Zouaghi, F., & Garcia Marco, T. (2017). “Diversity is strategy: the effect of R&D team diversity on innovative performance.” R&D Management
11. ↑ FMEA worksheet example. Figure created by: Niels Peter Lindegaard on the basis of book and articles referenced here
12. ↑ Dai, Wei & Maropoulos, Paul & Cheung, Wai & Tang, Xiaoqing. (2011). Decision-making in product quality based on failure knowledge. Int. J. of Product Lifecycle Management