Skip to content

What is FMEA?
Understanding the Failure Mode and Effects Analysis Process

Published on: October 27th, 2022

Failure Mode and Effects Analysis (FMEA) consists of proactive, structured actions used to evaluate risks, processes, or systems to establish how they can fail and assess the impact of potential failures. An FMEA team determines the possible failures or risks throughout the development lifecycle. In particular, the FMEA teams investigate various failure modes (or points of failure) to identify impacts like defects, waste, and harm, to inform the appropriate mitigation measures for eliminating the failures.

The FMEA process should prioritize potential failures based on detectability, severity, and frequency:

  • Detectability defines how hard it is to detect possible failures.
  • Severity defines the seriousness of the impact of failure.
  • Frequency implies the number of times failure is likely to occur.

Therefore, the main purpose of FMEA is to either remediate different risk levels based on a prioritized set of actions to eliminate failures or minimize their rate of occurrence and severity. The FMEA process also describes and assists in choosing the mitigation measures to remediate the consequences and impacts of failure.

See how it works:
 


Ready to streamline your requirements management today?

When to Employ FMEA

Use the FMEA process in the following situations:

  • During the service, product, or process design or redesign, especially after the deployment of a quality function
  • When planning to deploy a current service, product, or process differently from its present deployment.
  • Before developing and implementing a control plan for a modified or new product or process
  • When planning goals and objectives for an existing service, system, or process
  • During the analysis and evaluation of potential or existing failures in service, system, or process
  • Frequently and systematically throughout a product’s lifecycle after it has been released
Male Engineer Explains to Female Project Supervisor Functions of the Product and design with failure mode analysis

Why the FMEA Process Is Important

Most organizations and development teams fear releasing a product with undetected failures that may result in product recalls, corrections, harm to end-users, and lawsuits, all of which can harm your company. Even the slightest problem can have unwanted consequences that taint your brand’s reputation.

Moreover, spending time rectifying failures after product release inhibits you from working on developing new features. This can stunt company growth.

Performing the FMEA process enables risk identification during the development lifecycle to ensure early mitigation, saving money and time and preserving the organization’s reputation. Structured and routine FMEA processes permit development teams to detect and mitigate risks in the product design phase, allowing risk control, remediation, and lower costs.

How to execute the FMEA Process

FMEA. Failure mode and effects analysis process diagram. Business analysis concept.

There are five primary phases in the FMEA process:

1. Prepare the FMEA Document and Team Invitation

An FMEA team member who knows the system, process, or product design to be analyzed prepares the FMEA document.  A product team member then forms and invites a cross-functional team consisting of sales, production, marketing, finance, end-user, customer, and procurement.

An FMEA document should only contain a single product, process, sub-system, or attribute at any given time to ensure all failure modes are detected. If its scope is too broad, the specific actions are harder to pin down.

2. Input the FMEA Information

The team members brainstorm when the FMEA document is ready, and a cross-functional team is put in place. Essentially, they evaluate all possible failure modes. A failure mode is a process of identifying all the potential or actual errors and defects in the process or product design. In addition, the FMEA team analyzes the potential risks, impacts, and causes of the identified failure modes and fills this information on the FMEA document.

3. Assign the RPNs

The team must then assign a Risk Priority Number (RPN), which is a number calculated for a specific step in each process to determine the likelihood of occurrence and probability of detection of the identified failure modes and quantify their impacts’ severity.

Assigning an RPN is crucial since the FMEA process aims to minimize the RPN. The higher the number, the more necessary it is for the FMEA process to minimize it before releasing the system or product.

4. Prioritize and Coordinate

The FMEA team must prioritize failure modes that have the largest RPN. The higher the RPN, the higher the risk of failure. Hence the failure modes with higher RPNs should be analyzed and reviewed to inform the mitigation measures.

Also, the cross-functional FMEA team should review different products, processes, and sub-systems concurrently to ensure coordination in the mitigation process. For example, if one solution is responsible for the failure modes in a different product, the responsible teams should coordinate to ensure this is detected and addressed throughout the development lifecycle.

5. Incorporate Compliance Regulations and Requirements Management

The FMEA teams should incorporate the relevant compliance regulation and requirements management as they complete product evaluation and mitigation of potential failures. It is recommended to use a requirements management tool to ensure the FMEA items directly link to the sources of possible failures to enable mitigation and verification of the necessary requirements and compliance regulations.

executive managers group at meeting. Multicultural professional businesspeople working together on FMEA plan in boardroom.

Choose a Requirements Tool that Can Help

Modern Requirements’ authoring tools allow you to connect your existing requirements or author new requirements into your project. You can take authoring a step further and use its automation tools to help your team generate User Stories, Use Cases, and Test Cases.

It can help identify potential failures, risks, and problems in a product early in the development lifecycle. With MR4DevOps, you can compare baselines easily to assess what requirements might have been added, removed, or changed over time and if these changes introduce new failures to the product under development.

Contact us for a quote or for more information.

Subscribe to our Monthly Newsletter!

Wait! Before you go:

Want to see how ModernRequirements4DevOps works?

We’ll give you a quick Demo!