FMEAs are legal documents that support the demonstration of due care in product development. FMEA teams should ensure their worksheets are consistent with good legal practices for documents, and follow company legal guidelines.
“Common sense often makes good law.” William Orville Douglas, past Justice of the Supreme Court
Excerpt from chapter 5 of Effective 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:
1. All FMEA database entries should be factual and absent of emotional words or exhortations.
2. 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.”
3. 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.
4. 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.
5. FMEA teams should continue the FMEA project until an acceptable level of risk is reached.
6. 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.
7. 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.”
The focus of FMEA needs to be on problem prevention, anticipating the factors that lead to failure and helping achieve safe and reliable products and processes. Following legal guidelines is necessary, but should not detract from the primary purpose of FMEA.
Complex systems often integrate mechanical, electrical, and software elements. It is becoming increasingly necessary to include software in FMEA applications. This next article discusses the subject of Software FMEA.