Six Sigma and Beyond: Design for Six Sigma, Volume VI

Common team problems that may make it difficult to get the most from FMEA include:

• Poor team composition (not cross-functional or multidisciplinary )

  • Low expertise in FMEA

  • Not multi-level

  • Low experience/expertise in product

  • One-person FMEA

• Lack of management support

• Not enough time

• Too detailed, could go on forever

• Arguments between team members (Opinions should be based on facts and data.)

• Lack of team enthusiasm /motivation

• Difficulty in getting team to start and stay with the process

• Proactive vs. reactive (a "before the event" not "after the fact" exercise)

• Doing it for the wrong reason

Common procedural problems include:

• Confusion about, poorly defined or incomplete functions, failure modes, effects, or causes

• Subgroup discussion

• Using symptoms or superficial causes instead of root causes

• Confusion about ratings as estimates and not absolutes (It will take time to be consistent.)

• Confusion about the relationship between causes, failure modes, and effects

• Using "customer dissatisfied" as failure effect

• Shifting design concerns to manufacturing and vice-versa

• Doing FMEAs by hand

  • Dependent on the engineers ' "printing skills"

  • RPNs or criticality cannot be ranked easily

  • Hard to update

  • Much space taken up by complicated FMEAs

  • Time consuming

  • Resistance to being the "recorder" when done manually

  • Inefficient means of storing and retrieving info

    Note	With FMEA software these are all eliminated.

• Working non-systematically on the form (It is suggested that the failure analysis should progress from left to right, with each column being completed before the next is begun.)

• Resistance of individuals to taking responsibility for recommended actions

• Doing a reactive FMEA as opposed to a proactive FMEA (FMEAs are best applied as a problem prevention tool, not problem solving tool, although one may use them for both. However, the value of a reactive FMEA is much less.)

  • Not having robust FMEA terminology (A robust communication process is one that delivers its "function" [imparting knowledge and understanding] without being affected by "noise factors" [varying degrees of training]. Simply stated, the process should be as clear as possible with minimum possibility for misunderstanding.)

Institutionalizing FMEA in your company is challenging, and its success is largely dependent upon the culture in the organization as well as the reason it is being utilized. Below are some main considerations:

• Selecting pilot projects (Start small and build successes.)

• Identifying team participants

• Developing and promoting FMEA successes

• Developing templates (databases of failure modes, functions, controls, etc.)

• Addressing training needs

Figure 6.21 shows the learning stages (the direction of the arrows indicates the increasing level) in a company that is developing maturity in the use of FMEA.

Figure 6.21: The learning stages.