FMEA and Legal Considerations
Abstract
Carl and Fred discussing common sense legal guidelines for doing FMEAs. The focus of FMEAs should be first and foremost on improving designs and manufacturing processes, and consistent with company legal policy.
Key Points
Join Carl and Fred as they discuss their experiences with FMEAs, with respect to good legal practices.
Topics include:
- What should be legal guidelines for FMEAs?
- Reference Effective FMEAs chapter 5, section 5.2.5 (posted in Show Notes)
- Focus on safe and reliable products
- Make factual entries into worksheets, absent emotional words
- Close loops in FMEAs with Actions Taken
- The document is for the design team, not for the legal department
- FMEA actions can be integrated into project tracking systems
- When should FMEA document be controlled?
- Never hide or omit raising issues
- What about recording FMEA sessions?
- Continue FMEA until risk is reduced to an acceptable level
- Safety is highest priority, even if occurrence is low
- Disagreement is an important part of getting to consensus
- Should management attend FMEAs?
Enjoy an episode of Speaking of Reliability. Where you can join friends as they discuss reliability topics. Join us as we discuss topics ranging from design for reliability techniques to field data analysis approaches.
- Social:
- Link:
- Embed:
Show Notes
Excerpt from Chapter 5, section 5.2.5 of Effective FMEAs:
5.2-5 Legal Guidelines for Doing FMEAs
It is important for the FMEA team to understand that FMEAs are legal documents that support the demonstration of due care in product development. As legal documents, they are subject to subpoena for legal proceedings. The FMEA team members should familiarize themselves with and adhere to any relevant company guidelines regarding legal documentation, and closely follow advises from company legal representatives. They should also follow common sense principles, such as:
- All FMEA database entries should be factual and absent of emotional words or exhortations.
- All FMEA database entries that state an action will be taken to address a problem should be closed out with a corresponding entry saying what specifically was done, leaving no “open loops.”
- All FMEA database entries should be detailed and specific enough so that anyone who is not part of the FMEA team can read the entry and understand the meaning and context.
- The FMEA team should never omit raising an issue or addressing a problem because it does not have an immediate solution or out of concern for legal ramifications. If there are important concerns that are legal in nature, the team should discuss these issues with management and company legal representatives.
- FMEA teams should continue the FMEA project until an acceptable level of risk is reached.
- Safety issues are always the highest priority, regardless of likelihood of occurrence. No FMEA is complete unless the FMEA team is satisfied that there are no unaddressed safety related issues within the scope of the FMEA project.
- When entering information into the FMEA database, care should be taken to characterize concerns as “potential” or “possible” when appropriate, unless the team is certain the issue will occur. One example is entering an effect that has a possibility of injury. Here it is appropriate to say “with the possibility of injury” rather than saying “will result in injury.”
Leave a Reply