How to Run a PFMEA for a Manufacturing Process (Step by Step)

A PFMEA is not a risk checklist. It is a structured method for identifying the ways a manufacturing process can fail before those failures show up in production. When executed correctly, it tells you exactly which process steps carry the highest risk, where to invest in controls, and which failure modes are unacceptable regardless of how rarely they occur. When executed as a compliance formality, where a team assigns medium scores to everything to avoid difficult conversations, it produces a document that looks complete and tells you nothing useful.

The difference between a PFMEA that drives process improvement and one that collects dust on a shared drive is execution quality. That starts with understanding what the tool is actually asking you to do.

What a PFMEA is and what it is not

A PFMEA is a prospective analysis. It asks what could go wrong with this process step, not what has gone wrong. The distinction matters. A list of known defects from your quality system is historical data. A PFMEA explores the space of potential failures that the process is susceptible to, whether or not any of them have been observed yet. You are looking for failure modes before they become production problems.

A PFMEA is cross-functional. No single person has enough process knowledge to identify all the failure modes for a complex manufacturing process. The process engineer knows the intended process. The production operator knows what actually goes wrong during a shift. The quality engineer knows what failures have been observed in incoming inspection and customer returns. The maintenance technician knows what equipment behaviors create process variation. You need all four perspectives to build a PFMEA that covers the actual failure space.

A PFMEA is not a post-mortem. It is not a corrective action report. It is not a list of historical non-conformances. Those documents have their place in a quality system, but they answer a different question. The PFMEA answers: what could fail, what would happen if it did, and how well could we detect or prevent it?

The PFMEA table structure

The PFMEA is organized as a table. Each row is one potential failure mode for one process step. A single process step may have three or four rows, one for each distinct way that step can fail. Work through every column for each row before moving to the next failure mode.

Process step. The specific operation being analyzed. Be specific enough that the failure mode is unambiguous. "Torque fastener M8x25 to 22 Nm using torque wrench TW-014 at assembly station 3" is a process step. "Assembly" is not.

Potential failure mode. How this specific process step could fail to perform its intended function. For the torquing step above, three failure modes are plausible: torque applied below the minimum (18 Nm), torque applied above the maximum (26 Nm), and wrong fastener installed. Each failure mode is a separate row in the table.

Potential effect of failure. What happens to the product or to the customer if this failure mode occurs. For undertorque: joint loosens in service, creating a field reliability failure. For overtorque: fastener head strips during assembly, resulting in an assembly rejection and potential fastener retention risk. For wrong fastener: assembly may not meet strength specification, potentially requiring rework or scrap. The effect determines the severity score.

Severity (S). A 1 to 10 score for how serious the effect is. Scored from the customer's perspective.

Potential cause. What causes this failure mode to occur. For undertorque: torque wrench out of calibration, operator fatigue at end of shift causing inconsistent technique, torque wrench slippage on a worn fastener head. Each distinct cause may warrant its own row if the controls or occurrence rate differ significantly.

Occurrence (O). A 1 to 10 score for how often this cause produces the failure mode.

Current process controls. What is already in place to prevent or detect this failure mode before it reaches the customer. Controls can be preventive (designed to prevent the failure from occurring) or detective (designed to detect it after it occurs). A calibrated torque wrench with a 6-month calibration cycle is a preventive control for the calibration drift cause. 100 percent torque audit at the end of the line is a detective control.

Detection (D). A 1 to 10 score for how effectively the current controls detect the failure mode before it reaches the customer. Note that this scores the current controls, not theoretical ones.

RPN. Risk Priority Number. RPN equals Severity multiplied by Occurrence multiplied by Detection. The range is 1 (lowest risk) to 1,000 (highest risk). RPN is used for prioritization, not as an absolute threshold.

Recommended action, responsibility, and target date. For failure modes that require action, the specific action, the person responsible, and the completion date are recorded here.

Revised RPN after action. After the action is completed, the occurrence and/or detection scores are updated to reflect the improved control, and the revised RPN is calculated. This column shows the risk reduction achieved.

How to score severity, occurrence, and detection

Scale calibration is where most PFMEA sessions go wrong. Without anchor points that the team agrees on, individuals score based on intuition. One person scores a joint failure as severity 5. Another scores it as severity 8. Both are defending different interpretations of what "moderate" means. Anchor points resolve this before the disagreement starts.

Severity scale anchors: 1 means no effect on the customer. 5 means moderate degradation of product performance, the customer notices but the product is still functional. 8 means the product is nonfunctional and requires replacement, but there is no safety hazard. 10 means the failure creates a safety hazard without warning. The key cut points are 8 (the product fails completely) and 9 or 10 (there is a safety or regulatory consequence). Anything scored 9 or 10 requires action regardless of occurrence rate.

Occurrence scale anchors: 1 means the failure is unlikely, less than 1 occurrence per 1,500,000 opportunities. 4 means occasional failure, approximately 1 in 2,000. 7 means frequent failure, approximately 1 in 80. 10 means failure is almost inevitable, more than 1 in 2. Most manufacturing process steps, when properly controlled, should have occurrence scores in the 2 to 5 range. A process step with an occurrence score of 8 or above has a serious control problem that needs to be addressed before worrying about the PFMEA score.

Detection scale anchors: 1 means current controls will almost certainly detect the failure before it reaches the customer. The detection mechanism is automatic and infallible. 5 means moderate detection probability. Controls may or may not catch the failure. 10 means current controls cannot detect the failure. There is no inspection or verification step that would catch this failure mode. A detection score of 10 means the customer is the detection mechanism. Any failure mode with a detection score of 7 or above deserves prioritized attention, because even a low-occurrence failure will reach the customer when it occurs.

The most common mistake in scoring: the team assigns everything a score of 3 to 7 to avoid committing to an extreme position. This is social comfort masquerading as analysis. Force the team to defend any score in the middle range. If a failure mode cannot be confidently placed at the high or low end of the scale, that uncertainty itself is a data point. Use it to drive a deeper discussion about what controls exist and whether they are sufficient.

How to prioritize actions from the RPN

RPN above 100 is a common industry threshold for requiring action, but it is not a regulatory requirement and it should not be the only prioritization criterion. A failure mode with severity 10, occurrence 2, and detection 2 has an RPN of 40. That failure mode requires action. Severity 9 or 10 items require action regardless of RPN, because the consequences of that failure mode materializing in production are unacceptable at any frequency.

The practical prioritization order is: severity 9 or 10 items first. Then items by RPN, highest first. Then any item with a detection score above 7, because those are failures that will reach the customer when they occur, regardless of how rarely they happen.

A critical insight: actions that reduce occurrence are more effective than actions that improve detection. An action that prevents the failure mode from occurring is always preferable to an action that improves your ability to catch it after it occurs. Detection improvements are still valuable, especially as interim controls while process improvements are implemented. But the long-term goal is a process where failures are prevented, not one where failures are reliably caught.

How to run the PFMEA session

The cross-functional team is non-negotiable. For a typical manufacturing process, the minimum team is a process engineer, a quality engineer, a production operator with direct experience on the process being analyzed, and a maintenance technician who maintains the equipment. If the process involves automated equipment with a control system, include the controls engineer. If the product is medical or regulated, include a regulatory affairs representative.

Session structure: plan for 2 to 4 hours per process area. Working through 10 to 15 process steps with their failure modes in that window is a realistic target for a focused team. Running longer than 4 hours without a break produces diminishing returns. The team loses focus and scores become less reliable. Spread the analysis across multiple sessions if the process is complex.

Pre-work is the facilitator's responsibility. Before the session, the process engineer maps every process step in the area being analyzed. This means a written list, not a mental model. The team reviews and corrects the process map at the start of the session. Operators will frequently identify steps that are not in the documented process. That correction is itself a finding: if operators are performing steps that are not documented, the SOP is incomplete.

The facilitator's role is to keep the team focused on one failure mode at a time and to challenge middle-ground scores. When the team assigns a 5 to occurrence, the facilitator asks: how many times in the last 100 cycles did this failure occur? If the team cannot answer, the score is a guess, not an analysis. The ground truth comes from production data, maintenance logs, and quality records. Bring them to the session.

The output of the session is a completed PFMEA table: all process steps analyzed, all plausible failure modes identified, all scores assigned with the team's agreement, all high-priority failure modes identified, and an action list with owners and due dates. The PFMEA is a living document. When process changes occur, the relevant rows are updated and the change is documented in the revision history.

PFMEA in regulated environments

ISO 13485:2016 does not name PFMEA by name, but it requires risk management activities as part of production and service controls. The recognized standard for medical device risk management is ISO 14971:2019, and PFMEA is the established method for applying ISO 14971 to manufacturing process risks. When a notified body or FDA inspector asks how manufacturing process risks are managed, PFMEA is the expected answer.

FDA expects to see manufacturing process risk analysis in the design history file for class II and class III medical devices. The design history file is the documentary record that the device was designed and its production process was validated in a controlled manner. PFMEA is part of the process side of that record.

IATF 16949, the automotive quality management standard, requires PFMEA explicitly. The AIAG/VDA FMEA methodology is the reference standard for automotive PFMEA, and it follows the same structure described in this guide with additional requirements for special characteristics and family FMEAs across product variants.

For manufacturers preparing for an audit and needing to produce or update their PFMEA documentation, the Aptibot documentation service runs PFMEA sessions, facilitates the cross-functional analysis, and produces the completed PFMEA table and action plan. For the validation protocols that address the process risks identified in the PFMEA, see the guide on IQ OQ PQ protocols.