FMEA
Training That Actually Works: How Zeus and I Train Teams to Think
Differently About Failure
Let me be honest about something. Most FMEA training is terrible.
I’ve sat through enough of it to know. Someone stands at the front of
a conference room, puts a slide on the projector that says “Failure Mode
and Effects Analysis,” and proceeds to read definitions from the
AIAG-VDA handbook while the audience quietly checks their phones. By the
time the facilitator gets to the risk priority number matrix, half the
room is gone — physically present, mentally elsewhere.
That’s not training. That’s a sleep aid.
When I design FMEA training, I do it differently. And when Zeus — my
colleague and co-facilitator — is in the room with me, we make sure
nobody is checking their phone. Not because we’re entertaining, but
because what we’re teaching actually matters to the people sitting in
those chairs.
Why FMEA Training
Fails (Before You Even Start)
Here’s the fundamental problem. Most companies treat FMEA as a
document. A checkbox. Something you create because the auditor asked for
it, file it in the quality system, and never look at again until the
next audit.
Zeus and I start every training session the same way: we ask the
room, “When was the last time you opened an FMEA that wasn’t during an
audit?”
The silence is usually deafening.
The answer tells you everything. If your team only touches FMEAs
during audits, your FMEA process is already broken. Training won’t fix a
broken process — it’ll just teach people how to go through the motions
faster. So before we train anyone, we make sure the process itself is
worth learning.
The Training
Structure: How Zeus and I Run It
Our FMEA training is a two-day workshop. Not two days of lectures —
two days of doing. Here’s how it breaks down.
Day 1: Foundation and
Failure Thinking
Morning — The Mindset Shift
Zeus opens with a simple exercise. He puts a everyday object on the
table — a coffee maker, a door hinge, a ballpoint pen — and asks the
group to list every possible way it could fail. Not likely failures.
Every failure.
The first ten minutes are always awkward. People are cautious. They
list the obvious: “The coffee maker could stop heating.” “The pen could
run out of ink.” Then Zeus pushes. “What if the heating element works
but the thermostat fails? What if the pen still writes but the mechanism
jams intermittently?” He keeps pushing until the whiteboard is covered
in failure modes nobody considered.
That’s the point. FMEA isn’t about listing the failures you expect.
It’s about discovering the failures you don’t.
I take over for the afternoon. We move from abstract failure thinking
to the structured methodology. I walk them through:
- Function analysis — what is the product or process
supposed to do? If you can’t define the function clearly, you can’t
analyze its failure. - Failure mode identification — how could the
function not be achieved? - Effects analysis — what happens if the failure
occurs? Who notices? When? - Severity ranking — how bad is it? (And bad for whom
— the operator, the customer, the end user?) - Occurrence ranking — how likely is it?
- Detection ranking — can you catch it before it
reaches the customer?
I don’t use slides for this. I use a real product — something from
their own production line. I bring a component, a process flow diagram,
and we build an FMEA together, right there, on flipchart paper. Messy,
iterative, real.
Afternoon — The AIAG-VDA Approach
Zeus leads the session on the AIAG-VDA harmonized methodology. This
is where we get into the structure that most trainings rush through:
- Structure Analysis — breaking down the system into
subsystems, components, and process steps - Function Analysis — defining functions and
interfaces - Failure Analysis — linking failure modes to
functions - Risk Analysis — scoring severity, occurrence, and
detection - Optimization — defining actions, assigning owners,
tracking closure
Zeus is methodical. He doesn’t skip steps. He explains why each step
exists — not just what to do, but why it matters. “Structure Analysis
isn’t bureaucracy,” he tells the group. “It’s how you make sure you
don’t miss a failure mode hidden in an interface between two
subsystems.”
Day 2: Application and Action
Morning — Build a Real FMEA
This is where most trainings fall apart. They teach you the theory,
show you a textbook example, and send you home. Zeus and I don’t do
that.
On Day 2 morning, we split the group into teams of three. Each team
picks a real process from their own facility — something they work on
every day. Their task: build a complete FMEA for that process using the
methodology from Day 1.
Zeus and I circulate. We sit with each team. We challenge their
assumptions. We ask:
- “Did you consider how this process step interfaces with the previous
one?” - “Your severity rating is a 7 — who is affected? The operator? The
customer? The next station?” - “Your detection rating is a 3 — how? What inspection method catches
this? Is it reliable?”
The teams struggle. That’s intentional. FMEA is supposed to be hard.
If it’s easy, you’re not thinking deeply enough about failure.
Afternoon — Review and Action Plan
Each team presents their FMEA. The rest of the group critiques. Zeus
and I facilitate. We look for:
- Completeness — did they cover all process steps and
interfaces? - Consistency — are the severity, occurrence, and
detection ratings logically consistent? - Actionability — do the recommended actions actually
address the highest risks? - Traceability — can they trace each failure mode
back to a specific function?
This is where the real learning happens. When a team presents a
severity rating of 9 for a failure mode they hadn’t even considered that
morning, and the rest of the group nods because they missed it too —
that’s the moment FMEA stops being a document and starts being a way of
thinking.
What Zeus Brings to the
Training
I’ve trained FMEA for years. I know the methodology inside out. But
Zeus brings something I can’t — a different perspective on risk.
Where I tend to focus on the quality system and compliance angle
(because that’s my background), Zeus thinks about risk from an
operational standpoint. He asks questions I wouldn’t think to ask: “What
happens to the upstream process if this failure is detected here? Does
the upstream station need to adjust?” He forces the group to think
beyond the immediate failure — to consider the cascading effects across
the entire production system.
Together, we cover both sides. The quality compliance perspective and
the operational impact perspective. That combination is what makes the
training effective. One without the other gives you half the
picture.
The Results
I’ll give you a concrete example. We ran this training at an
aerospace supplier last year. The team built an FMEA for their composite
layup process during the workshop. They identified a failure mode in the
curing cycle that had a severity of 9 and a detection of 8 — meaning if
it happened, it would be catastrophic, and they had almost no way of
catching it.
They implemented a process change the following week: an in-situ
thermocouple monitoring system that caught temperature deviations during
cure in real time. Detection dropped from 8 to 2. Three months later,
they hadn’t had a single defective composite part reach final
inspection.
That’s what FMEA training should produce. Not a completed form. Not a
satisfied auditor. A process change that prevents defects.
Lessons
Learned from Training Hundreds of Engineers
After running this workshop dozens of times, here’s what I’ve
learned:
-
Start with the object, not the standard. Don’t
open the AIAG-VDA handbook in the first hour. Start with a coffee maker
and failure thinking. The standard makes sense once you understand why
it exists. -
Use their process, not a textbook example.
People learn FMEA by doing FMEA on something they know. Textbook
examples are too abstract — they don’t trigger the “oh, we have this
problem” moment. -
Make them struggle. If the workshop is
comfortable, it’s not working. FMEA requires deep thinking about
failure, and deep thinking is uncomfortable. That discomfort is where
learning happens. -
Two facilitators are better than one. Zeus and I
see different things. We challenge the group from different angles. A
single facilitator, no matter how good, has blind spots. -
Action items must be real. Don’t let the
workshop end with “we’ll look into this.” Every high-risk failure mode
gets an action item, an owner, and a due date — before the team leaves
the room.
Closing Thoughts
FMEA is the most powerful quality tool we have. It’s also the most
misused. When it’s treated as a document, it’s waste. When it’s treated
as a way of thinking — a disciplined approach to understanding how
things fail and what to do about it — it transforms how an organization
manages risk.
Zeus and I will keep training it the way we do. Not because it’s the
easy way, but because it’s the way that works. And when a team comes
back six months later and tells us they caught a failure mode in design
that would have cost them six figures in scrap — that’s when we know the
training landed.
Peter Stasko is a Quality Director with 20+ years of experience
leading quality management systems across the automotive and aerospace
industries. He has implemented and transitioned ISO 9001 systems at
Airbus, SNOP, and WITTE Automotive, and has trained hundreds of
engineers in FMEA, root cause analysis, and quality system
design.
