Most PFMEAs fail the same way: they are written to satisfy an audit, then never opened again. This walks through running one so that what comes out of it ends up in the control plan and on the floor.
1. Get the process flow right first
Walk the line and write down what actually happens, including the rework loop and the inspection nobody documented. A PFMEA built on an idealised flow analyses a process that does not exist.
2. Bring the operators
The people who run the process know the failure modes, and engineering knows the severity. You need both in the room, and the session has to be short enough that the operators are not pulled off the line for a full day.
3. Score severity before anything else
Severity is a property of the effect on the customer and does not change with your controls. Fixing it in the first pass stops the table drifting later.
4. Make every action land in the control plan
An action has to change a control, a check frequency or a reaction plan. If you cannot write it into the control plan, it has not changed anything.
5. Set the trigger for revisiting it
Tie reviews to events such as a new failure mode, an engineering change or a process change, instead of to a date on the calendar. In our experience calendar reviews get skipped and event-driven ones get done.
What we would do differently
On our first attempt we scored occurrence from warranty data, which lagged the process by months and made the ranking wrong. Use in-process data where it exists, and say so when it does not.
This is a sample post. It shows how a Tutorial is laid out, and it is also flagged as a Lesson, so it appears under Lessons Learned as well as here. Delete it or replace it once there is real material to publish.