The PFMEA was 47 pages long. It had 340 failure modes listed across 28 process steps. Every failure mode had an effect, a severity rating, an occurrence rating, a detection rating, and an RPN — risk priority number — calculated with admirable precision. It was the most impressive quality document I had ever seen. And it was completely useless.
I inherited this PFMEA when I took over quality at an automotive plant. I read it cover to cover on my first weekend. By Monday morning, I knew two things: first, that the team that wrote it had worked very hard, and second, that it had not prevented a single defect in the two years since it was created.
The numbers problem
The fundamental problem with this PFMEA — and with most PFMEAs I see — was that the scoring was so uniform that it provided no discrimination. Of the 340 failure modes, 312 had RPN scores between 80 and 160. This means that 92 percent of the failure modes were classified as roughly the same risk. When everything is the same risk, nothing is high risk. The PFMEA had become a list rather than a prioritisation tool.
The severity ratings were almost all 7 or 8 — "high" on the scale. The occurrence ratings were almost all 4 or 5 — "moderate." The detection ratings were almost all 4 or 5 — "moderate." Nobody had the courage to score anything below 4 because a low score meant the risk was under control, and if the risk was under control, someone might ask why it was in the PFMEA at all. Nobody had the courage to score anything above 8 because a 9 or 10 meant the risk was unacceptable, and an unacceptable risk required immediate action.
The result was a bell curve of scores clustered around the middle, providing zero prioritisation value. The PFMEA was not identifying the risks that mattered. It was listing every conceivable failure mode and giving them all the same score.
A PFMEA that identifies 340 failure modes has not done a thorough analysis. It has done a brainstorming session. The value of a PFMEA is not in how many failure modes it identifies but in how few it prioritises.
What I did
I threw the 47-page PFMEA away. Not literally — the auditor would have had questions. But I started over with a blank sheet and a different approach.
First, I assembled the cross-functional team: process engineer, quality engineer, production supervisor, operator from the line. Not consultants, not managers — the people who ran the process every day.
Second, I gave them a rule: we identify failure modes that have actually occurred or are reasonably foreseeable based on process data. Not theoretical failure modes. Not every conceivable thing that could go wrong. Failure modes that the process history and the process physics tell us are real.
Third, I calibrated the scoring. Before we started, I had the team score three reference failures from our own history — failures we understood well. This anchored the scale. When they scored a new failure mode, they compared it to the reference points. This prevented the clustering problem — a failure mode that was less severe than the known reference got a lower score, period.
The result: 47 failure modes. Not 340. Forty-seven. Of those, 12 had RPN scores above the action threshold. Of those 12, six were addressed with engineering changes, four were addressed with improved detection controls, and two were accepted with documented rationale.
What changed
The new PFMEA was seven pages long. It was readable. The operators could understand it. The process engineers used it as a working document, not a reference shelf artefact. And it predicted failures — in the first year, three of the six engineering changes we made prevented failure modes that subsequently appeared at similar plants in the company network.
The certification auditor reviewed the new PFMEA and noted that it was significantly shorter than the previous version. I explained the approach. She said it was one of the best PFMEAs she had seen. The length was not the point. The discrimination was the point.
Why teams inflate PFMEAs
There is a perverse incentive in PFMEA development: the more failure modes you list, the more thorough you appear. A short PFMEA feels incomplete. A long PFMEA feels comprehensive. So teams err on the side of inclusion, listing every failure mode they can imagine, and the document balloons to hundreds of entries that nobody can prioritise.
I have seen PFMEAs with 500+ failure modes that were never reviewed after initial creation. I have seen PFMEAs where the recommended actions column was blank for 80 percent of entries. I have seen PFMEAs where the same failure mode was listed three times under different process steps because the team did not recognise the duplication. These documents exist to satisfy a requirement, not to manage risk.
A PFMEA should be a living tool that drives engineering decisions. It should be reviewed when the process changes, when a new failure mode is discovered, and when a near-miss reveals a gap. It should be short enough to read in one sitting and specific enough to act on. If your PFMEA has more than 100 failure modes, it is probably trying to do too much. If it has more than 200, it is almost certainly useless.
Kill the 340-failure-mode PFMEA. Build a 47-failure-mode PFMEA that actually matters. Your defect rate will thank you.
