The document contains questions and answers from an FMEA webinar. Key points from the discussion include: - Targeting only RPN values misses potential high severity issues, so both severity and RPN should be considered when prioritizing issues. - Failure modes are described differently depending on whether a system, subsystem, or component FMEA is being performed. - Effects of failure modes should be traced from the local to system level. - FTA considers interactions between failures while FMEA considers each failure individually. - Proper facilitation and risk assessment are needed to ensure the right level of detail in an FMEA.

1. Questions and Answers from Webinar #1
Q1: Should we need to keep target values of RPN as objectives to take actions in FMEA?
A1: First of all, there are two different forms of risk in the RPN number: high severity regardless of RPN,
and high RPN by itself. Targeting only RPN misses the potential risk of high severity – low RPN issues,
which can devastate a company. Some companies choose to provide target values or “thresholds” for
RPN, where action is mandated if RPN exceeds the target value. There is no problem with ensuring that
items with high severity or high RPN values get added review. However, mandating action for RPN
above a threshold has the potential of a numbers game. The best practice is to first ensure that all
high-severity items are addressed regardless of RPN; and then to address all high-RPN items, beginning
with the highest and continuing until the FMEA team and management is satisfied that risk is reduced to
an acceptable level. See section 7.1 “Prioritize Issues for Corrective Action,” pages 163 to 165 in Effective
FMEAs.
Q2: Could you please define failure modes from different context like system, sub-system, and
components.
A2: “Failure mode” is the manner in which the item or operation potentially fails to meet or deliver the
intended function and associated requirements. Depending on the type of FMEA, such as System,
Subsystem or Component, the description of the corresponding failure mode will look different.
The following is Figure 3.2, page 31 from Effective FMEAs. It shows the progression of Failure Mode and
Cause from system to subsystem to component, using the example of fictitious bicycle FMEAs.

2. Q3: Do you include damage effects too? (ex = hose fails and sprays fluid on components)
A3: Yes. It is important to trace the effect of the failure mode all the way from the local level (hose) up
to the system level (overall system, including the hose). The end effect can be described for both the
system and the end user. Fluid spray can damage adjacent system components as well as generate
unsafe conditions for operators. Reference 7.4 “Effects”, pages 32 to 34 from Effective FMEAs.
Q4: How to differentiate between FMEA and FTA (Fault Tree Analysis)?
A4: Excerpt from Chapter 14, section 14.2 “FTA and FMEA”, page 317 of Effective FMEAs:
“The primary differences between FTA and FMEA include:
1. FTA is a graphical representation of the complex relationships in the system leading
to the unwanted event, whereas FMEA is worksheet based.
2. FTA considers the interactions between unwanted events and multiple contributors,
such as two or more contributors that each must be present in order for the
unwanted event to manifest. FMEA usually considers each contributor separately.
3. FTA has the capability of incorporating the probabilities for each of the contributors
and the complex interactions and interrelationships with the top-level unwanted
event. FMEA does not usually support the probability calculation of a top-level
unwanted event.”
Section 14.2.1 “When Should FTA Be Used in Addition to FMEA?” page 317 of Effective FMEAs, provides
more information.
Q5: What controls can be put in place during the FMEA creation process to assure the proper level of
detail?
A5: Proper level of detail is important to ensure that the FMEA is complete, but does not become too
cumbersome and a waste of time. Good FMEA facilitation keeps the team focused on areas of risk that
lead to root causes and effective corrective actions. FMEA discussion should be limited to areas of
concern by one of more members of a properly constituted FMEA team, and avoid lengthy discussions
on low-risk issues. In other words, the higher the risk the more important and in depth should be the
discussion. Lower risk issues should receive less, but appropriate discussion. For more information,
reference pages 231 to 232 of Effective FMEAs.
Q6: Do you prefer including items in analysis even if they're low risk, just to document that you've
thought about them?
A6: Chapter 4, sections 4.2 “FMEA Project Selection Criteria” and 4.3 “Preliminary Risk Assessment”,
pages 58 to 60 of Effective FMEAs, covers how to select FMEA items for analyses. These sections
introduce the concept of Preliminary Risk Assessment, in order to narrow down which items will benefit
from FMEAs. It is not advised to automatically perform FMEA on every subsystem and component in a
complex system, as FMEAs take time and cost money. In addition to performing Preliminary Risk

3. Assessment, I suggest documenting the selection criteria and assessment that clearly shows which items
are analyzed, which items are not analyzed, and why.
Q7: When selecting a failure identification tool we often choose Fault Tree Analysis because it can catch
multi-point failure. Are there any suggestions on how to cover multi-point failures with FMEA?
A7: Usually FTA is the best tool when dealing with failure modes and causes with multiple contributors
and complex interactions. See the answer above regarding FTA and FMEA.
Q8: What do you think of FMEA templates for the use in RCM?
A8: If by FMEA templates you mean preloaded worksheets of FMEA information for use in RCM
analyses, I have concerns. Any time generic or preloaded worksheets are used, there are caveats, such
as the relevance, accuracy or applicability of the information in the template to the specific application
in the RCM project. They can sometimes be useful as thought-starters, but caution is advised.
Q9: How do we share management with HL Output of FMEA from dollars and cents? Off course mgmt
has retention deficiency.
A9: I will cover this topic on Friday during the Webinar on the subject of Effective FMEA Process.
Q10: Do you recommend having a "fixed" FMEA team for an organization? Or is a different team
assembled each time (even for the same system, part, etc.)?
A10: I prefer to use guidelines for the representation of FMEA core teams. However, each FMEA is
different and guidelines can be modified to fit the needs, risk and timing of individual FMEA projects.
Reference section 5.3.4 “Assemble the Correct Team”, pages 93 to 96 of Effective FMEAs.
Q11: What are the keys to best describe part function(s)?
A11: A “Function” is what the item or process is intended to do, usually to a given standard of
performance or requirement. In the example of a part, the key is to describe in sufficient detail the
primary functions of the part being analyzed, and include the performance standard. For example, if the
part is a projector lamp, one function of the projector lamp might be “provide XX lumens of light for
image transfer for minimum yy hours of use.”
Q12: Are you familiar with the VDA 4.2 standard? If so, what are your thoughts? It looks like a very good
approach for system FMEAs.
A12: VDA 4.2 has a good approach to FMEAs in a very general sense. I prefer to use SAE J1739 as a
starting point for FMEAs, and then tailor the worksheet and scales to the unique needs of the company
or organization. For more information, please reference section 5.2.2 “Selecting or Modifying FMEA
Worksheets and Scales”, pages 68 to 70, from Effective FMEAs.
Q13: Regarding FMEA level of detail; what general rules do you have for keeping the level not too high
and not excessively granular?
A13: See question/answer #5 above.

4. Q14: Is there a good rule of thumb on how to estimate the cost of a FMEA? Such as for an electronic
system, would it be 16 hours per a CCA (8'x8" with 4 200 pin BGAs)?
A14: Cost of FMEAs is proportional to the amount of time needed by the FMEA team to do a proper job
of the FMEA procedure, and includes the cost of both the analysis and execution. There are many
variables in determining the time estimate, including system/component complexity, degree of new
technology, unresolved field issues, supplier involvement, and others. I’ve seen FMEAs take anywhere
from only a few hours (small part, very few changes, no new technology) to many weeks (complex
system, brand new, unproven new technology). I know of no rule of thumb that has proven the test of
time. FMEA is not merely “filling out a form”, and involves important cross talk and synergy by a
properly constituted team of subject matter experts. Chapter 4 of Effective FMEAs provides information
about the criteria that impacts a preliminary risk assessment, and from these criteria you can get an idea
of how much time is involved.
Q15: I recently retired from the Dept of Defense. Our [component] FMEAs were supposed to be
reviewed/updated each year. They [FMEAs] were not. How often should FMEAs be reviewed/updated?
A15: Good question. I will show the steps of an effective FMEA process on Webinar #3 (Friday Sept 7th),
which includes the feedback loop for updating an FMEA with test and field issues that occur after the
initial FMEA completion. The question about how often can be answered in the following way. I would
ensure the FMEA repository is updated as often as needed so that it can be used for new FMEAs that
build off the previous version. I’ll be sure to cover this on the 3rd Webinar.
Q16: How does FMEA include or contain a risk assessment of manufacturing process errors, which can
be a significant cause of field failures?
A16: A properly done Process FMEA will examine manufacturing process errors and ensure the risk of
manufacturing errors is reduced to an acceptable level.
Q17: Question about setting RPN setting: Are there any pitfalls in setting an RPN threshold based on
past experience? Or do you suggest to always leave the RPN threshold to each FMEA team?
A17: Please see the answer to the 1st question above. Also see section 6.2.11.1 “Limitations and
Alternatives to Using RPN”, pages 150 to 152 of Effective FMEAs.
Q18: Please explain basic difference between SAE ARP5580 and J1739. Why two different standards?
A18: A quote from SAE ARP 5580:
“Recommended Failure Modes and Effects Analysis (FMEA) Practices For on-Automobile
Applications describes the basic procedures for performing a Failure Modes and Effects Analysis
(FMEA). It encompasses functional, interface, and detailed FMEA, as well as certain pre-analysis
activities (FMEA planning and functional requirements analysis), post-analysis activities (failure
latency analysis, FMEA verification, and documentation), and applications to hardware,
software, and process design. It is intended for use by organizations whose product
development processes use FMEA as a tool for assessing the safety and reliability of system

5. elements, or as part of their product improvement processes. A separate, Surface Vehicle
Recommended Practice, J1739, is intended for use in automobile applications.”
ARP 5580 was intended to replace Mil Std 1629a, but as it turns out many companies still use 1629a for
military applications. I prefer to use SAE J1739. Many non-automotive applications use SAE J1739 with
excellent success. I recommend J1739 as a starting point, unless you are mandated to use a specific
standard. The key is to modify the worksheet and scales to fit your specific application.
Q19: Have you seen FMEA applied to Privacy Risks?
A19: Please email me with more information about your specific privacy-risk application, and I will be
glad to provide my opinion. Carl.Carlson@effectivefmeas.com
Q20: I have found a very good use of FMEA to mechanical functions, however to an electronic assembly
is to me very complicated as the potential number of failure modes becomes almost unlimited. How to
properly focus the FMEA to make it efficient and effective for complex electronic products
A20: I have seen many excellent uses of FMEA as applied to electronic/electrical functions, both
hardware and software, large and small. The key is to ensure that the primary functions are well
described, and the FMEA procedure is done properly. Be sure to begin with proper FMEA Block
Diagrams and Functional Block Diagrams, as covered in section 5.3.2 of Effective FMEAs. I cover
Software FMEAs in section 15.4, pages 348 to 356 of Effective FMEAs.
Q21: What is the difference between an FMEA and a Fish Bone Diagram?
A21: A Fishbone (Ishikawa) Diagram is a graphical representation of the causes of some event. An FMEA,
on the other hand is an engineering analysis done by a cross functional team of subject matter experts
that thoroughly analyzes product designs or manufacturing processes with the objective of finding and
correcting weaknesses before the product gets into the hands of customers. An FMEA can generate a
Fishbone Diagram; but a Fishbone Diagram cannot generate an FMEA.
Q22: As a plant support engineer for power plants, what resources are available to help determine
failure modes for old equipment (>25 years old) - some vendors may be out of business, loss of
knowledge of SME, etc. (Gene)
A22: There is no easy answer to this problem of aging equipment failure rates, where vendors are out of
business and actual field data does not exist. I cover some options in section 5.2.9 “Access to Failure
Information”, pages 76 to 78 of Effective FMEAs. You may also find useful information on the GIDEP
website. GIDEP stands for Government-Industry Data Exchange Program.
Q23: Do you always create Boundary and Parameter diagrams prior to performing a DFMEA? (Kevin)
A23: For System or Design FMEAs I always use FMEA Block Diagrams. I use Parameter Diagrams when
the item under analysis is a complex system with many system interactions, operating conditions, and
design parameters, and the team will benefit from seeing these elements visually. Reference section
5.3.2.3 “Parameter Diagram (P-Diagram)”, pages 85 to 87 in Effective FMEAs.
Q24: What's the most effective way for determining RPN limits for an FMEA Procedure? I.E. If I have an

6. RPN limit of 50 how do I know if that RPN is effective for analyzing the product's process or design
failure modes. How do I answer the question, is it too high or not high enough? (Chris)
A24: Each company must decide what is meant by “reduce risk to an acceptable level.” A high severity –
low RPN issue may be higher risk to customers and the company than a low severity high RPN issue.
Some companies go so far as to establish risk mitigation strategies for each combination of severity –
occurrence – detection. RPN by itself is inadequate for a one-size-fits-all risk metric. Reference section
6.2.11.1 “Limitations and Alternatives to Using RPN”, pages 150 to 152 of Effective FMEAs.
Q25: got here late - are slides or webinar available to keep up with the series? (Thomas)
A25: Please contact Fred Schenkelberg, who will provide the information on webinar slides availability.
Q26: How do you decide at what level of indenture to start FMEA?
A26: For a new or revised system, I almost always begin with a System FMEA. Then I use Preliminary Risk
Assessment to identify which subsystems and components will need Design FMEAs. Preliminary Risk
Assessment is fully explained in Chapter 4, section 4.3, pages 59 and 60 of Effective FMEAs.