#153 – PROJECT SPECIFIC RELIABILITY PLANS – FRED SCHENKELBERG

ABC FredA project-specific reliability plan is a guide or roadmap for intended action. It is also a collection of specific tasks and milestones, enhanced with rationale to allow the entire team to fully understand its role in accomplishing the reliability objectives.

The plan is a way to achieve the desired business objectives. This means that the product must be reliable enough to meet customer expectations, minimize warranty expenses, and garner market acceptance. The plan is just a plan. It is the accomplishment of the tasks, the decision that improve the design, the signals monitored that stabilize the supply chain and assembly process that all make the difference.

A plan without action is not worth the effort.

Key Elements of Any Reliability Plan

The overriding key to a successful reliability plan is to understand that no two plans are the same. Using the plan from the previous project is destined to failure. The plan must be crafted given the current situation, information, and risks.

Although each plan should be tailored for the specific project each also should address the following key elements:

  • goals and objectives,
  • risks and challenges, and
  • predictions and estimates.

Keep in mind that a reliability plan is not a test plan alone. It may or may not include testing. Yet it does require a goal, risks, and measurements for comparison to the goal.

Goals and Objectives

How reliable does your product need to be to be considered successful? How many should last for how long under what conditions performing which functions? The answers to these questions should be as specific as possible.

The reliability goals should be connected to your overall product platform, business financials, and brand and be as explicit as possible. Later, when evaluating the possibility of releasing a product that has just a 1% higher failure rate than desired, you will have an ability to understand the magnitude of the potential impact.

The goals should be connected to the elements within the product and across the product’s lifecycle. You should apportion the goals to the major elements and key components of the product and communicate the specifics to your team and suppliers.

Also, you should evaluate the changing nature of the environment around elements within your product. For example, the temperature is not always the outdoor ambient one.

It is essential to understand the cost of failure, the cost of warranty per unit shipped, the cost of a lost customer, or the relevant impact of a failure. This is important for balancing cost, time to market, and feature set decisions with reliability performance.

Risks and Challenges

Many teams naturally consider what could go wrong and what could fail during the design process. The reliability plan should help the team discover, reveal, coordinate, and prioritize this list of risks.

Risks and challenges may take a few different forms. There are factors that are known to be a problem but others are unknown. For some elements of a system we know from previous product performance, internal testing, or engineering judgment that this element of the design does not meet our reliability goals. Although we do not know how to resolve that issue, it’s a risk.

Sometimes we have a new material, process, invention, or application and that provides a realm of uncertainty. We do not know how the product will perform. We probably have some ideas and most likely a few questions. The plan should include strategies and methods to reduce the uncertainty.

Finally, there is the possibility that no one on the team knows about specific risks. These are unknown unknowns! Exploring the performance of early prototypes and discovery evaluations enable the team to reveal weaknesses or faults.

The team’s overall challenge is to identify all the relevant risks, prioritize them, and resolve as many risks to reliability as necessary. Running a few simple tests that result in ‘passing’ outcomes generally provides little to no information. Instead, you should look to find margins, discover faults, and reveal weaknesses deliberately.

If the team already has a long list of issues to resolve, it is better to work on those and ensure that no new risks create problems. The amount of risk discovery necessary is inversely proportion to how well the team understands the field reliability performance.

Predictions and Estimates

A goal without a means to measure progress against the goal is pointless. Likewise, measuring reliability without a goal for comparison is futile.

There are a wide range of reliability engineering techniques to draw from to evaluate the state of the current design. From early predictions based on little more than vague industry-collated data, to detailed failure-mechanism-specific accelerated life testing, the aim is to provide feedback to the team regularly. The early estimates are ‘rough and uncertain.’ Later in the program the estimate and testing results may provide specific, detailed models that accurately portray field reliability performance.

Based on the goals and risks, the elements of the plan should provide regular and increasingly accurate measures of the expected reliability performance. You should connect each model, prediction, analysis, and life test to a specific reliability goal for comparison. The compilation of the estimates should then be linked to key decision points in the program.

This is just a rough outline for the development of a tailored reliability plan for your project. Whatever plan you develop should make a difference and achieve the stated goals.

Bio:

Fred Schenkelberg is an experienced reliability engineering and management consultant with his firm FMS Reliability. His passion is working with teams to create cost-effective reliability programs that solve problems, create durable and reliable products, increase customer satisfaction, and reduce warranty costs. If you enjoyed this articles consider subscribing to the ongoing series at Accendo Reliability.

 

Leave a Reply

Your email address will not be published.