Management View of Reliability During Product Development

Based on the book Reliability Engineering Insights

I found, while working at HP as a reliability engineer, that most managers of new products had little to no understanding of reliability concepts. They usually had the basic concept that reliability engineers should be brought into the project as the design was being finalized but had no clue what they would work on.

Some of the important reliability concepts missing in product manager’s understanding of reliability were:

Reliability Metrics

A basic term commonly used by management was WFR (Warranty Failure Rate). In the manager’s mind, WFR was the total number of failures while in warranty (since day 1), divided by the total production (since day 1). This calculation did not account for time delayed for inventory buildup, shipping and building time on a product by the customer use. But production time started immediately. Therefore, a delay in creating a significant failure would occur keeping the WFR numerator at a low level while the denominator continues to grow. By the time failures starts to grow, the design team had been moved to other projects and all the insights into possible causes were hard to re-assemble.

Reliability Testing

Samples of products used in reliability testing during the development phases were usually obtained from early production facilities or proto-production sites. These samples were not typically what the customer would see when purchasing a product after introduction. Reasons for tests not representing real life situations could be:

• Early production technicians and operators were highly skilled and trained by engineers. High volume production training was done by local specialist, manuals, and certification tests.
• Early production volume was from one site but the long term high volume production usually was from multiple sites (with different: operators, equipment, materials, and culture).
• Early transportation of product from production for product testing was quick and direct due to local sites, but long term production had a longer lead time due to worldwide shipping. This caused different stresses on the product and confused the factors contributing to failures.
• Storage of product was at multiple sites with different environments.
• Customer use models were different which influence whether a failure mode was activated.

All these situations discussed above were encountered during the development of products I worked on at HP.

Tracking Failures

Software developers typically use defect tracking during development. The SW team addressed each failure before introduction of the project. But in Hardware development, the design engineers fixed some problems without recording them in the early stages of invention. Only when the product was being finalized did failures become visible to management. Since reliability engineering typically was done on samples from this final stage of development, weaknesses in the design may not be understood and therefore not included in the testing strategy.

Because of these limitations in management awareness and understanding of reliability, I found that the most important reliability related tools during product development were; HALT, FMEA, Defect Tracking, and Functional Architecture mapping. These tools allowed the reliability engineer to minimize the influences from areas discussed above. It was important to concentrate on a few tools so that you can have the time to deep dive into each of weakness found.

Note: This blog discusses reliability aspects of developing a product. They can be found in more detail in my book Reliability Engineering Insights by Arthur Ray Hart (found at accendoreliability.com, sub-heading ‘Resources/Authors’)