PFMEA: A Practical Guide for Process Engineers

Start with a process step and a clear requirement

Before filling in a worksheet, define the analysis boundary and involve people who understand the process, its controls, and downstream requirements. ASQ recommends a cross-functional team and an explicit scope, boundary, and level of detail. A failure description is easier to evaluate when the intended function is specific. (ASQ)

For this example, we will use:

These dimensions are fictional teaching values, not recommended process specifications.

We are looking at the electroplating step. Later assembly operations provide the context for understanding potential effects, but they are not the process step being analyzed.

Keep the cause, failure mode, and effect separate

A failure mode describes how the process fails to meet its intended function. An effect describes the consequence. A potential cause explains how that failure might arise. Keeping these roles distinct makes the analysis easier to follow and makes each row testable.

Here is one proposed failure chain for our fictional process:

The effect requires an explicit assumption: for this example, the downstream joining process cannot accommodate the illustrated height shortfall. A real assessment would need the relevant assembly geometry and process requirements.

The cause also requires an assumption: the obsolete recipe provides insufficient deposition under the otherwise unchanged conditions of this teaching case. The illustrated 42 µm height is not a calculated prediction from a particular recipe.

The recipe is not the only possible cause

A real team would list several potential causes for the same failure mode, each as its own row with its own controls. For low pillar height, typical candidates include:

The first two causes come straight from Faraday's law: deposited thickness follows the charge delivered per unit of plated area. If the relationship is unfamiliar, see Copper electroplating and Faraday's law. PlatingMate can help when you need to work out charge from the actual pattern area rather than a nominal deposition rate.

Treat this list as a prompt for the team, not a complete cause analysis. Which causes are credible depends on your equipment, chemistry, and product.

Why the wording matters

"Low pillar height" identifies the failure mode, but it does not explain why it happened.

"Wrong recipe" suggests a cause, but it needs enough detail to investigate: which revision, which parameter difference, and how could that revision be selected?

"Poor quality" is too vague for this example. We need to identify the particular downstream function that could be affected.

A useful check is to read the three statements together:

Because this condition could occur, the process could miss this requirement, which could affect this downstream function.

If that sentence is difficult to explain, revisit the analysis boundary or the proposed relationship.

Describe the controls that actually exist

In the AIAG & VDA FMEA methodology, a prevention control reduces the likelihood that a failure cause occurs. A detection control finds the failure cause or the failure mode before the product moves on. How well a control works depends on how it actually operates, not on how it is named. (AIAG & VDA FMEA Handbook)

For our fictional process, assume the following controls already exist:

Current prevention control: Released recipes are maintained under revision control, with changes restricted to authorized personnel.

Current detection control: Selected copper-pillar heights are measured before the lot is released to the next operation.

These descriptions are a starting point, not evidence that the risk is adequately controlled.

For the recipe control, the team still needs to determine whether obsolete revisions remain selectable and how a product is matched to its approved recipe.

For the height check, the team needs to understand the measurement method, sampling locations, acceptance criteria, and response to a failed result. A sampled check should not be described as inspection of every pillar. If the sample covers only a few sites per wafer, a localized shortfall (for example, near the wafer edge) may pass undetected.

If the height data is already collected, trending it gives the team evidence about the detection control, not just about individual lots. An I-MR chart can show whether the process is drifting toward the lower limit. The SPC & Capability Analyzer can estimate capability from the same data. Before relying on capability numbers, check whether Cpk or Ppk fits the data you have.

Keep proposed improvements separate

Now suppose the team proposes an automated check that blocks a run when the selected recipe revision does not match the product's approved revision.

That is a proposed action, not an existing control.

In this example, it should remain identified as planned until implementation and verification evidence are available. Writing it into the worksheet does not make it operational.

Evaluate risk using the applicable method

Risk evaluation should follow the method and rating criteria selected for the application. Do not assemble a scoring system from unrelated online tables.

For example, the AIAG & VDA FMEA Handbook (1st edition, 2019) introduced a seven-step approach and an Action Priority method that replaces the traditional RPN. Action Priority considers severity, occurrence, and detection. It is a specific methodology, not a universal scoring rule for every manufacturing organization. (AIAG)

We do not assign scores to this teaching example. We lack the application-specific effect assessment, occurrence evidence, and control-performance information needed to justify them.

What we can show is the evidence each rating would need:

An unanswered question is something to investigate, not a reason to invent a reassuring number.

Turn the analysis into an action with evidence

For the proposed recipe-revision check, an actionable record would identify an owner, a target completion date, and the evidence needed to assess the change.

For this fictional case, the verification plan could examine whether the check:

• Blocks an obsolete or mismatched recipe in an approved test environment.
• Allows valid product–recipe combinations.
• Handles overrides and exceptions in a controlled, traceable way.

The team would then record what was implemented, what was tested, what remained unresolved, and whether the risk assessment should change.

This example does not recommend deliberately creating defects on a production line. Testing conditions and authority must be established before execution.

A completed action is also not the end of the document's usefulness. FMEA records are meant to be maintained as the process and its supporting knowledge evolve. (IEC 60812:2018)

Common mistakes to watch for

Before you close the worksheet

Check whether the written analysis still tells the same story.

• The height definition, requirement, and failure mode agree.
• The downstream effect states its assumptions.
• Each proposed cause is specific enough to investigate, and more than one cause has been considered.
• Existing controls are described as they actually operate.
• Future actions remain separate from existing controls and have an owner and verification plan.

The goal is not a worksheet with every cell filled. It is a risk explanation that another engineer can understand, challenge, and act on.

Sources and further reading

• ASQ — FMEA overview. A starting point for scope, functions, failure modes, effects, and team-based analysis. (asq.org)
• IEC 60812:2018 — Public scope and summary. Describes the purpose and general applicability of FMEA, including its planning, documentation, and maintenance. The full standard is a separate publication. (webstore.iec.ch)
• AIAG & VDA FMEA Handbook, 1st edition (2019). Defines the seven-step approach, prevention and detection controls, and the Action Priority method. This guide does not reproduce the handbook's rating tables or substitute for its full methodology. Public introduction: blog.aiag.org; purchase: aiag.org.