How to write a PFMEA, step by step

How to build a process FMEA that points your controls at the real risks, with a worked example and the mistakes that make one useless.

A PFMEA (process failure mode and effects analysis) is a structured way to ask, before the problem happens, how each step of your process could fail, what that would do to the customer and what stops it. To write one, list the process steps, how each could fail, the effect, the causes and your current controls. Then rate severity, how often it happens and how well you would detect it, and assign actions to the highest risks. It is a working document. Update it every time a complaint, a change or a near miss teaches you something.

What a PFMEA is for

A PFMEA is a risk review of your process, written down. It makes the team say, step by step, what could go wrong, how bad it would be and what currently stops it. Done well, it points your inspection, error-proofing and control plan at the risks that matter. Done badly, it is a binder for the auditor.

It is not the same as a control plan. The PFMEA is the thinking and the control plan is what you do about it. The Control Plan vs PFMEA guide shows how the two connect.

Before you start

  • A process flow. Every step from receiving to shipping, in the order it happens. Each step gets its own group of rows.
  • The right people. A process engineer, quality, someone who runs the operation and maintenance. A PFMEA written by one person at a desk finds what that person already knows. Bring in a supplier or customer voice where it matters.
  • Your history. Complaints, scrap and rework data, audit findings and near misses. These are failure modes you already know exist.
  • A rating scale. Your customer may require one. Agree it before anyone scores a row, so a 7 means the same thing to everyone.

The steps

  1. List the process step and its function

    Take “wash parts before plating.” The function is what the step must achieve: remove cutting fluid and chips so the plating bonds to a clean surface. A function says what must be true, not what happens.

  2. List how the step could fail

    These are the failure modes: not done, done wrong, done partly, done too early or too late. For the wash: parts not washed, wrong wash time, contaminated rinse. One row for each.

  3. Describe the effect

    What the next operation, the customer and the end user would see. Write the effect in terms someone outside the plant would recognize, such as “plating blisters and the customer scraps the lot.”

  4. Rate severity

    How serious the worst effect is, on a 1 to 10 scale where higher is worse. Severity belongs to the effect. Adding a control does not lower it. Only changing the product or the process so the effect is smaller can.

  5. List the causes

    Why would this failure mode happen? Be specific: “rinse tank not changed on schedule,” not “human error.” A three-legged 5 Why is a good way to dig for the real cause.

  6. List the current controls

    Two kinds, kept apart. Prevention controls stop the cause from happening: error-proofing, preventive maintenance, setup verification. Detection controls find the failure after it happens: inspection, gauging, testing.

  7. Rate occurrence and detection

    Occurrence is how often the cause happens given your prevention controls. Detection is how likely your detection controls are to catch the failure before it leaves. Both use 1 to 10, higher is worse. A detection of 10 means you almost certainly will not catch it.

  8. Decide what needs action

    Older practice multiplies the three ratings into a risk priority number (RPN). The AIAG and VDA FMEA handbook replaced it with Action Priority, which rates each combination as high, medium or low. Use the method your customer requires, and look at severity first either way. A severity of 9 or 10 gets a hard look even when the other numbers are low.

  9. Assign actions and re-rate

    Each action has an owner and a date. When it is done and verified, re-rate occurrence and detection and record the new scores. Actions that change the process flow into the control plan and the work instruction.

Worked example: one operation, three rows

The operation is washing machined housings before plating. These ratings are examples only. Use your own scale.

Failure modeEffectSevCausePreventionDetectionOccDet
Parts not washedPlating blisters. Customer scraps the lot.8Wash skipped on rush ordersRouting requires a wash scanNone before plating47
Rinse contaminatedPoor adhesion, found after plating8Rinse tank not changed on scheduleTank change checklistConductivity check each shift34
Wash time too shortOil left in blind holes7Timer set by handFixed timer with locked settingUV light check on first piece35

Under the older RPN method, row one multiplies out to 224 against 96 and 105 for the others. The reason it leads is not the multiplication. It is the detection score of 7: nothing checks the wash before plating starts. The right action is error-proofing, such as an interlock that stops the plating line loading parts that were never scanned out of the wash. Finding that row is the point of the whole exercise.

Keep it alive

A PFMEA written for launch and then filed is the most common failure. Treat every complaint, scrap spike and audit finding as a test. Did the PFMEA predict this? If not, either the failure mode was missing or the occurrence and detection scores were too optimistic. Fix the row, then carry the change into the control plan and the work instruction. Field Book 1, chapter 4 walks through exactly this with a real complaint.

Review it whenever the process, tooling, material or supplier changes, and on a schedule you set so it does not drift out of date.

Mistakes that make a PFMEA useless

  • Writing it after launch to satisfy an audit. It describes what you already did and tells you nothing new.
  • One person writing it alone. You get that person’s view of the process, not the process.
  • Vague effects. “Quality problem” cannot be rated. Say what the customer sees.
  • Causes like “operator error.” Ask what in the process made the mistake easy, and write that.
  • Giving detection credit it has not earned. A check by the person who made the part, or one part in 500, is a weak detection control. Score it honestly.
  • Lowering severity because a control was added. A control changes occurrence or detection. The effect is still the effect.
  • Scoring to get under a threshold. Rating a risk down so it needs no action hides it. It does not remove it.

The free PFMEA to Control Plan check flags PFMEA risks that have no control in the plan, and severity 9 and 10 risks with weak detection. The Process FMEA workbook gives the team a structured layout, and the PFMEA Risk & Control Bundle adds the control plan side.

Questions people ask

What is the difference between a failure mode, an effect and a cause?

The failure mode is how the step fails, what you would see at that step, such as “hole drilled off position.” The effect is what that does downstream or to the customer. The cause is why the failure mode happens.

Who should be on the PFMEA team?

A process or manufacturing engineer, quality, someone who runs the operation every day and maintenance, with supplier, customer or design input when the process depends on them. Operators know where the process really goes wrong.

What is the difference between a DFMEA and a PFMEA?

A DFMEA looks at how the design could fail. A PFMEA looks at how making or assembling the product could fail. The DFMEA usually comes first, because it identifies the characteristics the PFMEA must protect.

Should I use RPN or Action Priority?

Use whichever your customer requires. The AIAG and VDA handbook uses Action Priority. Both start from severity, and neither replaces judgment.

How often should a PFMEA be reviewed?

Whenever the process, tooling, material or supplier changes, and straight after any complaint or near miss that it did not predict. Many plants also set a yearly review.