Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Way of the Quality Warrior
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • AI & Predictive Maintenance
      • Asset Management in the Mining Industry
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The People Side of Maintenance
      • The Reliability Mindset
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • Reliability Engineering for Heavy Industry
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Carl S. Carlson Leave a Comment

Common FMEA Confusion

Common FMEA Confusion

[Last month I mentioned that the next article would be on the subject of the application of models in the FMEA process. I am postponing that important topic, in order to do more research. Stay tuned . . .]

This month, I want to discuss one of the most common problems that FMEA teams face: getting confused about the difference between failure modes, effects and causes.

“Things are not always as they seem; the first appearance deceives many.” Phaedrus

Let’s begin with definitions

People at all levels of FMEA experience sometimes get confused about the difference between failure modes, effects and causes. A little careful attention to this subject, to the definitions given in this article, and a bit of practice, will avoid any such confusion.

A failure mode is the manner in which the item or operation potentially fails to meet or deliver the intended function and associated requirements. The term “failure mode” combines two words that both have unique meanings. The Concise Oxford English Dictionary defines the word “failure” as the act of ceasing to function or the state of not functioning. “Mode” is defined as “a way in which something occurs.” Combining these two words emphasizes that the failure mode is what presents itself, i.e. the manner in which the item does not meet the intended function or requirements.

An effect is the consequence of the failure on the system or end user. Depending on the ground rules for the analysis, the team may define a single description of the effect on the top-level system and/or end user, or three levels of effects:

  • Local effect: The consequence of the failure on the item or adjacent items
  • Next-higher level effect: The consequence of the failure on the next-higher level assembly
  • End effect: The consequence of the failure on the top-level system and/or end user

For Process FMEAs, the team should consider the effect of the failure at the manufacturing or assembly level, as well as at the system or end user.

A cause is the specific reason for the failure, preferably found by asking “why” until the root cause is determined. For Design FMEAs, the cause is the design deficiency that results in the failure mode. For Process FMEAs, the cause is the manufacturing or assembly deficiency (or source of variation) that results in the failure mode. In most applications, particularly at the component level, the cause is taken to the level of failure mechanism. By definition, if a cause occurs, the corresponding failure mode occurs.

An example to illustrate this potential confusion

Excerpting from Effective FMEAs, chapter 3:

Take the example of “leak.” In many cases “leak” is a failure mode, but not always.

Question: Can “leak” be a failure mode? Answer: “Yes.”

Example: If one function of a storage vessel or tank includes the need to contain fluid to some standard of performance, a “leak” can be a failure mode, which is the manner in which the storage vessel does not perform the containment function.

Question: Can “leak” be an effect? Answer: “Yes.”

Example: If one function of a vehicle body structure is to provide a safe “crumple zone” during accidents to a given standard of performance, a failure mode can be the structure compresses too quickly, which can result in breach of the vehicle fuel tank integrity and a “leak” of fuel. Thus, “leak” becomes part of the effect description.

Question: Can “leak” be a cause? Answer: “Yes.”

Example: If one function of a camera flash circuit is to provide the electrical signal for the flash bulb to a given standard of performance, a failure mode can be missing electrical signal and the cause can be capacitor malfunction or “leak.” Note that this is not a root cause, as the question still exists why the capacitor leaks. The FMEA team may do an FMEA on the capacitor, or further analyze the cause of the capacitor leakage, in order to arrive at root cause.

Failure Mode and Cause progression from system to subsystem to component

Take a look at this chart to help understand how the difference between cause, effect and failure mode depends on the level of analysis on the system hierarchy.

Tip

Whenever an individual or team gets confused about whether a particular word or phrase is a failure mode, effect or cause, I always go back to the item and the corresponding function (and associated requirements). I want to make sure everyone knows where we are on the system hierarchy, and which function we are addressing. This often clears up the the confusion. I then continue carefully to describe the failure mode as the manner in which the item potentially fails to meet or deliver the intended function and associated requirements. Now we have the correct description of the failure mode; same for effect and cause(s).

Summary

A given word or phrase does not itself imply whether it is a failure mode, or an effect, or a cause. Determining whether something is a failure mode, effect or cause depends on the context in the scenario, and where you are on the system hierarchy. There is no substitute for studying and learning the FMEA fundamentals, including a working knowledge of definitions.

Next Article

With “automation” being increasingly applied to engineering processes, I want to take up the subject of using generic lists of failure modes, causes, and failure mechanisms as an aid in conducting FMEAs. Is this a good idea or not, and under what circumstances can it be helpful?

Filed Under: Articles, Inside FMEA Tagged With: FMEA Confusion

About Carl S. Carlson

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines, supporting over one hundred clients from a wide cross-section of industries. He has 35 years of experience in reliability testing, engineering, and management positions, including senior consultant with ReliaSoft Corporation, and senior manager for the Advanced Reliability Group at General Motors.

« How to Implement a Risk Management Framework
Improving Reliability of Fleet »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Carl Carlson
in the Inside FMEA series

[popup type="" link_text="Logo Info" ]

Information about FMEA Icon

Inside FMEA can be visually represented by a large tree, with roots, a solid trunk, branches, and leaves.

- The roots of the tree represent the philosophy and guiding principles for effective FMEAs.
- The solid trunk of the tree represents the fundamentals for all FMEAs.
- The branches represent the various FMEA applications.
- The leaves represent the valuable outcomes of FMEAs.
- This is intended to convey that each of the various FMEA applications have the same fundamentals and philosophical roots.

 

For example, the roots of the tree can represent following philosophy and guiding principles for effective FMEAs, such as:

1. Correct procedure         2. Lessons learned
3. Trained team                 4. Focus on prevention
5. Integrated with DFR    6. Skilled facilitation
7. Management support

The tree trunk represents the fundamentals of FMEA. All types of FMEA share common fundamentals, and these are essential to successful FMEA applications.

The tree branches can include the different types of FMEAs, including:

1. System FMEA         2. Design FMEA
3. Process FMEA        4. DRBFM
5. Hazard Analysis     6. RCM or Maintenance FMEA
7. Software FMEA      8. Other types of FMEA

The leaves of the tree branches represent individual FMEA projects, with a wide variety of FMEA scopes and results. [/popup]

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Recent Posts

  • test
  • test
  • test
  • Your Most Important Business Equation
  • Your Suppliers Can Be a Risk to Your Project

© 2025 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy