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

From apppm
Revision as of 19:08, 21 September 2015 by S141573 (Talk | contribs)

Jump to: navigation, search

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.


Contents

FMEA in project life cycle

project life cycle

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

Projectlifecycle.jpg

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].

Risk designphases.png.jpg

Project risk management

As the definition of project above explains, a project can be either a success or a failure since the project goals cannot be achieved. 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. 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. “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]. Furthermore, 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 is a comprehensive model consisting of simple and applicable methods (Elkjaer, 1998). 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].

Loopofcontrol.jpg

FMEA in project life cycle

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[11]. “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][13]. 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. FMECA 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. 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.

Model description

FMEA is an inductive technique undertaken by analysts with sufficient knowledge/experience of the system under investigation. FMEA aims to identify and prioritize possible imperfections in products and processes (PUENTE et al., 2001). More precisely, FMEA can be defined as "the set of procedures by which each potential failure mode in a system is analyzed to determine the results or effects thereof on the system and to classify each potential failure mode according to its severity" (US MILITARY STANDARD 1629A, 1980. p. 4). 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 (Pate´-Cornell, 2002; Maddoxx, 2005). 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.

alt text

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) Ref. No.: 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) Operational mode: various operational modes for the element are listed (ex. Of operational modes are Idle, standby, and running). In applications where It’s not relevant to distinguish between operational modes, this column may be omitted.


(4) Failure mode: for each function and operational mode 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).

(5) Failure cause or mechanism: failure modes identified in (4) 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.

(6) Detection of failure: 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.

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

(8) 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.

(9) Failure rate: failure rates for each failure mode are listed. In many cases it is more suitable to classify the failure rate in broad classes.


(10) Severity ranking: the severity of a failure mode is the worst potential (but realistic) effect of the failure considered on the system level (the global effects).

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

(12) Comments: this column may be used to record pertinent information not included in the other columns

Risk ranking

Team review

Corrective actions

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, “The product-process-organization relationship in complex development projects,” Res. Policy, vol. 29, pp. 913–930, 2000.
  • [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] M. Susterova et al., 2012, "Risk management in product development processes", DAAAM international
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox