FMEA analysis
18 April 2025
updated at: 6 November 2026
- FMEA is your “digital shield”. Instead of fixing failures after the fact, the method lets you predict them and eliminate them while still at the design stage or when setting up processes;
- how it works: the team rates each risk on three scales:
- severity (S): how bad will things be if it happens?
- occurrence (O): how often can it happen?
- detection (D): will we spot the problem before the customer does?
- the key number: multiplying these scores gives you the RPN (risk priority number). The higher it is, the sooner changes need to be made;
- where to apply it in IT:
- DFMEA: when designing the architecture of new systems;
- PFMEA: to audit current IT processes and service desk operations;
- FFMEA: to check how component failures affect system functions.
- why it matters to the business: fixing an error in code or a process at the start is far cheaper than dealing with the consequences of an outage after release. It is a direct path to meeting SLAs and protecting your reputation.
What is FMEA analysis?
FMEA (Failure Mode and Effects Analysis) is a systematic method for identifying and preventing potential defects in products and processes. The name reflects the essence of the method: analyzing possible failure modes and their effects.
FMEA is a structured approach in which a team of specialists identifies every way a failure could occur, assesses its consequences and defines measures to reduce the risk. The analysis works bottom-up, from individual components to the overall picture.
The defining feature of FMEA is that it is preventive. Rather than reacting to problems that have already happened, the method lets you anticipate and prevent failures before they occur. FMEA rates risks against three criteria: the severity of the consequences (Severity), the likelihood of occurrence (Occurrence) and the ability to detect the problem before it manifests (Detection).
FMEA is applied at different stages of the product lifecycle:
- at the design stage, it helps uncover potential design problems (Design FMEA),
- when setting up production processes, it identifies possible process failures (Process FMEA),
- and functional FMEA focuses on preventing failures in the operation of the system as a whole.
The FMEA methodology includes a quantitative risk assessment. In the classic approach, the RPN (Risk Priority Number) is calculated as the product of Severity, Occurrence and Detection. The current AIAG-VDA standard also uses an Action Priority system (High/Medium/Low). Special attention is paid to risks with the highest Severity score (9–10 points), even if their RPN is low.
Types of FMEA: which approach to choose?
There are several types of FMEA, each applied at its own stage of the product or process lifecycle, depending on the goals and the object of analysis. Each type has its own specifics and scope:
| PFMEA | Process FMEA (PFMEA), or process failure mode and effects analysis, is a technique for examining existing operational processes and procedures. PFMEA is used to identify potential failures that could significantly affect current operations. It focuses on the risk of business process failures, user or administrator errors and threats originating in the IT infrastructure. The analysis is most effective when the organization has historical incident and outage data, which makes it possible to estimate the likelihood of problems more accurately. PFMEA helps system administrators, DevOps engineers and analysts find weak spots in IT processes. The method makes it possible to define and implement measures in advance that prevent service downtime, data loss and degraded IT service quality. |
| DFMEA | Design FMEA (DFMEA), or design failure mode and effects analysis, focuses on the design stage of a system, product or service. DFMEA aims to identify potential vulnerabilities and defects related to the architecture or logic of an IT product. This type of analysis is especially valuable when designing new systems, modules or applications, before active development or deployment begins. DFMEA reveals weaknesses in a product's architecture or logic early on, when changes take far fewer resources than rework after release. Development teams use DFMEA to systematically examine every component of the product being designed, assess its possible failures and their impact on the functionality of the whole system. |
| FFMEA | Functional FMEA (FFMEA) analyzes failures at the level of system functions. Unlike the component-level analysis in DFMEA and PFMEA, it looks at the relationships between elements. This approach is useful for complex IT systems, although the main standards do not define it as a separate type of analysis. FFMEA views the system in terms of the functionality it delivers and examines how failures in individual components could affect the system's ability to perform its core functions. This approach helps build a more reliable system that takes into account the relationships between its functional elements. |
When choosing an FMEA approach, consider the stage of the product lifecycle and the specific problems you need to solve. For new developments, it is best to start with DFMEA and then move to PFMEA when setting up the operational process. FFMEA can be used at any stage to ensure the functional reliability of the system as a whole.
Goals and objectives of failure mode and effects analysis
FMEA has a number of strategic goals and practical objectives that make it a valuable tool for organizations. The main goal of FMEA is to prevent potential failures and minimize their negative impact on the product, the process and, ultimately, the user.
One of the key goals of FMEA in IT is to improve the reliability and security of digital solutions, from software to IT infrastructure. Within the ITSM approach, FMEA helps systematically analyze and eliminate potential points of failure in services already at the design, implementation or change stage. Early detection of vulnerabilities makes IT services more resilient and reduces the risk of outages, data leaks and other incidents that affect the quality of service for end users.
Optimizing company resources is an equally important goal. Eliminating defects at early stages costs less than fixing problems in products that have already shipped. For example, if cloud data management software contains a vulnerability that could leak customer information, the result could be serious financial and reputational losses. That risk could have been minimized by applying FMEA when designing the system architecture and security mechanisms.
To achieve these goals, FMEA addresses a number of specific objectives:
- Systematically identify all possible failure modes of components, subsystems and the system as a whole.
- Determine the potential effects of each failure mode and rate their severity on a defined scale.
- Establish the possible causes of failures and the likelihood of their occurrence.
- Analyze existing controls and assess their ability to detect the causes of failures or prevent their effects.
- Calculate the risk priority number (RPN) for each failure mode based on severity, occurrence and detection ratings.
- Develop and implement corrective actions to reduce the risk of the most critical failures.
- Evaluate the effectiveness of the actions taken and update the FMEA based on the data obtained.
Addressing these objectives together builds a culture of proactive quality management in the organization, where potential problems are found and eliminated before they show up in finished IT products. This approach not only reduces the cost of warranty support and defect remediation but also strengthens customer trust in the company's brand and products.
Why and when to perform FMEA
FMEA is especially valuable at certain points in the lifecycle of a product or process. Knowing the best time to perform it maximizes the benefit and minimizes the cost of fixing potential problems:
At the early stages of developing new products or processes
FMEA is useful early on because the sooner potential failures are identified, the easier and cheaper it is to make the necessary changes. Fixing a defect at the concept stage is far cheaper than fixing the same problem after the product reaches the market.
After applying QFD (quality function deployment)
Once QFD has translated user requirements into technical characteristics, FMEA checks which of them are risky and need improvement.
When an existing product or process is applied in a new context
A change in operating conditions can reveal risks and failure modes that were not obvious and did not appear in the familiar environment.
Before developing control plans for a new or modified process
FMEA shows which process parameters and points need particular attention. This makes it possible to build an effective monitoring and quality control system.
When planning improvements to an existing product or process
FMEA helps set priorities and assess the potential risks of proposed changes. It prevents situations where solving one problem creates new, more serious ones.
When analyzing failures of existing processes or products
If defects or failures are found in operation, FMEA lets you investigate their causes systematically and develop measures to prevent recurrence.
Remember that FMEA is not a one-off exercise but a continuous process. As new operational data accumulates, conditions of use change or design changes are made, the analysis should be updated, which improves quality and reliability.
Choosing the right moment for FMEA lets an organization get the maximum return on the resources invested and significantly improve the quality of its products and processes.
FMEA methodology: a step-by-step algorithm
FMEA is a structured analysis carried out according to a defined algorithm. Following all the steps of the methodology in sequence not only reveals potential problems but also produces effective measures to prevent them.
Step 1. Define the process or system to analyze
The first step is to define the object of the study and assemble a team of specialists to carry out the analysis. If a complex system or process is being analyzed, it is important to set the boundaries of the analysis: what exactly will be examined and what will remain out of scope.
The team should include representatives of the various departments and disciplines related to the object of analysis: design engineers, process engineers, quality specialists, and representatives of operations and the service team.
Flowcharts are recommended to visualize the process being analyzed. They help all team members share the same understanding of the structure and logic of the system or process.
Step 2. Identify potential failures and their causes
At this step, the team identifies all possible failure modes for each element of the process or system. It is important to consider not only obvious breakdowns but any deviation from normal operation.
For each potential failure, its possible effects are determined: how it will affect the system, related systems and, ultimately, the user or customer. Local effects, next-level effects and end effects of the failure are analyzed separately.
The team then identifies the potential causes of each failure. Historical data on similar systems or processes can help here, as can brainstorming and cause-and-effect analysis.
Step 3. Rate severity, occurrence and detection
At the third step, each failure is rated on three parameters:
- Severity is rated on a 10-point scale, where 1 means negligible impact and 10 means catastrophic consequences that endanger human life.
- Occurrence is also rated on a 10-point scale, where 1 means an extremely low likelihood and 10 means the failure is almost inevitable.
- Detection rates the ability of existing controls to detect the failure or its cause before it affects the system or the customer. The scale runs from 1 (the failure will most likely be detected) to 10 (almost impossible to detect).
Ratings should be as objective as possible, take all available information into account and be based on consensus among team members.
Step 4. Calculate the RPN and prioritize risks
Based on the ratings, the risk priority number (RPN) is calculated using the formula:
RPN = Severity × Occurrence × Detection
The higher the RPN, the higher the priority of measures to eliminate or reduce the risk of that failure. A threshold RPN is usually set (for example, 125), above which corrective action is mandatory.
The results are entered in an FMEA worksheet, which becomes the basis for further risk reduction work.
Step 5. Develop corrective actions and monitor results
At the final step, corrective actions are developed for the failures with the highest RPN values. They can aim to:
- reduce severity (design changes, adding protective mechanisms);
- reduce the likelihood of occurrence (process changes, better-quality components);
- improve detection (introducing additional controls).
Each action is assigned an owner and a deadline. Once corrective measures are in place, the parameters are re-rated and the RPN recalculated to confirm the measures are effective.
An FMEA is a living document that should be reviewed regularly whenever the design, process or operating conditions change. Only then does the methodology become an effective tool for continuous quality improvement.
Examples of FMEA in business
FMEA is widely used in IT and digital business. Let us look at some practical examples of how the methodology helps prevent outages, make systems more resilient and improve the quality of IT processes and services.
In IT services, FMEA is especially valuable when implementing and improving ITSM processes. An IT company that supports critical infrastructure can apply FMEA to analyze its incident management process. The analysis may reveal potential failures in the incident escalation system, including the risk of misprioritizing critical outages and failing to notify the responsible specialists in time.
In a financial institution's IT infrastructure, FMEA can help identify risks associated with insufficient testing of changes before they are deployed to production. It can show what poses the most serious threat, for example the lack of full integration testing between different systems.
FMEA can be used when designing a customer data backup process. The analysis will reveal potential problems related to incomplete backups and restore failures. For example, the scenario in which backup integrity is not checked will receive the highest RPN. Introducing automatic backup verification and periodic test restores will reduce the risk of data loss and raise service reliability to the level required by the SLA.
These examples show how FMEA can be integrated into IT service management processes and help improve the quality and reliability of IT services. Systematic analysis of potential failures not only prevents problems but also builds a more resilient IT infrastructure, which ultimately increases user satisfaction and reduces overall support costs.
FMEA in a nutshell
- FMEA helps identify and eliminate potential failures before they occur. This significantly reduces the cost of fixing defects and avoids the reputational damage of releasing poor-quality IT products or delivering unreliable services.
- FMEA provides a structured, metrics-based approach to risk assessment. Calculating the risk priority number (RPN) gives an objective criterion for deciding whether and how urgently corrective action is needed, which helps allocate company resources sensibly.
- FMEA is applied across many areas of IT, from software development and IT infrastructure management to service reliability within ITSM. Depending on the object of analysis, you can choose the most suitable type of FMEA (DFMEA, PFMEA or FFMEA).
- FMEA is not a one-off exercise but a continuous process. Regularly reviewing and updating the analysis in light of new data and changes in design or processes helps improve products and services and keeps the company competitive.