Failure Mode and Effects Analysis in Various Project Stages

From apppm
(Difference between revisions)
Jump to: navigation, search
Line 154: Line 154:
 
*Consolidates the system by corrective actions.  
 
*Consolidates the system by corrective actions.  
  
The Process FMEA focuses on manufacturing and assembly processes at the system, sub-system or component level and normally with the assumptions that the design I sound. The objective of the variant is to ensure that the product meets design requirements safely, with minimal downtime, scrap and rework. The Process FMEA can encompass manufacturing, assembly, shipping, internal transport of materials, tool maintenance etc.  
+
'''The Process FMEA''' focuses on manufacturing and assembly processes at the system, sub-system or component level and normally with the assumptions that the design I sound. The objective of the variant is to ensure that the product meets design requirements safely, with minimal downtime, scrap and rework. The Process FMEA can encompass manufacturing, assembly, shipping, internal transport of materials, tool maintenance etc.  
  
 
Key output:
 
Key output:

Revision as of 09:45, 19 February 2018

Defects, downtime, injuries and delays can be extremely costly and often directly interfere with a company’s objective of delivering quality and reliability[1],. So how can these events be prevented from occurring?

Extensive testing in the later phases of product development project could for instance be a preventive measure. However discovering the faults at this stage can be very costly and mean even further delays. Instead, it is ideal to take preventive measures, which can be achieved through applying the risk management tool “Failure Modes and Effects Analysis (FMEA)”. FMEA is a systematic step-by-step approach for identifying, analyzing and preventing product and process failures. The tool is often applied in the early stages of a project, but can be used throughout in different variations.

This article aims to inform the reader on how to facilitate FMEA, how it can add value in different phases of a product development process and its limitations.

In this article, a “product” is often referred to as a “system” consisting of sub-systems and components

Contents

FMEA

Before discussing the use of FMEA in different project phases, the general concept of the tool and its application will be outlined.

Definition

FMEA is a qualitative tool that investigates how a product or process might fail (failure mode) in delivering its intended function and the consequences of this. The tool applies with the standards of Qualitative Risk Analysis defined by the PMBOK guide, which shortly can be summed up as a prioritization of risks for further investigation by assessing their probability of occurrence and severity[2]. In practice the tools objective and compliance with the standards can be formulated as:

  • Identification and understanding of failure modes and their causes, and the effects of failure on the system or end users, for a given product or process.
  • Risk assessment associated with the identified failure modes, effects, and causes, and prioritizing of issues for corrective actions.
  • Implementation of corrective actions for the most critical failure modes along with evaluation after implementation.

FMEA can be categorized as a proactive risk reduction tool that after initiation becomes a dynamic factor of improvement. This I due to the iterative nature of risks identification where new risks may evolve or existing risks becomes revealed as the project advances through its lifecycle. [2]. The motive for implementing risk identification followed by risk reduction derives from the objective of changing characteristics of the system, without significantly increasing cost. This ability to do so is highest at the projects start and decreases at the project progresses[2]. A general rule of thumb for the phenomenom is the Factor of 10 rule, which states that changing characteristics of a product in a development project multiplies by a factor 10 for each time the project progresses in to a new phase. The factor of 10 rule I illustrated in the figure below.[3]


Figure 1: Factor of 10 rule[3].

The Tool

FMEA is usually created within a spreadsheet, which enables the user to get an overview over complex systems with multiple components being inspected.

Figure 2: FMEA spreadsheet example[3]














The spreadsheet example consist of 11 descriptive categories that defines the FMEA investigation. These are outlined below:[3]

1. Item The system, subsystem, component or process step chosen for investigation.

2. Function The intended function of the system, subsystem, component or process.

3. Potential failure modes and identifying these Failure modes are the possible ways the intended function of the system, subsystem, component or process fails. These are the backbone of the FMEA tool and identifying these lay the foundation for a successful and broad inspection of how a process or product might fail. When identifying these the necessity for a cross-functional team is heavily underlined since stakeholders have different interpretations and views of possible failure modes. Therefore selecting a team with a broad field of experience relevant to the subject is crucial for the success of the FMEA. This could for instance be designers, production workers, end users, suppliers etc. As a baseline for the identification of failure modes Murphy’s law is introduced as a guiding statement: “Whatever can go wrong, will eventually go wrong”. Once the team are assembled, the brainstorming of potential failure modes can be initiated.Different variations of brainstorming can be applied in order to explore as many failure modes as possible.

4. Potential effect(s) of failure Consequence of the failure on the system, subsystem, component or process level.

5. Severity (S) Ranking of the most serious effect for a given failure mode. The severity is often scaled from 1 to 10, where 10 is the most severe. The ranking can be a product of an assessment based on experience or supported by data.

6. Potential Cause(s) of failure Specific reason(s) for the failure modes to occur (root causes).

7. Occurrence (O) Describes the likelihood of a failure mode occurring and is often scaled from 1 to 10, where 10 is the most likely. It is important to use data (if available) to validate the occurrence ranking. This could be from current design controls.

8. Current design controls (prevention/detection) Methods or actions already in place to prevent or detect failure modes. These are linked to the ranking of the occurrence (prevention) and the ranking of detection.

9. Detection (D) Ranking scale of the possibility of detecting the cause of failure modes. Is often scaled from 1 to 10, where 10 is the least likely. It is important to use data (if available) to validate the detection ranking. This could be from current design controls.

10. RPN (Risk Priority Number) Ranking of failure modes according to severity, occurrence and detection. The RPN value is found by multiplying these three values. RPN = S x O x D

11. Recommended actions Task recommended by the FMEA team with the objective of reducing or eliminating the risk associated with the failure modes.

Execution

In order to conduct an FMEA effectively it is highly recommended to follow a systematic step-by-step approach. D. H Stamatis recommends an eight-step method consisting of the following steps[1]:

1. Team selection and brainstorm – As stated in section ( - failure modes) a cross-functional team with diverse knowledge about the process or product is required for a broad exploration of failure modes. The team defines and prioritizes the opportunities for improvement as a scope for the FMEA process. If specific issues have been addressed by a supplier, costumer etc. the direction is given. If the project Is concerning new development or continual improvement tools such as brainstorms, storybook methods etc. can be used to determine the direction/area of focus.

2. Overview and team alignment. In order to align the team effort and establish an overview of the systems, subsystems, components and processes being investigated, tools such as functional block diagrams or process flowcharts are valuable assets. These tools provide both an overview and a working model for the systems, subsystems, components and processes that ensures everyone is on the same page and understands the problems associated with these.

3. Prioritizing executing an FMEA on big systems or product consisting of many components can be time-consuming and very costly. Therefore a prioritizing is often needed to establish where the main issues are located and where the FMEA can add most value. Preferably, the prioritizing is supported by data that verifies the issues. With smaller systems or if the issues is addressed by a third-party the prioritizing is given and the step can be skipped.

4. Data collection The team collects data of the failures and categorizes them in the FMEA spreadsheet.

5. Analysis The data collected is now utilized in order to fill out the columns of FMEA spreadsheet described in the previous section (The tool). Tools such as cause-effect-analysis, brainstorming, mathematical modeling etc. can be used to support the determination of severity, occurrence and detectability.

6. Results The severity, occurrence and detectability values are multiplied in order to calculate the RPN. Afterwards the failure modes are ranked according to this number.

7. Recommended actions and evaluation The results are used to prioritize the recommend actions and determine where it is most crucial to act. Once the recommended actions have been completed the team reevaluates and rescore the severity, occurrence and detectability for the top ranking failure modes. This is done to determine the effectiveness of the recommended actions. FMEA promotes continual improvement

8. Repetition FMEA has an underlying philosophy of facilitating continuous improvements with the long-term goal of eliminating every failure mode. In order to achieve that, repetition is key. In practice, it is almost impossible to completely eliminate every failure mode. Therefore, a critical RPN value is often chosen to determine when a failure mode is no longer worth investigating. This is of course very different from project to project.


Variations of FMEA and their application in different project phases

In this chapter the FMEA variations are discussed and linked to their respective roles in the different phases of a product development. FMEA can be tailored to fit many different applications and industries, but In general, the tool is normally divided in to three categories concerning product development.

  • Concept FMEA
  • Design FMEA
  • Process FMEA

In practice the FMEA tool is very similar in all variations, however it differs on objective and scope. Below, a road map of a product development process and FMEA can be seen. It illustrates the product development process and the phases in which FMEA is feasible to apply.


Figure 3: Road map of product development and FMEA [1].

The Concept FMEA, also referred System FMEA is the highest level analysis of an entire system. The focus is on system related deficiencies and their interconnection. The concept FMEA is facilitated when concept alternatives are being considered. Often defined as feasibility studies that can prove very valuable in elimination of poor design concepts with inherent risks. When considering many concept options, the efficiency of the process can be optimized by focusing on the concept’s primary functions and the corresponding failure modes, effects and causes that raises the greatest concern.

Key output:

  • Analyze concept alternatives in the conceptual phase ranked by RPN, which help determine the most feasible concept option.
  • Assists in the process of identifying and eliminating risks.

The Design FMEA focuses on product design and the identification of potential risks caused by design deficiencies. The identification is normally performed at sub-system or component level also defined as lower level failures on system operation. For instance, a bicycle is made of multiple components and in order to facilitate a thorough risk assessment it would be necessary to evaluate the different components individually; chain, tires, frame etc. and afterwards relate their interconnection in the system and the system effect of their specific failure modes. Even though the Design FMEA is usually performed in the design phase, it can also be used to evaluate existing products and systems. The findings are then prioritized with a systematic approach and used to improve future designs.

When facilitating a design FMEA it can be considered to do either a bottom-up- or top-down- approach. Both approaches are illustrated below.

Figure 4: illustration of Top-down- and bottom-up approach.


The top down approach assumes a system failure and identifies how that failure could occur by working downwards analyzing individual components related to the failure. This approach is often used when the complexity of the system is high and specific components and failure modes cannot be related without further investigation, or when the scope of the investigation focusses only on a set of specific risks. However, with a top-down approach, FMEA might only discover major failure modes in a system.

The bottom-up approach involves determining failure modes at component level and working upwards analyzing their effect on the system. This approach is more thorough and ensures all components are analyzed and considered accordingly. The bottom-up approach works well when every component has to be reviewed, however it can be difficult to perform on complex systems or systems that are not well defined[4].

Key output:

  • Establishes a priority for design improvement actions based on the failure modes and their prioritized ranking by the RPN.
  • Documents the rationale for changes.
  • Consolidates the system by corrective actions.

The Process FMEA focuses on manufacturing and assembly processes at the system, sub-system or component level and normally with the assumptions that the design I sound. The objective of the variant is to ensure that the product meets design requirements safely, with minimal downtime, scrap and rework. The Process FMEA can encompass manufacturing, assembly, shipping, internal transport of materials, tool maintenance etc.

Key output:

  • Identifies process deficiencies prioritized by their RPN along with corresponding corrective actions.
  • Identifies critical/significant characteristics that should be encompassed in production control plans.
  • Documents the rationale for changes.
  • Consolidates the system by corrective actions.

Limitations

Conclusion

Annotated references

  1. 1.0 1.1 1.2 D. H Stamatis, 2003, 2. Edition, "Failure Mode and Effect Analysis – FMEA from theory to execution", ASQ Quality Press. - Step-by-step approach for implementing FMEA and overview of phases the method is applicable to. Also includes ISO references and Six Sigma practices.
  2. 2.0 2.1 2.2 Project Management Institute, 2013, "Project Management Body of Knowledge", 5th edition - identifies that subset of the project management body of knowledge that is generally recognized as good practice. “Good practice” means there is general agreement that the application of the knowledge, skills, tools, and techniques can enhance the chances of success over many projects.
  3. 3.0 3.1 3.2 3.3 C.S. Carlson, 2012, "Effective FMEAs: Achieving Safe, Reliable, and Economical Products and Processes Using Failure Mode and Effects Analysis", John Wiley & Sons, Inc. - procedures for doing FMEAs and how to successfully apply them in various phases
  4. S. K. Sethiya, (chief mechanical engineer – West Central Railway at Jabalpur), 2004 , "Failure Mode and Effects Analysis (FMEA)" - General concept of FMEA with outlining of top-down and bottom-up approaches..
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox