Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
    • About Us
    • Colophon
    • Survey
  • Reliability.fm
  • Articles
    • CRE Preparation Notes
    • NoMTBF
    • on Leadership & Career
      • Advanced Engineering Culture
      • ASQR&R
      • 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 Maintenance Management
      • 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
      • RCM Blitz®
      • ReliabilityXperience
      • 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
      • Field Reliability Data Analysis
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability by Design
      • Reliability Competence
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
      • Reliability Knowledge
    • 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
      • Institute of Quality & Reliability
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Statistical Methods for Failure-Time Data
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Glossary
    • Feed Forward Publications
    • Openings
    • Books
    • Webinar Sources
    • Podcasts
  • Courses
    • Your Courses
    • Live Courses
      • Introduction to Reliability Engineering & Accelerated Testings Course Landing Page
      • Advanced Accelerated Testing Course Landing Page
    • Integral Concepts Courses
      • Reliability Analysis Methods Course Landing Page
      • Applied Reliability Analysis Course Landing Page
      • Statistics, Hypothesis Testing, & Regression Modeling Course Landing Page
      • Measurement System Assessment Course Landing Page
      • SPC & Process Capability Course Landing Page
      • Design of Experiments Course Landing Page
    • The Manufacturing Academy Courses
      • An Introduction to Reliability Engineering
      • Reliability Engineering Statistics
      • An Introduction to Quality Engineering
      • Quality Engineering Statistics
      • FMEA in Practice
      • Process Capability Analysis course
      • Root Cause Analysis and the 8D Corrective Action Process course
      • Return on Investment online course
    • Industrial Metallurgist Courses
    • FMEA courses Powered by The Luminous Group
    • Foundations of RCM online course
    • Reliability Engineering for Heavy Industry
    • How to be an Online Student
    • Quondam Courses
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home
  • Barringer Process Reliability Introduction Course Landing Page
  • Upcoming Live Events
You are here: Home / Articles / Why FMEA Needs to be Team-Based

by Carl S. Carlson Leave a Comment

Why FMEA Needs to be Team-Based

Why FMEA Needs to be Team-Based

“Many ideas grow better when transplanted into another mind than the one where they sprang up.”
Oliver Wendell Holmes

In the international FMEA community, one of the hot topics is how much of an FMEA can be automated versus how much needs to be team-based. Some experts say the future of FMEA requires an automated approach, as systems are getting more and more complex. Others say FMEA must always be grounded in a team of subject matter experts, narrowly focused on the highest priority issues.

In this article, I will share my thoughts on why FMEA needs to be team-based, and what elements can be prepopulated or automated.

I’ll begin with what is not an FMEA.

FMEA is not a checkbox activity, a fill-out-the-form activity, a one-person analysis, a last-minute exercise to meet a contract, or a “do it to satisfy the customer” job.

FMEA is an engineering analysis performed by a cross functional team of subject matter experts, who thoroughly analyze product designs or manufacturing processes, performed early in the product development process, that results in finding and correcting weaknesses before the product gets into the hands of the customer. The end result of properly done FMEAs is risk reduced to an acceptable level.

What is the argument in favor of team-based FMEAs?

To answer this question, I’ll use an excerpt from chapter 5, section 5.3.3 of Effective FMEAs. [1]

There are three primary reasons for the necessity to have the correct team when doing an FMEA.

1. People have “blind spots.” A well-defined cross-functional team minimizes the errors inherent with “blind spots.”

When information is prepopulated in an FMEA, the person doing the prepopulation may have “blind spots”, and include incorrect information or miss important information. When the prepopulated information is subsequently reviewed with the FMEA team, care must be taken to ensure that the team detects incorrect or missing information. Good facilitation will mitigate this potential issue.

2. The FMEA analysis requires subject-matter experts from a variety of disciplines to ensure incorporation of all necessary inputs into the exercise, and that the proper expertise is applied to the design or process being analyzed.

As covered in the excerpt referenced above, FMEAs require the correct team representation, in order to be effective. This is also essential when reviewing prepopulated information. The full team must be present when reviewing prepopulated information in order to be sure there is no incorrect or missing information.

3. One of the indispensable values of an FMEA is the cross talk and synergy between subject-matter experts that occurs during the meetings. Well-defined groups can discover things that individuals often miss.

As covered above, one of the indispensable values of an FMEA is the cross talk and synergy between subject matter experts that occurs during the meetings. The team should avoid deferring to the person who prepopulated the information. In other words, the team should assume there are errors in the prepopulated information and attempt to find the errors. In essence, the FMEA team must discuss and thoroughly examine the prepopulated information. Otherwise, one of the primary benefits of the FMEA exercise can be missed.

What portions of an FMEA can be pre-populated or automated?

Reference the article titled “To Prepopulate or not to prepopulate, that is the question” [2]

In the article, I cover which specific areas of an FMEA can be prepopulated and how to guard against “blind spots” when prepopulating.

Prepopulating Functions:
It may be possible for someone to prepopulate the functions in the FMEA. Examination of product and technical specifications, as well as consulting with SMEs can provide input to the function descriptions. When prepopulating the primary functions in an FMEA, ensure the function descriptions are exactly according to definition, including standard of performance. Review with the full FMEA team to modify function descriptions or add missing functions. Make sure the team is tasked with correcting any deficiencies.

Prepopulating historical Failure Modes:
It may be possible to prepopulate historical failure modes, based on actual field history (in the case of System or Design FMEAs) or manufacturing history (in the case of Process FMEAs). Some practitioners survey individual SMEs to determine potential failures of concern. Past FMEAs may provide insight into potential failures for new designs. When failure modes are prepopulated, these will need to be reviewed with the entire team to modify failure mode descriptions or add missing failure modes.

Prepopulating Detection Controls:
It may be possible to prepopulate detection-type controls in an FMEA. This can only be considered after the FMEA has been completed up through failure modes and causes. The reason for this is the detection-type controls are associated with the corresponding failure modes and causes. Current and past test plans and test procedures are considered when deciding what information to prepopulate in the detection controls column. As covered before, these will need to be reviewed in detail with the entire FMEA team to ensure nothing is missed and incorrect detection controls are modified.

It is a human shortcoming that when people look at lists of information, they sometimes fail to see what is missing in the set of information. It is easier to correct or modify what you see than it is to see what is not there. Therefore, when reviewing prepopulated information, it is essential that the FMEA team is empowered and encouraged to look with a critical eye.

How to mitigate against FMEAs taking too long

One of the arguments made by advocates in favor of automated generation of FMEAs is that complex systems can take a very long time to conduct the traditional FMEA procedure when done by a team. How can this problem be avoided?

Reference the article titled “How to Get Better Results with FMEAs, in Less Time” [3]

In my experience, when these strategies are used, team-based FMEAs can be performed in a reasonable time, even for complex systems.

What is the argument in favor of automated generation of FMEAs?

To answer this question, I will excerpt from an article titled “Failure Propagation Modeling in FMEAs for Reliability, Safety, and Cybersecurity using SysML.” [4]

“The fundamental innovation in our approach is the identification and enumeration of all failure propagation paths and the detailed documentation of the failure transformations, detection measures, mitigation measures and protective measures that can be applied to these devices to prevent or mitigate the impact of the anomaly. By doing so, we can expand the traditional FMEA approach to analysis of cyberattack vectors.” [4]

“Because our approach is automated and can be readily integrated into a system development effort using Model Based Systems Engineering (MBSE), the analysis can be readily repeated throughout the design and can be used frequently to assess a system design, identify weaknesses, and take corrective actions to create a more resilient and robust system.” [4]

Those who advocate for automated generation of FMEAs say that automating the dependency mapping of failure propagation allows a consistent and repeatable FMEA analysis from system models generated from Model-based Engineering. Their rationale is as follows: Increasing complexity of systems, and system of systems, makes it difficult to accurately or consistently perform FMEA using the traditional team-based process. They say this problem is compounded by the requirement to update the FMEA as engineering changes are proposed during the design lifecycle. In their opinion, companies do not have the time to do detailed FMEA analysis on all aspects of complex systems.

Are there concerns about automated generation of FMEAs?

One of the primary concerns about automated generation of FMEAs is the possible introduction of “blind spots” in an FMEA. Automated generation of FMEAs rely on the skill and accuracy of the person or persons who program the automation, and an error introduced will not necessarily be remedied in the FMEA process. See paragraph above “What is the argument in favor of team-based FMEAs?”

Another concern is potential lack of depth and value when describing the underlying causes and failure mechanisms for higher risk failure modes. One of the primary benefits of properly done FMEAs is an accurate depiction of the underlying causes and failure mechanisms. Automated generation of FMEAs can lack depth and value when it comes to FMEA causes and corresponding corrective actions.

What are future discussion and exploration topics?

This is an evolving subject. I will outline a few areas where discussion may be especially worthwhile.

FMEA preparation

Advocates for automated generation of FMEAs acknowledge the need for “expert and knowledgeable input . . . originated by a knowledgeable engineer or analyst and manually entered.” [5]

Advocates for a team-based FMEA approach also agree that there needs to be expert and knowledgeable input to FMEAs.

Preliminary Risk Assessment provides the prioritized list of FMEAs to be done. It allows the project team to focus their FMEA efforts on the most critical items in the system hierarchy. This avoids overly long FMEAs, wasting time and manpower.

FMEA Block Diagram provides the scope of the FMEA, along with identification of key interfaces. Since more than 50% of problems occur at interfaces, this is a critical FMEA preparation step.

Once these critical steps are completed, the information can be automatically populated to an item-function matrix and function descriptions added for the most important basic and interface functions. These prioritized functions can be automatically populated to the function column in the FMEA.

Past failures that are within the scope of the FMEA project should be added to the new FMEA as potential failures associated with the corresponding function. This can be prepopulated.

FMEA prepopulation

Advocates for automated generation of FMEAs use models to populate the FMEA, with focus on the complex failure propagation. Advocates for a team-based FMEA approach acknowledge that there are opportunities for pre-populating selected portions of FMEAs. See article “Discussing the Controversial Subject of FMEA Prepopulation,” as part of the Inside FMEA series, on AccendoReliablity.com. [2]

Application of models

Advocates for automated generation of FMEAs extensively use model-based systems engineering to generate the FMEA entries.

The automated generation of failure propagation can be integrated into the FMEA process, without detracting from the team-based approach. In essence, this guides the Effect description (local, next, system, end), and can be reviewed by a cross-functional team.

Advocates for a team-based FMEA approach use models as part of FMEA input, integration of failure mechanisms, and providing effective corrective actions, to name a few.

Summary

There is an important role for a cross-functional team of subject matter experts in performing FMEA procedure. Selected FMEA information can be prepopulated and/or automated, as covered above. However, there remains a key portion of the FMEA that should be conducted by a properly constituted FMEA team. Following the guidelines outlined in this article, the downside to the involvement of FMEA teams can be avoided, with the benefit of risk reduced to an acceptable level.

References

1. Carlson, Carl, Effective FMEAs, published by John Wiley & Sons, © 2012

2. Carlson, Carl, “To Prepopulate or not to prepopulate, that is the question,” part of Inside FMEA series, posted on www.AccendoReliability.com

3. Carlson, Carl, “How to Get Better Results with FMEAs, in Less Time,” part of Inside FMEA series, posted on www.AccendoReliability.com

4. Hecht, Myron, Baum, David, “Failure Propagation Modeling in FMEAs for Reliability, Safety, and Cybersecurity using SysML,” presented at 17th Annual Conference on Systems Engineering Research (CSER), 2019

5. Hecht, Myron, Chuidian, Aaron, Tanaka, Taiki, Raymond, Ross, “Automated Generation of FMEAs using SysML for Reliability, Safety, and Cybersecurity,” presented at RAMS 2020

Next Article

FMEA can play an important role in a risk management process. In this next article, the linkage between FMEA and risk management is explored.

[display_form id=415]

Filed Under: Articles, Inside FMEA, on Tools & Techniques

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.

« Well Tortuosity
What is the Relationship between Process Stability and Process Capability? »

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

  • Gremlins today
  • The Power of Vision in Leadership and Organizational Success
  • 3 Types of MTBF Stories
  • ALT: An in Depth Description
  • Project Email Economics

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