Assumptions

• Your company designs and manufactures products or outsources these activities

• You have families of products, so that new products have design features in common with previous products and are sold to the same customer base

• Structured methods should be used continually to understand customer requirements and the reasons for them

• Whatever tool is used, it should capture the true customer requirements, prioritize them, and relate them to details of the product design. Reliability issues will be included in the responses. The same tools should be used on your competitors' products to give you a better understanding of your strengths and weaknesses in your customer's eyes.

• Customer feedback from Field Service and Customer Service organizations must be carefully captured in a well structured database. This is not as easy as it might appear. It must be coordinated with Failure Analysis. For example, you might get many complaints about hardware component A and even replace many of them, only to discover later that software or hardware component B was the culprit. The information system should tell the designers that hardware B was at fault or they will be working on the wrong problem in the next version of the product design.

• Engineers should have some face-to-face contact with customers. Thus, they will get to feel the customer's passion, adding a new dimension to the statistics of failure data.

• Customers will provide help in understanding what the design life of the product should be. Then, your company needs to be specific to everyone involved internally about the life you plan for your products. Developers should understand clearly that the warranty period almost never extends to what the customer feels should be the useful and trouble-free life of the product.

• A comprehensive and carefully designed product failure database is fundamental to trouble-free products.

• This database is the vital source of information to product developers about failures in similar previous designs. But, many other groups in your company also have needs for the data, often with slightly different requirements. These groups include: field service, customer service, warranty, accounting, procurement and inventory control, suppliers, and manufacturing. The database should be carefully crafted to serve everyone, and it should be a single, company-wide database to avoid expensive duplication and arguments about whose data are correct.

• For the design engineers, the data base should include for each failure:
• Part that failed
• Failure mode
• Root cause of failure
• Period in the life of the product of the failure (infant, useful, end)
• Severity to customer
• Statistical summaries of the data above

• Engineers need to know in what period of life the part failed. Failures during the infant period may indicate a manufacturing defect rather than a reliability issue. Random failures during the useful life usually have other root causes, often correctable by better design. Failures at end of life may indicate wear and merit attention if they occur before the planned lifetime has passed. So, the failure database must collect and maintain data to indicate when the failure occurred.

• Specialists often perform Failure Analysis because the field service people have a mission to satisfy the customer, not to analyze why the failure occurred. Failure Analysis strives to get to the root cause of the failure. Failure Analysis Reports should be well designed and integrated with the failure database. Design engineers should have a close working relationship with technicians performing failure analysis.

• Knowledge about field failures is more valuable than knowledge from lab tests. Why?
  • The field failures occurred under true conditions in the hands of the customers.
  • The number of products being "tested" by customers is very large, giving more statistically valid results.

• But, field failure data suffer from some problems. The data collection and failure analysis system must strive to cope with these shortcomings.
  • As mentioned above, often parts are reported defective initially, then later found to be OK (no fault found).
  • Parts cannot be economically designed to stand extreme customer abuse, and customers do not usually confess to such abuse.
  • Service people are charged with getting the customer's product fixed, not with isolating the problem part accurately or with establishing the root cause.

• Product Developers must have primary responsibility for reliability. It must be "designed in." Others are charged with ensuring that the product always goes out the door as designed, that all parts and assemblies are bought and built to specification with essentially no variability in processes. For example, if an electronic component in the previous product overheated and failed, only the designer can provide for more cooling or specify a different component. If a part is failing from wear, it is the designer who must change the material, the heat treatment, or the lubrication.

• Of course, the designer must have reasonably accurate summaries of communications with the customers and from the product failure database and the failure analysis effort.

• Then, when a design team is assembled for a new product, there should be a formal process for setting reliability goals for it. Using all the information available, an improved overall reliability goal should be set, and discussion and negotiation should set formal goals for improvements for the various subsystems and components of the product. Accurate failure data will permit the design engineers to concentrate on the worst offending components; 80% of the problems are likely caused by 20% of the components. The goals become part of the written internal contract for this product.

• Next, the engineers decide how to achieve the improved reliability goals. How? This is what engineers do for a living. Customer involvement, brainstorming, simplification, modular design, reuse of reliable subassemblies, design failure mode and effects analysis (FMEA), reliability predictions, reliability growth models, robust design, change of materials, redundancy, sophisticated CAD systems, learning from a product failure database, better collaboration with suppliers, more thorough testing, better collaboration with their peers working on other parts of the design, and concurrent engineering with manufacturing engineers. The product design team really must take the leadership role with procurement, suppliers, and manufacturing to improve reliability.

• There needs to be a formal methodology for the entire product development process. (See our other website at www.lean-product-development.com.)
• It has several phases, each carefully defined with approvals required to proceed to the next phase.
• The reliability steps are written into the product development process at the appropriate points including the use of specified tools, tests, prototyping, piloting, etc.
• A rapid, but methodical design process, not a hurried, panicked, or sloppy one, will improve reliability in designs.
• It is important to control projects entering the design process. Too many projects will result in poor design, and trouble-prone products will be one of the results. Marketing and product design leaders must agree to be realistic about the amount of work that can be done well.
• Similarly, mid-course corrections - product requirement changes by marketing during design - often compromise the quality of the design.
• Successful companies use an internal contract to define the project at the beginning. Elements of the contract include product specifications, cost, life, performance, time to market, etc. If someone wants to change a portion of the contract, everything is open to renegotiation.

• Project management of product development projects is critical. The project must follow the standard development process, meet the dates, and meet the requirements of the contract. The project manager must interface effectively with all the appropriate groups outside the design team, including manufacturing, procurement, quality assurance, reliability engineering, etc.