<<< Back to Issue 117 Index

Gathering Information for Effective Design and Process FMEAs

Software Used

→ Xfmea

[Editor's Note: This article has been updated since its original publication to reflect a more recent version of the software interface.]

One key to a successful FMEA session is up-front preparation. In this article, we outline the basic items that should be collected as input to the FMEA, distributed to the FMEA team before the kick-off meeting and readily accessible during the session.

Why Gather Information Up Front?

Gathering information up front will help with utilizing the team meeting time in the most efficient manner. Many FMEA teams struggle to achieve their objectives in the allocated time frame, and part of the reason is inadequate up-front preparation. Another benefit to gathering information up front is that it greatly helps with creating a more thorough and accurate analysis. The analysis has to be specific enough to identify high-risk items and address them through corrective actions. Having detailed information, such as a clearly identified function with associated standards of performance derived from available technical specifications, will help the team to understand the potential failure modes and causes and to determine whether the current controls are adequate, or if further action is needed to reduce risk to an acceptable level.

While the information required varies depending on the application and specific business, industry and other factors, this article presents some general guidelines about the nature of the up-front information that should be sought in both Design and Process FMEAs.

Design FMEA

Bill of Materials

The bill of materials specifies all the parts that are planned to be used in the final product. The intent is to build a system hierarchy from the bill of materials. The different parts need to be arranged in a logical manner to represent subsystems, assemblies and subassemblies in a hierarchical (tree) structure that rolls up to the system level.

Boundary Diagrams

A boundary diagram shows the physical and logical relationships between the components in the system or assembly. It identifies the relationships and dependencies between components. A boundary diagram helps in determining the scope of each FMEA analysis: system, subsystem and component level. It can also clearly illustrate component and subsystem interfaces and encourages the FMEA team to start thinking about interactions, which often represent a significant percentage of total failure modes in a system.

Customer Requirements Document

Every company should create a customer requirements document. While there are many different ways to do this, such as Quality Function Deployment (QFD), the purpose of all of them is to specify the product’s requirements from a customer’s perspective. This will help the team to understand the intended product functions from a customer’s point of view.

Business Requirements, Functional Specs, Technical Specs

Related to the previous item, every company needs to create a process to take high level business requirements and derive product requirements from them, and then to translate those to functional and technical specifications. It is very important that this up-front work be done, since the technical specifications will feed directly into the intended functions of the system, its subsystems and components. Having well-defined functions is the foundation of an effective FMEA process.

Design Schematics, Drawings

Design schematics can help the FMEA team visualize the design and understand how components are assembled together. This can provide tremendous value, since a drawing can depict subtle differences in design that can make a big difference. All available schematics and drawings should be readily accessible for the FMEA team.


A parameter diagram (P-diagram) is used to classify the functionality associated with the intended product into signal factors, control factors, noise factors, output functions (response variables) and error states. [1] It is related to robust design efforts and can provide information on the product’s response to customer usage and expected operating environment.

Feasibility Studies and Trade-off Analyses

At the early concept stages, feasibility studies are performed for various alternative design approaches. Some elements of design may be traded off for others; for example, a higher cost might be deemed acceptable if it results in better performance. These studies can be useful to the FMEA team because they depict conscious design decisions that might lead to higher-risk items.

Current Test Plans

The current test plan matrix should be readily available to the FMEA team. It can provide input for detection controls and the detailed descriptions of the tests can provide an in-depth look into how effective the tests are in addressing specific failure modes. Later, the test matrix will be updated with the focus on high-risk items from the FMEA.

Field Failures and Other Information from Previous and Similar Designs

Most new products are not entirely new to the world or the company. Often, lessons learned and documentation from previous and/or similar designs can be used as input to the new FMEA efforts. This includes utilizing previous FMEAs and bringing failure information from the field. This information can be used as "phrase sets" for potential failure modes and causes in the new FMEA.

Supplier Documentation

Supplier documentation, including technical specifications and available test results, can shed light on the expected quality, performance and reliability of parts, as well as the expected usage and operational limits. Working closely with suppliers to establish a communication channel in order to obtain this information is key for this step.

Available Test Results

Preliminary test results need to be looked at because they can provide an early insight into the dominant failure modes of the new design. Usually, such information will be at the component level, since system testing capability is generally not available until later in the development process.

Program Schedule

The team needs to be aware of the overall program schedule and important development milestones. This will drive due dates for action items.

Applicable Government and Safety Regulations

Many industries and products are bound by safety or government regulations that need to be understood by and readily accessible for the team during the FMEA meetings.

Design Standards to be Used

It is very common that specific industries follow specific design standards. For example, a company designing a new pipeline system might use the design guidelines in accordance with ASME/ANSI B16 – Standards of Pipes and Fittings. The FMEA team not only needs to reference the standard when defining standards of performance, but needs to have direct access to the standard in order to be able to understand detailed requirements.

Severity, Occurrence and Detection Scales

If your company has developed its own severity, occurrence and detection scales, these need to be understood by the FMEA team before the kick-off meeting. If a standard scale is to be used, such as the SAE J1739, AIAG, ISO 16949 or others, the FMEA team needs to make sure that the descriptions of the rankings make sense for the particular business and the application.

Process FMEA

Because the Design FMEA is used as input to the Process FMEA, all the above material will also be relevant for the Process FMEA. In addition, the following are recommended before the start of the PFMEA meetings:

Process Flow Diagram

The Process Flow Diagram (PFD) provides a logical, visual depiction of the manufacturing or assembly process that is being analyzed. It identifies relationships and interactions between steps and illustrates inputs and outputs. Such diagrams can be helpful in determining the steps in the process that will be analyzed in the PFMEA, as well as the functions and critical characteristics that will be considered in the analysis.

Manufacturing Guidelines and Practices

Any guidelines and practices that are used to set up the manufacturing line in the company, such as error proofing practices, lean concepts, etc., should be available to the PFMEA team.

Manufacturing Lessons Learned

The lessons learned from manufacturing or assembling previous and similar products should be collected and provided as an input to the PFMEA so that mistakes are not repeated and continuous improvement of the process is achieved.

Using Xfmea to Store Gathered Information

Xfmea can function as an information repository so that the gathered information will be easily accessible before and during the FMEA meetings. The first step is to build the system hierarchy based on the bill of materials. Xfmea allows you to build your system hierarchy manually and also supports importing a system hierarchy from Excel®. Figure 1 shows a sample system hierarchy built from the bill of materials of a mini flashlight.

System Hierarchy
Figure 1: System Hierarchy for a Mini Flashlight

Reference materials can then be attached or linked to the system hierarchy. For links, Xfmea stores the full pathname/filename for web pages or files located outside of the database. This does not take up a significant amount of space in the database and provides access to the latest version of the file in its original location (if the link is valid on the computer and the necessary software is installed). For attachments, Xfmea stores a complete copy of the file inside the database. This may take up a significant amount of space in the database but it ensures that the file is always accessible and can be changed only through Xfmea. Figure 2 shows a linked document, a linked URL and a file attached to the system hierarchy. The items have been associated with the top level item, "flashlight," to support the system FMEA. Other part drawings, schematics and supplier information can be linked or attached to subsystems and components, or even to elements of the FMEA (such as functions, causes, etc.).

Xfmea Links and Attachments Window
Figure 2: Linking and Attaching Files to the System Hierarchy

Xfmea also supports the generation of system boundary diagrams (functional block diagrams) and process flow diagrams directly from the system hierarchy. Figure 3 shows a preliminary system boundary diagram for the flashlight.

Boundary Diagram
Figure 3: Preliminary System Boundary Diagram Generated in Xfmea


The success of the FMEA meetings depends upon thorough up-front preparation. The FMEA is a team activity, and the team needs to be enabled with the right informational material so that FMEA sessions are productive and use the experts’ time in an effective manner. This article described some of the references that are commonly used by effective FMEA teams but of course the specific documents will vary depending on the particular situation. Although it is not required to link/attach these resources within the Xfmea software, this can be an efficient way to make sure that the information is easily accessible for all analysis team members.


[1] "Robustness P-Diagram: Overview," last modified May 9, 2008, accessed November 4, 2008, http://thequalityportal.com/p_diagram.htm.