Project Management Institute

UseFMEAs to improve your product development process

img

by Jim Bongiorno, PMP

If you are going to spend money on Failure Modes and Effects Analysis (FMEA) projects to meet customer or government mandates, then go ahead and be a little selfish—get some business value from them! FMEAs should be a business investment to create superior products and thereby improve the corporate bottom line. As auto manufacturers and their supply chains move toward implementing quality standards in their Product Development Process (PDP), the fact that you do FMEAs doesn't set you apart from the rest. By attaining value from the FMEA process you not only improve your organization's business value but also position your company outside the reach of your competitors. This article is intended to help manufacturing organizations get the most from their FMEA efforts so that they can improve their business performance.

FMEA is a risk identification and mitigation strategy used during product development. How does an organization go about improving the FMEA process to yield desirable results? That's a 10-part answer:

Apply project management processes and methodologies to FMEA work; in other words, projectize FMEAs.

Ensure that the FMEA to be undertaken is occurring early in the product development process.

Commit yourself to doing upfront research before launching the FMEA project.

Identify an appropriate FMEA sponsor to represent the best interests of the team.

Ensure that the right people who possess the necessary knowledge, skills, and attitudes are responsible for executing the FMEA work.

See that an experienced FMEA expert with a solid technical background facilitates the FMEA sessions.

Avoid getting caught-up in FMEA technology; a simple electronic spreadsheet and an overhead projector may be all that you need.

Standardize the scales used to measure the three components of FMEAs: Severity, Occurrence, and Detection (SOD).

Engage in risk reduction, not number reduction.

Implement a thorough review process where lessons learned are logged and made readily available so that rework is minimized and the FMEA learning process is streamlined.

Let's consider each of these points in detail, occasionally using the example of designing a retractable sunroof for a new vehicle line. In this case, your customer, a large automotive OEM (original equipment manufacturer), requires you to show proof that the design of the sunroof is sound so as to prevent gross quality defects in the final product. As the design approval engineer, you are charged with overseeing the planning of a thorough and efficient design test and therefore decide to use a Design FMEA (D-FMEA) as your quality assurance report.

Projectize FMEAs. You must first realize that this assignment is indeed a project and not an operation. It's start and finish dates are predetermined by the product development cycle. This D-FMEA has a defined project work scope that can be developed through the use of a project charter worksheet. The scope of a D-FMEA is limited to the design of the product, including issues of manufacturability and assembly in addition to functional and hardware requirements.

Another clue that the D-FMEA is indeed a project is that it is a one-time activity, which, in the case of a D-FMEA, is to document the design thought process. However, a D-FMEA report should be seen as a living document that will be modified as learning occurs over the course of future product development life cycles. Consider the completed D-FMEA as a “first pass” effort that has satisfied an initial goal but will evolve over time.

Do D-FMEAs at the Right Time. Any successful D-FMEA initiative must occur at the right time in the product development process to be of maximum impact. D-FMEAs should be initiated at or before design concept finalization and completed before production drawings are released for tooling. The output of a D-FMEA project serves as the blueprint for the manufacturing process. Otherwise, D-FMEA efforts will likely be useless. D-FMEA results will have little, if any, impact if realized during the part procurement or product development stages. Too often is the case where D-FMEA projects are launched during production.

Failing to complete D-FMEA projects early in the product development process can have grave consequences to the bottom line. Time-to-correct metrics will be much greater if, for example, the D-FMEA engineers reveal only after Purchasing has already ordered one-fourth-inch-thick sheets of glass that they will, in fact, need glass twice as thick to outfit the vehicles with sunroofs. (Imagine, too, if Purchasing is required to get four bids and interview each potential supplier before procuring the parts!) In other words, identifying and preventing design failure modes during the design phase is far less costly than if those failure modes surfaced during procurement and production.

Further, lessons learned after a timely D-FMEA project is completed can help modify the plan and establish new requirements in the subsequent product development process phases. For example, it is realized during the D-FMEA that the sunroof's weather strip cannot exceed three-quarters of an inch in thickness to fit properly on the roof of the new vehicle line. The result might be that a new test is required during the development phase to find the optimum thickness of the weather strip. Such a revelation and call to action is much better than outfitting thousands of vehicles with an incorrectly sized part.

Do Up-front Research. It is highly recommended that research be done on similar D-FMEAs before work begins. Pore through documents containing important field data relating to previous sunroof designs and design oversights. Here are some things to look for:

 

Reader Service Number 084

For each design requirement, the potential failures in addition to their effects, causes, and controls are recorded and quantified in the Severity (S), Occurrence (O), and Detection (D) columns, respectively. The analysis section is complete when the S, O, and D columns reveal the risk priority number (RPN). In the ROI section of the template, actions are recommended, responsibilities are assigned, and results are recorded to yield a new, hopefully lower, RPN

Exhibit 1. For each design requirement, the potential failures in addition to their effects, causes, and controls are recorded and quantified in the Severity (S), Occurrence (O), and Detection (D) columns, respectively. The analysis section is complete when the S, O, and D columns reveal the risk priority number (RPN). In the ROI section of the template, actions are recommended, responsibilities are assigned, and results are recorded to yield a new, hopefully lower, RPN.

Warranty costs (costs associated with replacing or fixing problem sunroofs that customers have returned within the warranty period)

Recall campaigns (costs associated with manufacturer recalling failed sunroofs on new vehicles)

J.D. Power rankings (leading authority in ranking the quality of similar products produced by different manufactures)

Pulls (defective parts that must be pulled off the assembly line due to design or process failures)

Scrap (permanently defective parts that must be thrown out due to design or process failures).

Analyzing the field data before committing to designing a new sunroof may help save time by preventing unnecessarily repeating steps, help bring to surface any unrealized steps, and help prevent similar problems from reoccurring.

Identify a Sponsor. Sponsorship should not be an option; rather, it is a requirement. Projects are usually done well with an exceptional sponsor who serves many roles: the champion of the project who looks out for the best interest of the team; the single source of authority, resources, and accountability to call for and support the D-FMEA project; and the source of funding (need anything else be said). A good D-FMEA sponsor will follow up with the team at each milestone throughout the D-FMEA project. Based on feedback from the team, the sponsor helps decide where the biggest bottlenecks lie and helps remove them. In addition, the sponsor decides where to spend allotted money during the D-FMEA project and helps shape D-FMEA spending in the future. In general, sponsors are open-minded individuals who can encourage teams to reveal problems and ensure that no one will be labeled a complainer for pointing out shortcomings. In many ways, the sponsor represents the importance of D-FMEAs.

Assemble the Right Team. Good FMEAs result from good teams. If I were held responsible for a D-FMEA, I would want the most experienced, knowledgeable, and motivated engineers I could find. Individuals with these characteristics help ensure that everyone on the D-FMEA team is present at all FMEA sessions and are properly prepared every time. Without a prepared and motivated team, FMEA sessions can turn into extended post-lunch naps.

A simple suggestion for motivating FMEA teams is to pass around a sign-in sheet. Or simply ask team members to fill in certain sections of the FMEA template before each session to facilitate discussions. Generally, when people are encouraged to participate and to make the D-FMEA their own, they know that their contributions are helping to make a difference.

Identify a Facilitator. An experienced FMEA facilitator can be the difference between a successful D-FMEA and a poor one. Because most organizations lack experienced D-FMEA facilitators who are objective, practical, and unbiased toward the FMEA process, hiring an outside FMEA consultant is worthwhile. Perhaps a less obvious, but equally important, attribute that the facilitator must possess is unwillingness to compromise. (For more on this see the discussion on standardizing scales.)

Experience is key; someone who has facilitated many FMEA sessions will be properly prepared, able to answer most questions, and unlikely to give in to the team's whims. In addition to having significant FMEA facilitation experience, this individual should be technically competent in terms of understanding design and manufacturing processes. The best FMEA facilitators use FMEA templates and standard scales for the severity, occurrence, and detection rankings for calculation of the Risk Priority Number (RPN). Exhibit 1 shows a sample D-FMEA template.

Here are simple suggestions to help manufacturing organizations avoid common pitfalls when executing D-FMEA projects so that they can realize improved business performance

Exhibit 2. Here are simple suggestions to help manufacturing organizations avoid common pitfalls when executing D-FMEA projects so that they can realize improved business performance.

Use Simple Tools. Sophisticated technology does not a good FMEA make. A facilitator with a projector and a Microsoft Excel FMEA template prepared before FMEA sessions are all that may be required. The benefits of simplicity abound:

No one has to be a techno-wizard to manipulate and use the template.

An MS Excel file can be easily accessed from a laptop computer and be password-protected.

Money will be saved that would have gone to procuring expensive FMEA software that requires much configuration and leaves few expert users.

The organization is not sorely tempted to mold the FMEA processes and methodologies to fit the new software (a common case of the tail wagging the dog).

The user-friendly technology serves as a prop to get the team thinking and interacting.

Standardize the Scales. Standardized scales are key for objective risk assessment. It is important to keep in mind that the point of doing D-FMEAs is to help identify potential product failure modes early in the product development process, not to identify high RPN line items. Thus, using an objective SOD scoring mechanism is crucial [see FMEA-2 Potential Failure Mode and Effects Analysis (FMEA), 1995, Automotive Industry Action Group]. Unfortunately, FMEA work sessions often turn into bargaining arenas where the team tries to talk the facilitator into lowering SOD scores to the RPN below an arbitrary threshold. This happens in many organizations because RPNs above a certain high-water mark require action items, which translate into more work for members of the team. With such a system, work is assigned where no action is warranted and real risk is frequently overlooked. Instead, let reality dictate the true RPN with the help of an objective FMEA facilitator who uses a standard SOD scoring scale. And consider action items only after a realistic RPN report is generated.

All that are required to prevent such occurrences are a standardized scoring procedure and a hard-nosed FMEA facilitator who is reluctant to fold at the first sign of disagreement from the team members. Paying for professional advice that you're not getting, whether the facilitator is an employee or an outside consultant, and, at the same time, potentially jeopardizing product integrity is hardly a winning combination. To help implement a standardized scale in your organization use the D-FMEA Tips Sheet (Exhibit 2).

Reduce Risk, Not Numbers. Implementing a standardized scale leads to another important step toward improving business performance through improved FMEA projects: engaging your resources in risk reduction, not number reduction. RPNs are relative numbers—without a context, they are meaningless. I have seen many cases where management has chosen to target RPN values to use in the monitoring and scheduling of RPN reduction. While this may sound like an appropriate strategy and does create a nice metric for monitoring progress, it is not recommended. Each D-FMEA is independent of all others, so common targets that attempt to apply standard relative values to nonrelative FMEA projects are futile. For this reason, the team is very important. It must have the flexibility to apply rankings without having the built-in bias of a threshold value that must ultimately be reached. If one team applies the rankings honestly and another team just plays a numbers game by trying to keep RPNs below some threshold value, the honest team is penalized for using the FMEA tool correctly.

The FMEA Technique In Automotive Product Development

Failure Modes and Effects Analysis (FMEA) is a systemized group of activities intended to:

Recognize and evaluate the potential failure of a product or process and its effects

Identify actions that eliminate or reduce the chance of the potential failure mode from occurring

Rank-order potential design and process deficiencies

Document the process.

In its simplest terms, an FMEA is an analysis of risk. Although most commonly applied to design (D-FMEA) or process (P-FMEA), the tool has been used in concept, safety, production control, and logistics organizations, and for special machine and equipment (any situation where risk is present).

One of the most important factors in implementing the FMEA program is timeliness. The analysis must be performed as early in the product development cycle as possible. It is intended to be a predictability or proactive tool, not a reactive means of resolving known problems.

FMEAs are intended to utilize the cross-functional talents that are resident in all organizations. A team of knowledgeable individuals should be assembled—engineers (with expertise in design, manufacturing, assembly, quality), skilled trades, machine operators, and assemblers. As the product or process changes and matures, team membership will also change.

FMEAs are intended to be living documents. The D-FMEA should be initiated prior to finalization of the product design and updated as changes to the design occur. The P-FMEA should be initiated prior to procurement of tooling or special machine tools for production. The biggest drawback to successfully completing a FMEA is starting too late in the development cycle to impact the design or the process.

When preparing a FMEA, participants use a standard template asking:

What can go wrong? (Potential Failure Mode)

How serious is it? (Potential Effect of Failure/Severity)

Cause of the failure/frequency of occurrence (Potential Cause/Occurrence)

How can we detect or prevent it from occurring? (Current Controls/ Detection).

The outputs of effect of failure, cause, and current controls (severity, occurrence, and detection) are individually ranked on a scale from 1 to 10, using standard ranking guidelines developed by the Society of Automotive Engineers (SAE) as documented in the SAE J1739, Potential Failure Mode and Effects Analysis (Design, Process, Machinery) and the Automotive Industries Action Group (AIAG) as documented in the AIAG, Potential Failure Mode and Effects Analysis, 2nd Edition [February 1995]. The product of these three numbers is known as the Risk Priority Number (RPN). The RPN will be between 1 and 1,000. This is the measure of risk in the design or the process being analyzed. Ranked high to low, it allows the team to effectively assign recommended actions to improve the design or process, beginning with the highest-ranked concerns.

The intent of any recommended action is to reduce any one or all of the severity, occurrence, and/or detection rankings.

Keep in mind the word potential. Many organizations fail to benefit from FMEA because the analysis is done too late in the development cycle to properly implement recommended actions. Used effectively, FMEA can be the driving force behind process and design improvements.

If you are unsure if your RPN scoring scheme is undermining your PDP, here are some foolproof strategies to consider. Assign action items to be carried out as full projects to only the 10 highest RPN items—a noble strategy. Another possibility is to average the top 25 RPNs after the D-FMEA is complete and use that number as the target for RPN reduction. Reduce any RPN above that average until it is below the target. As you reduce RPNs, you will also reduce the target value, yielding a better picture of continuous improvement than any arbitrary value would. Both of these strategies allow the D-FMEA to be generated free of any number bias and remain independent from other D-FMEAs at the same time. In either case, you eliminate the unnecessary work of assigning action items, responsibility, and due dates to a bunch of FMEA line items that likely wouldn't get done anyway.

Learn from the FMEA Project. At the conclusion of the FMEA project, a thorough review process is required. An appropriate review session helps to:

Evaluate the validity of the results

Ensure that all action items are done satisfactorily

Tie up loose ends

Receive sponsor blessing by his or her sign-off

Archive lessons learned in a secure, easily accessible database to close the learning loop

Minimize reprocessing

Prevent failure modes from propagating through the PDP where cost to correct increases exponentially.

HEY, YOUR CUSTOMER HAS required that you do D-FMEAs (at your expense) throughout the PDP to keep his or her business. Instead of half-heartedly turning out RPNs and leaving dangling action items, take advantage of this opportunity by turning it into a business improvement tool and reaping the benefits of a truly upgraded PDP. By making a concerted effort to adopt and follow this straightforward set of 10 principles, you will improve your organization's business performance and get a leg-up on your competitors. images

Jim Bongiorno, PMP, is president of PlanTech Inc. (www.plantechinc.com), a full-service project management firm based in Farmington Hillls, Mich., USA. For more than 15 years, he has developed and implemented project management methodologies and applications to help clients improve their product quality improvement initiatives, and is known for incorporating “lean principles” into traditional project management to increase an organization's bottom line.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network May 2001

Advertisement

Advertisement

Related Content

Advertisement