“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. 
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” 
In the article, I cover which specific areas of an FMEA can be prepopulated and how to guard against “blind spots” when prepopulating.
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” 
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.” 
“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.” 
“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.” 
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.
Advocates for automated generation of FMEAs acknowledge the need for “expert and knowledgeable input . . . originated by a knowledgeable engineer or analyst and manually entered.” 
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.
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. 
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.
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.
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
FMEA can play an important role in a risk management process. In this next article, the linkage between FMEA and risk management is explored.