Design Lifecycle and Problem Solving

Locked lesson.

Upgrade

About this lesson

The FMEA methodology provides insight for product managers and operations managers at all stages of the product lifecycle. They are a key source of information for problem solving and process improvement.

Quick reference

Design Lifecycle and Problem Solving

FMEA analysis should be conducted during the design lifecycle for new or updated product and services.  In addition, the FMEA can be used to guide elements of the problem solving process.

When to use

Whenever a product or process is being designed or updated, an FMEA should be created or updated.  Since the FMEA is a technical risk management analysis, it is used whenever technical changes are implemented in products or processes.  In addition, when analysing failures, the FMEA can provide insight into likely causes for observed failures.

Instructions

FMEAs are a technical risk assessment technique with both strategic and tactical implications.  They are used in the product development lifecycle to identify and mitigate risks during the detailed design stages of the development.  Prior to detailed design, there is normally not enough information to adequately asses the risk of component or process step failure.  However, after detailed design is complete there is often a great deal of organizational inertia preventing design changes that are not absolutely mandatory.  Therefore, the best time to conduct the FMEA analysis, both Design FMEA and Process FMEA, is during detailed design.  At that point it is relatively easy to accommodate risk mitigation design changes.

As stated in other lessons, the Design FMEA is focused on reducing the risk that the product fails to meet the customer’s expectations at the time of use.  The Process FMEA is focused on reducing the risk that the product or service is improperly processed, resulting in scrap, rework, or the delivery of a defective product or service to the customer.

FMEA lifecyle uses

When considering the entire product lifecycle, the FMEA has application at many points.

  • During design and development, the FMEA will identify technical risks or design errors and it can be used to evaluate the efficacy of proposed risk resolution plans.
  • During the start-up and early operation, the FMEA can be used to develop training plans to highlight to operators critical characteristics and control plan elements.
  • When a system or process is transferred to a new site or operating location, the FMEA is a tool to explain why characteristics are critical and to review any requested control plan or tolerance changes.
  • When a product or process is changed, the FMEA is updated to determine if new failure modes are being introduced.
  • During the problem-solving process for existing products or processes, the FMEA can be used to trace observed failures back to likely causes, accelerating the creation of a solution.
  • The FMEA is a means of capturing critical technical information that was known to the designers of a product, service, or process and convey that information to those who inherit responsibility for the product, service, or process.

Living document

FMEAs are living documents.  They should be reviewed and updated whenever a design or process change is made.  Those changes may introduce new failure modes.  By the same token, they may eliminate or reduce other failure modes and allow the product or process to be simplified.  In these cases, all three scores – severity, occurrence, and detection – could be changed.  In addition, when the customer begins to use the product or service in a different application than was used originally, the severity score is likely to change.  New processing equipment or changes to the process control plan, including software changes that impact product self-test or diagnostics, will typically impact occurrence and detection scores.  If over time the product sees a change in the level of customer complaints or returns, the field use data can be utilized to update the occurrence scores.

Hints & tips

  • Put the FMEAs under revision control and treat them as you would any other design documentation.
  • FMEAs should be reviewed as part of a product or service design review prior to design freeze.  Too often organizations do these well after design freeze as part of a documentation package required for submittal to a customer or regulator.  At that point it is difficult to apply appropriate risk mitigation actions.
  • Whenever a product or process change occurs, be sure to review the FMEAs to see what impact it has, if any.  This includes relocating a process or using a product for a new application.
Login to download
  • 00:04 Hi, I'm Ray Sheen.
  • 00:06 I'd like to wrap up this intro section providing context for FMEAs with
  • 00:10 a discussion of the design lifecycle and the problem solving process.
  • 00:16 Let's start with one of the more common visual representations of the design of
  • 00:21 a complex product or service system.
  • 00:23 The process is represented with a v-shaped diagram.
  • 00:26 The left side of the v is the flow-down of goals and requirements.
  • 00:30 The right side of the v is a roll-up of the design documentation,
  • 00:34 and other design verification activities such as testing.
  • 00:37 So we start at the top left point of the v with the voice of the customer.
  • 00:41 This is the customer request or expectations for performance and
  • 00:44 safety of the system.
  • 00:46 This is translated and flowed down into system requirements.
  • 00:49 If it is a simple system, there is one set of requirements.
  • 00:52 A complex system may have a different set of requirements for
  • 00:56 each of the subsystems.
  • 00:57 These are separate, but must be harmonized so
  • 01:00 that the system works together to meet the customer expectations.
  • 01:04 These are then flowed down to the component or subsystem requirements.
  • 01:07 These will be the performance requirements used to design or
  • 01:10 source the components and subsystems for the products or services.
  • 01:14 Typically today, an additional set of requirements are then added to
  • 01:17 the performance requirements that are focused on the operational or
  • 01:20 process requirements.
  • 01:22 These would include things like quality requirements, reliability requirements,
  • 01:26 maintainability requirements, and shipping or logistics requirements.
  • 01:30 At this point, the design or sourcing activity takes place.
  • 01:34 As the product design is being completed,
  • 01:35 a control plan that highlights the key inspection and test points should be done.
  • 01:39 This should ensure that the process requirements are met.
  • 01:43 With that in place, the final drawings and specifications with appropriate tolerances
  • 01:46 and critical characteristics can be finalized.
  • 01:49 These should satisfy the component and system requirements.
  • 01:52 In fact, often there is testing to demonstrate that they do.
  • 01:56 Now everything can be assembled into a final system for system testing.
  • 02:00 In addition, there is a pilot run to evaluate the process capability.
  • 02:04 The test results and
  • 02:05 process capability studies will determine if the system requirements are being met.
  • 02:10 Ultimately the product is released to the market, and customer response is monitored
  • 02:14 to determine if the customer satisfaction is as expected for
  • 02:17 this product or service.
  • 02:19 Within the framework, both the Design FMEA and
  • 02:22 the Process FMEA are done at the time of detailed design work.
  • 02:25 However, the Design FMEA will focus at the customer use level, and
  • 02:29 the Process FMEA will focus at the process performance level.
  • 02:33 Let's consider how the use of FMEAs
  • 02:36 can reduce errors during the product lifecycle.
  • 02:39 As we saw on the previous slide, it can help during the development process
  • 02:43 to identify flaws in product performance and process development.
  • 02:47 FMEAs will also be of assistance during start-up and early operations.
  • 02:51 The FMEAs identify the critical components and the operational control plan features.
  • 02:55 If the production started at one facility and is then moved or expanded to another
  • 02:59 facility, the FMEA is an excellent tool for explaining why certain
  • 03:03 features are critical, and why tolerances have been set at certain levels.
  • 03:07 At any point in time during the the product lifecycle, a problem can occur.
  • 03:11 The FMEA can help the problem solving team to understand the likely causes
  • 03:16 by comparing the observed problems with those described in the FMEA.
  • 03:19 This points them to the root cause or causes.
  • 03:22 Finally, at various times during the lifecycle,
  • 03:25 the organization may want to improve or modify the product or service.
  • 03:29 The FMEA is a means by which the original developers can convey what design
  • 03:33 attributes are important and why, to those who follow them and do the new analysis.
  • 03:39 Which brings us to a key attribute of an FMEA,
  • 03:42 one that must be implemented if the organization intends to use FMEAs
  • 03:46 when problem solving during the product lifecycle.
  • 03:48 That is, that the FMEA document is maintained as a living document.
  • 03:53 To be useful for analysis, the FMEA must reflect the product or process
  • 03:57 as it currently is, not how it used to be at some time in the distant past.
  • 04:02 That means it must be a living document.
  • 04:05 That means that the product or process design characteristics are current, and
  • 04:09 the probability scores reflect the reality of the current process.
  • 04:13 If new components or systems are added to the product or
  • 04:15 process, then the failure modes of those components or systems need to be included.
  • 04:21 For instance, if a manual manufacturing process is automated, the Process FMEA
  • 04:25 must be updated to reflect the failures and the performance of the automation.
  • 04:30 And remove the failures and performance modes of the manual steps.
  • 04:34 The new failures for the equipment will have its own severity occurrence and
  • 04:37 detection scores.
  • 04:39 Probability of occurrence should be updated with real failure rate experience
  • 04:43 from the field.
  • 04:45 Changes to the process equipment means changes to the failures and
  • 04:48 evaluations, particularly those associated with occurrence and detection.
  • 04:53 New product performance software will enhance monitoring capabilities,
  • 04:57 or new control plan systems such as statistical process control
  • 05:02 will change both occurrence and detection scores.
  • 05:05 And new applications for
  • 05:06 an existing product can dramatically change a severity score.
  • 05:10 FMEAs should not be a static analysis done just to check a box.
  • 05:15 They're a valuable element of the development process and
  • 05:18 the overall product lifecycle, so they should be maintained as living documents.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course