Accendo Reliability

Your Reliability Engineering Professional Development Site

  • Home
  • About
    • Contributors
  • Reliability.fm
    • Speaking Of Reliability
    • Rooted in Reliability: The Plant Performance Podcast
    • Quality during Design
    • Way of the Quality Warrior
    • Critical Talks
    • Dare to Know
    • Maintenance Disrupted
    • Metal Conversations
    • The Leadership Connection
    • Practical Reliability Podcast
    • Reliability Matters
    • Reliability it Matters
    • Maintenance Mavericks Podcast
    • Women in Maintenance
    • Accendo Reliability Webinar Series
  • Articles
    • CRE Preparation Notes
    • on Leadership & Career
      • Advanced Engineering Culture
      • Engineering Leadership
      • Managing in the 2000s
      • Product Development and Process Improvement
    • on Maintenance Reliability
      • Aasan Asset Management
      • AI & Predictive Maintenance
      • Asset Management in the Mining Industry
      • CMMS and Reliability
      • Conscious Asset
      • EAM & CMMS
      • Everyday RCM
      • History of Maintenance Management
      • Life Cycle Asset Management
      • Maintenance and Reliability
      • Maintenance Management
      • Plant Maintenance
      • Process Plant Reliability Engineering
      • ReliabilityXperience
      • RCM Blitz®
      • Rob’s Reliability Project
      • The Intelligent Transformer Blog
      • The People Side of Maintenance
      • The Reliability Mindset
    • on Product Reliability
      • Accelerated Reliability
      • Achieving the Benefits of Reliability
      • Apex Ridge
      • Metals Engineering and Product Reliability
      • Musings on Reliability and Maintenance Topics
      • Product Validation
      • Reliability Engineering Insights
      • Reliability in Emerging Technology
    • on Risk & Safety
      • CERM® Risk Insights
      • Equipment Risk and Reliability in Downhole Applications
      • Operational Risk Process Safety
    • on Systems Thinking
      • Communicating with FINESSE
      • The RCA
    • on Tools & Techniques
      • Big Data & Analytics
      • Experimental Design for NPD
      • Innovative Thinking in Reliability and Durability
      • Inside and Beyond HALT
      • Inside FMEA
      • Integral Concepts
      • Learning from Failures
      • Progress in Field Reliability?
      • R for Engineering
      • Reliability Engineering Using Python
      • Reliability Reflections
      • Testing 1 2 3
      • The Manufacturing Academy
  • eBooks
  • Resources
    • Accendo Authors
    • FMEA Resources
    • Feed Forward Publications
    • Openings
    • Books
    • Webinars
    • Journals
    • Higher Education
    • Podcasts
  • Courses
    • 14 Ways to Acquire Reliability Engineering Knowledge
    • Reliability Analysis Methods online course
    • Measurement System Assessment
    • SPC-Process Capability Course
    • Design of Experiments
    • Foundations of RCM online course
    • Quality during Design Journey
    • Reliability Engineering Statistics
    • Quality Engineering Statistics
    • An Introduction to Reliability Engineering
    • Reliability Engineering for Heavy Industry
    • An Introduction to Quality Engineering
    • Process Capability Analysis course
    • Root Cause Analysis and the 8D Corrective Action Process course
    • Return on Investment online course
    • CRE Preparation Online Course
    • Quondam Courses
  • Webinars
    • Upcoming Live Events
  • Calendar
    • Call for Papers Listing
    • Upcoming Webinars
    • Webinar Calendar
  • Login
    • Member Home

by Carl S. Carlson Leave a Comment

Using the “Five Whys”

Using the “Five Whys”

Getting to Root Cause with “Five Whys”

There is no more important task in an FMEA than correctly identifying the “Cause.” Finding the root cause is the heart and soul of FMEA procedure. When you have the right cause, it opens the door to solutions. When you have the wrong cause, nothing gets accomplished.

By continuing to ask “why,” the team will be able to discover the progression of cause-and-effect relationships behind a problem and the root cause that is below the surface.

Wisdom begins in wonder – Socrates

why

The Oxford English dictionary defines “why” as “a reason or explanation.” Origin: Old English “by what cause.”

Recall the definition of “Cause” in FMEA

If you haven’t read the “Inside FMEA” article on Understanding FMEA Causes, this would be a good time to read the article.

A “cause” is the specific reason for the failure, preferably found by asking “why” until the root cause is determined. For Design FMEAs, the cause is the potential design deficiency that results in the failure mode. For Process FMEAs, the cause is the manufacturing or assembly deficiency (or source of variation) that results in the failure mode.

What are “five whys” and how are they used?

Many practitioners use repeated questioning of the FMEA team to ensure that the basic “why” is determined as the cause of a failure mode. This technique, called the Five Whys, can be very helpful, especially when the root cause is not forthcoming. The Five Whys is a technique developed by Taiichi Ohno, originator of the Toyota Production System. It means that by asking “why” five times, the team will be able to discover the progression of cause-and-effect relationships behind a problem and the root cause that is below the surface.

Rationale for “five whys”

Identifying the right “cause” in an FMEA is one of the most important concepts in effective FMEAs. It is impossible to over-stress the importance of fully analyzing and understanding the cause. A half-analyzed cause has little value, as the cause is the heart and soul of the FMEA. Take the example of a projector lamp shattering. If the FMEA team simply describes the cause as “over pressure” and does not ask why the over pressure, the root cause of “wrong gas” is not established. The team will end up trying to solve “over pressure,” and may miss recommending the correct gas specification. The problem will not be solved.

For high-risk issues, it is essential that root cause be identified. “Five whys” is a useful technique to help ensure the FMEA team achieves root cause.

FMEA Tip

Tip: When the FMEA team first identifies the cause of a failure mode (call it Cause A), it is useful to ask why the cause occurred. If there is a meaningful answer, then Cause A is not the root cause, and the team should continue asking “why” until root cause is determined.

Progression of failure mode and cause from system to subsystem to component

Appropriate failure mode and cause descriptions depend on the type of FMEA being performed: in some cases, the cause in a System FMEA will be the failure mode in the Subsystem or Component FMEA. The following excerpts from of a bicycle system FMEA, a hand brake subsystem FMEA and a brake cable FMEA will illustrate this concept. This excerpt is from chapter 3 of Effective FMEAs.

Failure Mode and Cause progression

The FMEA team needs to be aware at what level of the system hierarchy (system, subsystem, and component) the FMEA is being done. Remember, it is always necessary to get to root cause (and associated failure mechanism) for higher-risk failure modes. In this example, the FMEA team can use the Recommended Actions column of the hand brake subsystem FMEA to require a design FMEA on the brake cable, in order to get to root cause.

Excerpt from bicycle hand brake Design FMEA

In the Hand Brake Subsystem DFMEA, “cable breaks” is not a root cause. The FMEA team recommends “Require cable DFMEA and PFMEA from cable supplier . . .” in order to get to root cause.

“Corrosion of cable wiring due to wrong material selected” and “Fatigue cracks in cable wiring due to inadequate cable thickness” are root causes. The FMEA team can use techniques such as “five whys” to help ensure root cause is obtained.

Problem

An FMEA team is performing a Design FMEA on a projector lamp. They identify “lamp shatters” as one of the failure modes, and “pressure too high” as one of the causes. Is “pressure too high” a root cause? If not, how can the team use “five whys” to ensure root cause is obtained?

Solution

In this example, since the team can ask, “Why is the pressure too high” (and get a meaningful answer), they have not yet achieved root cause. By continuing to ask “why”, the team can follow the answers to discover the root cause: “over pressure in lamp due to wrong gas.”

FMEA Question

The important thing is not to stop questioning. – Albert Einstein

Reader:

With regard to System FMEAs, I would expect these to be done early in a project, and at a high level in the system’s hierarchy, meaning that the design elements being analyzed are going to be the main sub-systems and assemblies that will make up the product. Scoring the Severity seems straight forward, but scoring the Occurrence and the Detection seems a bit more problematic at the System FMEA level because one may not have any useful information about those metrics.

Do you find that you can apply the usual scoring scales for O and D at the system level, or do you handle these metrics in some other way for the System FMEA?

Carl:

It is often challenging to assess occurrence and detection for system FMEAs, as they occur early in the product development process, and objective data may or may not yet be available. There are ways to help with this assessment. First is good preparation, which includes having objective field-failure data on similar systems. It’s not perfect, as system configurations change, but it is helpful input to the discussion. Second is having the right team of subject matter experts in the room. They can be asked subjectively for their input to the likelihood of occurrence of the failure mode / cause. Third is having representation from the testing department on the team. This helps with the detection assessment, as to how well the currently planned testing or analysis methods can detect the failure mode / cause.

Next Article

FMEAs take time and cost money. They should be done when a certain level of risk can be effectively addressed by the FMEA procedure. The next article presents a tool called “Preliminary Risk Assessment,” which can be used to prioritize potential FMEA projects.

Ask a question about FMEA

In the words of Albert Einstein, “The important thing is never to stop questioning.” I invite you to ask anything at all about the broad subject of FMEAs. You may be curious about an application issue, or want another view on a challenge you are experiencing. Questions and answers are the lifeblood of learning, and we’re are all learning. I will answer all questions to the best of my ability, and promise to keep personal information confidential.

Filed Under: Articles, Inside FMEA, on Tools & Techniques

About Carl S. Carlson

Carl S. Carlson is a consultant and instructor in the areas of FMEA, reliability program planning and other reliability engineering disciplines, supporting over one hundred clients from a wide cross-section of industries. He has 35 years of experience in reliability testing, engineering, and management positions, including senior consultant with ReliaSoft Corporation, and senior manager for the Advanced Reliability Group at General Motors.

« Are You Selfish
Paul Crocker Interview »

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Articles by Carl Carlson
in the Inside FMEA series

[popup type="" link_text="Logo Info" ]

Information about FMEA Icon

Inside FMEA can be visually represented by a large tree, with roots, a solid trunk, branches, and leaves.

- The roots of the tree represent the philosophy and guiding principles for effective FMEAs.
- The solid trunk of the tree represents the fundamentals for all FMEAs.
- The branches represent the various FMEA applications.
- The leaves represent the valuable outcomes of FMEAs.
- This is intended to convey that each of the various FMEA applications have the same fundamentals and philosophical roots.

 

For example, the roots of the tree can represent following philosophy and guiding principles for effective FMEAs, such as:

1. Correct procedure         2. Lessons learned
3. Trained team                 4. Focus on prevention
5. Integrated with DFR    6. Skilled facilitation
7. Management support

The tree trunk represents the fundamentals of FMEA. All types of FMEA share common fundamentals, and these are essential to successful FMEA applications.

The tree branches can include the different types of FMEAs, including:

1. System FMEA         2. Design FMEA
3. Process FMEA        4. DRBFM
5. Hazard Analysis     6. RCM or Maintenance FMEA
7. Software FMEA      8. Other types of FMEA

The leaves of the tree branches represent individual FMEA projects, with a wide variety of FMEA scopes and results. [/popup]

Join Accendo

Receive information and updates about articles and many other resources offered by Accendo Reliability by becoming a member.

It’s free and only takes a minute.

Join Today

Recent Posts

  • test
  • test
  • test
  • Your Most Important Business Equation
  • Your Suppliers Can Be a Risk to Your Project

© 2025 FMS Reliability · Privacy Policy · Terms of Service · Cookies Policy