The Failure Mode and effects analysis (FMEA) in product development projects

Developed by Federico Sbernini

Every project faces uncertainties all along its life cycle. Dealing effectively with risks is then a crucial aspect for a successful project management. Companies and industries across the globe are cutting costs and shortening development times , however high reliability and impeccable safety are essential to customer satisfaction and financial viability.

This article aims to show the application of the Failure Modes and Effects Analysis (FMEA) in project management, and in particular in product development contexts. FMEA is a risk management tool intended to identify all the potential failure modes of the various parts of the system, analyse the effects of these failures and take actions to avoid and monitor the effects of the failures on the system.

Method description and procedure

The Failure Modes and Effects Analysis (FMEA) can be described as a systemized group of activities intended to identify and analyse:

• All potential failure modes of the various parts of the system
• The effects these failures may have upon the system
• How to avoid the failures, and/or mitigate the effects of these failures on the system

A failure mode is defined as the way in which a component, sub-system or system could potentially fail to perform its desired function.

FMEA is therefore a systematic technique of identifying, analysing and preventing product and process problems before they occur.

The 3 most common types of FMEA are:

• Design FMEA is used to analyse product designs before they are released to production. It focuses on potential failure modes associated with the functions of the product and caused by design deficiencies;
• Process FMEA is used to analyse the new or existing processes. It focuses on the potential failure modes associated with both the process safety /effectiveness/efficiency, and problems with the functions of a product caused by the problems in the process .
• System FMEA is the highest level analysis of an entire system , made up of various subsystems. The focus is on system - related deficiencies, including system safety, system integration, interfaces or interactions between subsystems or with other systems, interactions with the surrounding environment, human interaction, service, and other issues that could cause the overall system not to work as intended.

Although the purpose, terminology and other details can vary according to the type of FMEA, the basic methodology is similar for all. To be successful, FMEA must be performed as team-based activity and it needs the right team of subject matter experts. Even the best engineers have blind spots and only a team composed of the right disciplines can provide the necessary input and discussion to ensure all concerns are surfaced and addressed . This enables to tackle the risk analysis from different perspectives and then to reduce the possibility of non-considered risks appearance.

The development procedure of an FMEA is divided into several subsequent steps:

• FMEA prerequisites
• System structure analysis
• FMEA worksheet
• Team review
• Corrective actions

FMEA prerequisites

The first step of the FMEA includes the following tasks, which constitute the basis for the further FMEA development:

• Define the system to be analysed
• Identify system boundaries (which parts should be included and which should not)
• Identify main system missions and functions (including functional requirements)
• Define operational and environmental conditions to be considered
• Interfaces that cross the design boundary should be included in the analysis.

System structure analysis

Figure 1: Hierarchical structure of a system

The aim of this step is to divide the system into manageable units, typically functional elements.

The level of detail of the system breakdown will depend upon the objective of the analysis.

Being FMEA a bottom-up approach, it can be also desirable to illustrate the structure by a hierarchical tree diagram (Figure 1) in order to identify potential/known failure modes at one level and investigates the effect on the next sub-system level .

FMEA worksheet

FMEA uses a tabular method of presenting data, meaning the content of the analysis is visually displayed in a series of worksheet rows and columns.

Figure 2: Logical relationship between FMEA elements

For each system element (subsystem, component) the analyst must consider all the functions of the elements in all its operational modes, and ask if any failure of the element may result in any unacceptable system effect.

The definition of each column is illustrated in the sequence they are normally developed in a FMEA project, which correspond to the logical relationship between FMEA elements (figure 2).

Even though the following worksheet (Figure 3) presents a general FMEA layout, it can be modified according to specific requirements.

Figure 3: FMEA worksheet

Columns description

For each system element (subsystem, component) the analyst must consider all the functions of the elements in all its operational modes, and ask if any failure of the element may result in any unacceptable system effect. The worksheets are divided into different columns:

(1) Item: a unique reference to an element (subsystem of components) is given. It may also be a reference to an identity number in a specific drawing, a so-called tag number, or the name of the element

(2) Function: functions of the element are listed. A checklist may be useful to secure that all the functions are considered

(3) Failure mode: for each function and operational mode (ex. of operational modes are idle, standby, running) of an element the potential failure modes have to be identified and listed. Note that a failure mode should be defined as a nonfulfillment of the functional requirements of the functions specified in (2).

(4) Potential effect of failure:

• On the subsystem: the effects each failure mode may have on other components in the same subsystem and on the subsystem as such (local effects) are listed.

• On the system function: the effects each failure mode may have on the system (global effects) are listed. The resulting operational status of the system after the failure may also be recorded, that is, whether the system is functioning or not, or is switched over to another operational mode. In some applications it may be beneficial to consider each category of effects separately, like: safety effects, environmental effects, production availability effects, economic effects, and so on.

(5) Severity: the severity of a failure mode is a ranking number associated with the worst potential (but realistic) effect of the failure considered on the system level.

(6) Failure cause or mechanism: failure modes identified in (3) are studied one-by-one. Failure mechanisms (for example, corrosion, erosion, fatigue) that may produce or contribute to a failure mode are identified and listed. Other possible causes of the failure mode should also be listed.

(7) Occurrence: failure rates for each failure mode are listed.

(8) Current design controls: For each cause, the FMEA team identifies the design or process controls. Controls are defined as “ the methods or actions currently planned or already in place to reduce or eliminate risk. Controlscan be the methods to prevent or detect the cause during product development, or can be actions to detect a problem during service before it becomes catastrophic”. Prevention - type design controls describe how a cause, failure mode, or effect in the product design is prevented based on current or planned actions; they are intended to reduce the likelihood that the problem will occur, and are used as input to the occurrence ranking. Detection – type design controls describe how a failure mode or cause in the product design is detected , before the product design is released to production, and are used as input to the detection ranking. Detection controls are intended to increase the likelihood that the problem will be detected before it reaches the end user.

(9) Detection: detection is a ranking number associated with the best control from the list of detection - type controls, based on the criteria from the detection scale. The detection ranking considers the likelihood of detection of the failure mode/cause, according to defined criteria.

(10) Risk priority number (RPN): a numerical ranking of the risk of each potential failure mode/cause, made up of the arithmetic product of the three elements: severity of the effect, likelihood of occurrence of the cause, and likelihood of detection of the cause.

$Severity*Occurrence*Detection=RPN$

(11) Recommended actions - Risk reducing measures: possible actions to correct the failure, and restore the function or prevent serious consequences.

Team review

The main objectives of this step are:

• Decide whether or not the system is acceptable
• Identify feasible improvement of the system to reduce the risk. This can be achieved by reducing the likelihood of occurrence of the failure, reducing the effects of the failure, increasing the likelihood the failure is detected before the system reaches the end user.

Corrective actions

After identifying ana analysing the possible failure modes and their effect, the team should think about the possible corrective actions in order to reduce or avoid the risks. Risks may be reduced by introducing:

• Design changes
• Engineered safety features
• Safety devices
• Warning devices
• Procedures/training

FMEA in product development projects

Product development projects life cycle

Figure 4: project life cycle

Figure 5: Risk decreases with availability of useful information

The project Management Institute (PMI) defines a project as “a temporary endeavour undertaken to create a unique product, service, or result. The temporary nature of projects indicates that a project has a definite beginning and end. The end is reached when the project's objectives have been achieved or when the project is terminated because its objectives will not or cannot be met, or when the need for the project no longer exists”.

Every project passes through a series of phases all along its life, from the start to the closure: all these phases represent the project life cycle. While every project life cycle is determined or shaped by the specific nature, industry and technology employed by the specific organization, all projects can be mapped to the following generic life cycle structure (Figure 4):

• Starting the project
• Organizing and preparing
• Carrying out the project work
• Closing the project.

In this article, the specific case of new product development is analysed. Product development is the process by which an organization uses its resources and capabilities to create a new product or improve an existing one .

Product development projects are product-oriented processes, which specify and create the project's product, and they are typically defined by the project life cycle (Initiation, planning, executing, closing).

Along the project development, the product design is carried on, which includes 3 main phases: conceptual design, preliminary design and detailed design. Risk are higher at the beginning of the project, precisely in the conceptual design phase, but they decrease proportionally to the incorporation of product knowledge(Figure 5). Especially with novel products, designers learn much along the way about what will and will not work.

A key challenge faced by new product development projects is therefore how to acquire knowledge and manage sources of uncertainty in order to reduce the risk of failure of either the project or the resulting product.

Project risk management

Even though the success of projects highly affects the company’s business performance, many of them fails or presents delays due to inefficient management of project risk.

The PMBOK guide (project management body of knowledge guide) defines the Project Risk Management as including the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project.In a highly competitive environment, management must deal effectively with these risks if the company wants to succeed and achieve the project's goals.

Figure 6: Project risk management loop of control

Furthermore, “Risk and uncertainty are greatest at the start of the project. These factors decrease over the life of the project as decisions are reached and as deliverables are accepted, while the ability to influence the final characteristics of the project's product, without significantly impacting cost, is highest at the start of the project and decreases as the project progresses towards completion”.

Early detection of contingencies is critically important for managing and minimizing any negative impact on project performance. Therefore, identifying risk factor as early as possible in the project development involves considerable improvements in the overall performance. The product can “fail” due to intrinsic problems (e.g. does not meet performance, reliability, or safety requirements in the environment for which it was designed) or extrinsic problems (e.g. flops in the market, changes in regulations), while the project can “fail” by violating constraints (e.g. late, over budget), not delivering the product, or being beaten by the competition.

Risk does not affect all projects equally but depends on the effectiveness of collective managerial actions dealing with specific contingencies. Hence, to be successful, an organization should be committed to address risk management proactively and consistently throughout the project. Risks can only be prevented by identifying their sources and managing them systematically. By systematically, it means that the risk management phases (identification, assessment, response and monitoring) should be performed continuously. The PRM Loop of Control illustrates a dynamic and continuous process: it is a process where risks are continuously reassessed until they are prevented, reduced or accepted(Figure 6).

The application of FMEA in projects

FMEA is one of the most widespread methods used in product development to aid in determining priorities for technical risks in the management process by identifying project weak points, and as a consequence, optimising the use of resources. Its objective is finding and correcting weaknesses before the product gets into the hands of the customer.

Since for Design FMEAs, the objective is to improve the design of the subsystem or component,it is therefore very important to consider risk management as a support for the decision-making process.

By nature, product innovation involves considerable risks, which implies the importance of performing the FMEA repeatdly over the entire life cycle of the project according to the vision of risk management as a continuous and dynamic process.

Figure 7: FMEA shifts problem discovery earlier in the product development process

Furthermore, FMEA shifts problem discovery earlier in the product development process (Figure 7): early detection of failures implies less disruptive alterations in the product development process and then lower cost of changes. Therefore, knowledge and clear information are then fundamental for an effective FMEA development. Due to the nature of product development, which is iterative and uncertain, gaining knowledge and performing intensive planning at the front-end of the project directly affects not only the project efficiency but also its effectiveness.

Front-end loading, defined as the process of developing sufficient strategic know-how and information at the very beginning of the project, would enable e better and more comprehensive failure detection.

Even though front-end loading increases the cost at the initial phases of the project for the knowledge creation, it would imply more accurate strategic decisions and efficiency improvement, which in turn would decrease the overall project cost and the likelihood of meeting the project goals and deadlines.

Limitations

The FMEA is a widely used method in project management, however it presents several limitation to be taken into account when using it.

• Subjectivity and quality of information
• Limited value when used in isolation

Subjectivity and quality of information

The FMEA, and in particular the risk ranking, is developed on the team’s perception. The components of RPN (severity, occurrence and detection) are each subjective ratings, then the risk analysis is subjective by nature. The FMEA can be only as good as the capacity of team members and the knowledge they have on the system. The quality of information used to develop the FMEA is the a crucial aspect for its effectiveness as useful tool in risk assessment. Otherwise, it can lead to inefficient product development project planning, which in turn would imply unpredictable risk manifestation and therefore cost and development time increase, undermining the project outcomes. Furthermore, there is no perfect risk priority system, RPN is one way for the FMEA team to take into account the three types of risks . Whatever risk system the FMEA team uses, an understanding of the advantages and disadvantages of the risk system is essential to prioritize correctly issues for corrective action.

Limited value when used in isolation

FMEA does not model the interactions between failure modes. When it is necessary to model or understand the interconnected relationship between causes, failure modes, or effects, a Fault Tree Analysis may be the right tool, and can be used to supplement FMEA. Due to its limited validity when used in isolation, the FMEA should be combined with quantitative and other qualitative methods for a more accurate risk analysis. Therefore the FMEA should be considered as one tool in the overall reliability plan.

Conclusion

Product development, by nature, implies high risks. The FMEA can be performed as useful method for the risk individuation and analysis, in order to reduce or avoid the risk impact on the project outcomes. Furthermore, the FMEA shifts problem discovery earlier in the product development process and enable an effective risk management. Early detection of contingencies is critically important for managing and minimizing any negative impact on project performance. Therefore, identifying risk factor as early as possible in the project development involves considerable improvements in the overall performance. To enable a successful project, the FMEA should be performed proactively and consistently throughout the project. Risks can only be prevented by identifying their sources and managing them systematically. However, its subjectivity and the quality of information affect considerably an efficient project planning. Front-end loading, defined as the process of developing sufficient strategic know-how and information at the very beginning of the project, would enable a better and more comprehensive failure detection. In addition, The FMEA should be thought as a tool in a broader reliability plan, in addition to other methodologies.