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

Revision as of 20:54, 21 September 2015

Every project faces uncertainties all along its life cycle. Dealing with risks is then a fundamental aspect for a successful project management: uncertainties can affect the possible outcomes and project effectiveness The risk management's objective is to assure uncertainty does not affect the project goals. This article aims to show how

The concept of loop of control in risk management is a comprehensive model consisting of applicable methods, implying a dynamic and countinous model. The loop of control is built upon 4 phases: individuation, assessment, controlling and monitoring.

Model 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

FMEA is then a systematic technique of identifying, analyzing and preventing product and process problems before they occur. The purpose of FMEA is to examine possible failure modes and determine the impact of these failures on the product (Design FMEA - DFMEA) and process (Process FMEA - PFMEA)[6]:

• DFMEA is used to analyze 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;
• PFMEA is used to analyze 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.

Although the purpose, terminology and other details can vary according to type (e.g. Process FMEA, Design FMEA, etc.), the basic methodology is similar for all.

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 development includes the following tasks:

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

System structure analysis

FMEA worksheet

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.

Columns explanations

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 the worst potential (but realistic) effect of the failure considered on the system level (the global effects).

(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 (prevention)

(8) current design controls (detection): various possibilities for detection of the identified failure modes are listed. May involve diagnostic testing, different alarms, proof testing, human perception, etc. Example: Failure mode “fail to start” of a pump with operational mode “standby” is an example of a hidden failure.

(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 defi ned 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.

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

Team review

Corrective actions

FMEA in product development projects

Project life cycle

project life cycle - Source: [2]

Risk decreases with availability of useful information - Source: [7]

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[2]:

• 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. New product development (NPD) is the process by which an organization uses its resources and capabilities to create a new product or improve an existing one[4]. Product development is seen as “among the essential processes for success, survival, and renewal of organizations, particularly for firms in either fast-paced or competitive markets”)[10]. A key challenge faced by new product development projects is 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[4]. In order to take into account this aspect, the product design phases should be considered. PD processes are unlike typical business and production processes in several ways. Instead of doing exactly the same thing over and over, PD seeks to create a design that has not existed before[7]. The goal of PD is approached by producing useful information that reduces uncertainty and risk[7]. As the graph shows, the risk are higher at the beginning of the product development, precisely in the conceptual design phase. Especially with novel products, designers learn much along the way about what will and will not work[8].

Project risk management

As the definition of project above explains, a project can be either a success or a failure. 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[5]. Every project faces uncertainties all along its life cycle and, by nature, product innovation involves considerable risks.

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.

Project risk management loop of control - Source: [9]

Risks “can never be fully eliminated, but can be effectively managed to mitigate the impacts to the achievement of a project’s goals”[1]. In a highly competitive environment, management must deal effectively with these risks if the company wants to succeed.

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”[2]

Early detection of contingencies is critically important for managing and minimizing any negative impact on project performance[3]. Then, 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[4].

In addition, risk does not affect all projects equally but depends on the effectiveness of collective managerial actions dealing with specific contingencies[3]. Hence, to be successful, an organization should be committed to address risk management proactively and consistently throughout the project[2]. Risks can only be prevented by identifying their sources and managing them systematically[9]. By systematically, it means that the risk management phases (identification, assessment, response and monitoring) should be performed continuously end especially each time a project milestone is achieved. 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[9] and it is built upon 4 phases: individuation, assessment, controlling and monitoring..

The application of FMEA in projects

“FMEA is one of the most widespread methods used in NPD 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 NPD resources, mostly during the testing phase”[12][11]. Hence, it is very important to consider risk management as a support for the decision-making process[5]. The FMEA as a proactive tool should be performed over the entire life cycle of the project according to the vision of risk management as a continuous and dynamic process. FMEA is usually performed during the conceptual and initial design phases of the system in order to assure that all potential failure modes have been considered and the proper provisions have been made to eliminate these failures.

Throughout the product development phases, design decisions are made within the context of a flow of decisions[4], which implies that knowledge over the product, problems, uncertainties, assumption and the relationships between them can change significantly.

- KNOWLEDGE - INFORMATION MANAGEMENT

It is fundamental the cross-functional participation in order to guarantee different perspective and approach the risk individuation to avoid possible risk missing. If one non considered risk arose during the project development, it would affect the project with unpredictable outcome for the further development. It also implies the likely delay of the project and the subsequent increase of the overall cost.

Limitations

Conclusion

References

• [1] M.W. Cohen, G.R. Palmer, 2004, "Project Risk Identification and Management", AACE international transactions

• [2] Project Management Institute, 2013, "A guide to the project management body of knowledge", 5th edition

• [3] H. Thamhain, 2013, "Managing Risks in Complex Projects", project management journal

• [4] L.P. Cooper, 2003, "A research agenda to reduce risk in new product development through knowledge management: a practitioner perspective", Elsevier, Journal of engineering and technology management

• [5] A. Segismundo, P.A. Cauchik Miguel , 2008, "Failure mode and effects analysis (FMEA) in the context of risk management in new product development: A case study in an automotive company", International Journal of Quality & Reliability Management

• [6] Z.Bluvband, P. Grabov, 2009, "Failure analysis of FMEA", IEEE

• [7] T.R. Browning, J.J.D. Deyst, S.D. Eppinger, 2002 , "Adding Value in Product Development by Creating Information and Reducing Risk", IEEE transaction on Engineering Management

• [8] P. Nightingale, 2000, “The product-process-organization relationship in complex development projects,” Res. Policy, vol. 29, pp. 913–930

• [9] M. Elkjaer, F. Felding, 1999, "Applied project risk management – introducing the project risk management loop of control", International project management journal, pg. 16

• [10] Brown, S.L., Eisenhardt, K.M., 1995. "Product development: past research, present findings, and future directions", Academy of Management Review 20 (2), 343–378

• [11] Maddoxx, M.E. , 2005, “Error apparent”, Industrial Engineer, Vol. 37 No. 5, pp. 40-4.

• [12] Pate´-Cornell, E., 2002, “Finding and fixing systems weaknesses: probabilistic methods and applications of engineering risk analysis”, Risk Analysis, Vol. 22 No. 2, pp. 319-34.