Students will be introduced to failure modes and effects analysis (FMEA) and failure modes and effects and criticality analysis (FMECA), and they will be taught how they can both be used to make their first design a reliable design. The course structure and schedule are also covered.

FMEAs are commonly misunderstood and seen as a bureaucratic formality. When done well, FMEAs greatly accelerate production, slash costs by eliminating problems and crises, and allow novel design features to be incorporated when it is fast and easy.

Students will be taught the differences between design, software, and process FMEAs and how they interact with each other. This course focuses on design FMEAs that focus on creating new or updated products.

A good FMEA is scheduled and facilitated well. That involves allocating time for specific analysis steps and moving on when that time expires (even if the whole item is not completely analyzed). Good FMEAs are those that do the most important part of the item well and not all of the item poorly. Students will learn how FMEA block diagrams can help facilitation.

The ‘root causes’ of failure aren’t corrosion, suppliers, customers, the weather, or the schooling system. They are (by definition) decisions we did (or didn’t) make. Anything else (by definition) is something we can’t influence and is therefore, an environmental consideration we must accommodate. Students learn how embracing this concept allows changes to be made that quickly and cheaply address design weaknesses.

Good FMEAs involve creating (or recreating) a use case regardless of what has been completed beforehand. This allows specific characters (with names) to be used in the FMEA workshop to facilitate brainstorming and the identification of potential root causes of failure.

Students will learn how to develop a use case using brainstorming tools that can be supplemented with artificial intelligence.

A ‘requirement’ is what a customer or user wants to be able to do with an item, system, or product. One of the first steps of any FMEA is ‘requirements analysis’ where participants brainstorm (and understand) the different things customers and users want to do (even if this has been completed). Students will learn how this helps set up the workshop, where participants empathize with those using the item.

‘Functions’ are things the item in question does. ‘Requirements’ are the language of the customer or user. ‘Functions’ are the language of the designer. Students will learn how ‘functions’ support ‘requirements,’ which supports how FMEAs find potential root causes of failure.

‘Functional failure modes’ are what your item is (or is not) doing as a result of failure. Students will learn what these are at the system and component levels and how they can be used to prioritize which failures we focus on first.

If all failures are important, then no failures are important. Students will learn how to easily classify the ‘severity’ of different failures using criteria that are easy to understand and allow rapid classification during a FMEA workshop to help maintain momentum.

Students will participate in a workshop where ‘severity scales’ are developed, and criteria for different failure events are determined so that a numerical score can be attributed to different failure scenarios. The more well-thought-out this process is, the easier classification is during the workshop.

‘Physical failure modes’ are the physical aftermath of a failure mechanism. This could be a ‘fracture,’ ‘deformation,’ ‘delamination,’ or whatever else describes what the ‘broken bit’ looks like. Students will learn what ‘physical failure modes’ are and how they relate to other ‘failure modes.’

‘Failure mechanisms’ are the physical, chemical, electrical, thermal, or other natural process that results in failure (think ‘fatigue,’ ‘corrosion,’ ‘wear,’ and so on). Each ‘failure mechanism’ is triggered by something called a ‘fault,’ which is the circumstance that gives rise to failure. ‘Faults’ can be physical (such as manufacturing defects or imperfections), a poor design choice (where the wrong material is used), or anything else. Students will learn about ‘failure mechanisms’ and ‘faults’ that allow them to understand how we can identify potential root causes of failure.

We always want to focus our FMEA efforts on the ‘vital few.’ There is no point in focusing on removing failure scenarios that are possible but highly unlikely. Students will learn how ‘occurrence’ can be used to help characterize the likelihood of different failure scenarios to ensure that (in conjunction with the ‘severity’ of each failure) we only ever focus on the ‘vital few.’

Students will participate in a workshop where ‘occurrence scales’ are developed with criteria for different timeframes for failure determined in a way where a numerical score can be attributed to the speed at which different failure mechanisms occur.

The ‘faults’ that trigger different failure scenarios can sometimes be detected during production. Something like a bend in metal that is too sharp (thereby amplifying local stresses beyond a critical level) might be detected during something like ‘finite element analysis (FEA).’ Students will learn about the ‘detectability’ of different failure scenarios, allowing us to pay less attention to or ignore failure scenarios we will likely pick up anyway.

Students will participate in a workshop where ‘detectability scales’ are developed with criteria for different timeframes for potential detectability during the normal production process.

If every failure is important, then no failure is important. Potential failure scenarios need to be ranked in terms of risk based on ‘severity,’ ‘occurrence,’ and (if included) ‘detectability.’ Students will learn how to use this prioritization to focus on the ‘vital few’ failure scenarios for design improvement.

FMEAs are not about admiring problems. They are about preventing them. Students will learn how the prioritized failure scenarios can be analyzed for different ‘corrective actions (CAs)’ to be identified to prevent those scenarios from occurring. The earlier CAs are identified, the faster, simpler, and cheaper they are to implement.

Maintenance strategies are often identified after a design is finalized. This robs a lot of potential for truly optimized maintenance strategies, as slight design modifications allow extraordinary maintenance efficiency improvements. Students will learn how to embed maintenance considerations into a FMEA seamlessly.

Some systems are very complex. Completing a FMEA on the entire system can be unfeasible. System FMEAs can help break down the task by focusing on the system at a high level and then (amongst other things) identifying the components and subsystems that will be subjected to more specific FMEA efforts. Students will learn how system FMEAs can help you work out what part of your system you need to (and which you don’t need to) focus on.

A ‘criticality analysis’ is a poorly defined activity that often focuses on the ‘failure rates’ of different failure scenarios to help inform logistic and support activities (like sparing and repair). Students will learn how ‘criticality analyses’ can be used, effectively converting a FMEA to a FMECA (‘failure mode, effects, and criticality analysis).

A good FMEA workshop doesn’t just happen. A FMEA workshop is a brainstorming workshop of 4-8 cross-functional representatives with an amazing facilitator. Students will learn how to prepare for and execute an amazing FMEA workshop.

Students will participate in a system and design FMEA workshop based on either a smart lock or an item from an organization (should training be delivered to that organization).

A summary of all the core concepts we covered in the course and brief review of key takeaways.