FMEA (Failure Mode and Effects Analysis) is a super-tool for a team, especially when developing concepts and requirements. Done early, iteratively, and treated as a "living" analysis helps teams throughout development and beyond.
Some people seem to either love it or hate it. I don't have a strong reaction like that, but I do think it can be a valuable option for teamwork and design - so much so that I've dedicated a few episodes to it (including this one). We touch on some of the objections to it, too.
FMEAs can have different focuses and can be built to suit the goals of the team. There are two FMEAs, in particular, that can be done in the early concept stages of development: “use” UFMEA and “systems design” DFMEA.
- What is the difference between these two FMEAs?
- How do they relate to one another?
- Should we do both of them?
- What do we do with the information?
FMEA is not the only way to assess risk and make risk-based decisions. Here are a few other options:
- ETA, FTA – to get more detail on multiple causes of a failure event
- SWIFT – Structured What-If Technique
- User process flow or task analysis
TIP – Many of these can be done with a team and then used as an input into an FMEA to take it further.
What's today's insight to action? Do risk analyses early and iteratively. Consider using both UFMEA and systems DFMEA because they focus on different things. Think about the user and the product itself because we’re designing products as an interface to DO something for a user.
Visit these other blogs to explore these topics further: