Speaking Of Reliability: Friends Discussing Reliability Engineering Topics | Warranty | Plant Maintenance

How reliable does a surgical robot need to be? Chris and Mojan use that question to explore a much broader reliability engineering problem. Patients care about safe outcomes and what happens when the robot fails; hospitals also care about availability, utilization, and downtime. The conversation then moves upstream to where many expensive failures actually begin: poorly defined hardware-software interfaces and requirements delivered too late. They discuss why cutting early reliability work often makes development slower, not faster, and how AI-enhanced FMEA can expose difficult failure scenarios early enough for engineers to prevent them rather than discover them during validation.

Measuring reliability should help engineers make better decisions—not simply generate an impressive MTBF or another test report. Chris and Fred explore how misleading metrics, late reliability demonstrations, and ever-expanding test programs can create the appearance of reliability engineering without actually making products more reliable. One organization accumulated 47 tests simply by adding another whenever a field problem occurred. The result was not better engineering, but designers learning to design for the tests. The episode argues for something more useful: measure what helps engineers prevent failures, make better design decisions, reduce development cost, and get reliable products to market faster.

Is it Reliable? Abstract When a customer asks “Is it reliable?” they’re not asking about MTBF or lab test results. They’re asking: “Will this do what I bought it for?” Join Fred and Mojan as they explore why product management is the most underrated function in reliability engineering. From HP’s obsessive attention to printer sound […]

Measuring Reliability Abstract “It’s impossible to measure.” “It’s too vague.” If you’ve heard these objections, you’re facing a fundamental misunderstanding about measurement. Join Fred and Mojan as they explore Douglas Hubbard’s principle that everything can be measured—the real question is whether the cost of measurement is worth the reduction in uncertainty. They discuss how to […]

Reliability-Centered Maintenance should do more than produce a list of preventive maintenance tasks. Chris and Carl examine how maintenance and supportability FMEAs feed RCM decision logic, and why maintenance thinking must begin before design is locked down. They challenge two particularly costly habits: treating initial maintenance intervals as permanent answers and assuming that more preventive maintenance always improves reliability. Without good failure data, servicing intervals may begin as educated guesses—and unnecessary intervention can itself cause failures. Effective RCM therefore needs feedback from field data, failure analysis, maintainability, and design to continually improve the maintenance strategy.

Is reliability engineering becoming less attractive as companies cut costs, demand faster development, and turn increasingly to AI? This episode argues that the opposite may be true—but only for engineers willing to move beyond comfortable tools and established routines. Chris and Enrico examine why cutting reliability capability can actually increase cost and delay development, why late-stage testing cannot substitute for early prevention, and why technical expertise must translate into business value. They also tackle AI: not as a replacement for reliability knowledge, but as a powerful tool for engineers who already know enough to question, challenge, and improve its output.

Return Logistics and Failures Abstract Kirk and Fred discuss the challenge of getting field failures back to the engineers who can do detailed failure analysis. Key Points Join Kirk and Fred as they discuss how difficult it is to get failed products back and how many returns aren’t actually failures but still end up in […]

Weibull is Useful Abstract Kirk and Fred discuss the long-running question of Weibull analysis and whether it’s useful. Key Points Join Kirk and Fred as they discuss why Weibull is useful after failures occur in the field. Topics include: Weibull plots are used to determine whether a failure is an infant mortality failure, a random […]

GM knew its ignition switch failed an internal torque specification before the affected vehicles entered production. Yet the switch was approved, field problems followed, and an improvement costing less than $1 per vehicle was later rejected. Eventually, approximately 2.6 million vehicles were recalled, with enormous financial and human consequences. Chris uses the GM ignition switch failure to make a broader reliability engineering point: finding problems is not enough. Engineers and leaders must act while changes are still inexpensive. Earlier changes the economics—and waiting until testing or customers expose a failure can turn a simple engineering decision into an extraordinarily expensive one.

What does reliability mean when the customer thinks your product has failed even though it still technically works? And how should engineers measure reliability when failures involve software defects or patient safety rather than conventional hardware wear-out? Chris and Enrico continue their examination of reliability metrics by looking at customer ratings, brand reputation, medical devices, and software. They discuss why customer expectations matter, why medical reliability and safety overlap, and why software cannot simply be forced into traditional hardware reliability models. The discussion also highlights a growing systems-engineering problem: reliable products increasingly depend on hardware and software teams working together from the beginning.