Failure Happens – It Is What Happens Next That Matters

One of the benefits of reliability engineering is failure happens.

Nothing made, manufactured, or assembled will not fail at some point. It is our desire to have items last long enough that keeps us working. Since failures happen, our work includes dealing with the failure.

Not My Fault

Years ago while preparing samples for life testing at my bench, I heard an ‘eep’ or a startled sound from a fellow engineer. It was quickly followed by an electrical pop noise and a plum of smoke.

Something on the circuit board she was exploring had failed. With a pop and smoke. She didn’t move.

At this point, my initial amused response turned to concern for her safety. She was fine, just startled as the failure was unexpected. She quickly claimed it wasn’t her fault.

It was her design, she selected and assembled the parts, and she was testing the circuit. Yet, it wasn’t her fault. She did not expect a failure to occur (a blown capacitor – which we later discovered was exposed to far too much voltage), thus it was not her fault.

We hear similar responses from suppliers of components. It must have been something in your design or environment that caused the failure, as the failure described shouldn’t happen. It’s not expected.

Well, guess what, it did happen. Now let’s sort out what happened and not immediate assign blame for who’s fault it is.

The ‘not my fault’ response so a failure is not helpful. Failures are sometimes the result of a simple error and quickly remedied. Other are complex and difficult to unravel. The quicker we focus on solving the mystery of the cause of the failure, the quicker we can move on to making improvements.

Warranty

With possibly too many ‘not my fault’ responses, laws now enjoin the manufacture of products to stand behind their product. If a failure occurs, sometimes within specific conditions, the customer may ask for a remedy from the supplier.

If failures did not happen there would be no such thing as a warranty.

A warranty is actually a legal obligation, yet has turned into a marketing tool. A long warranty implies the product is reliable and by offering a long warranty the manufacturer is stating they are shifting the risk of failure to themselves.

A repair or replacement is generally not adequate recompense for a failure, yet it provides some restitution. In most cases, it only provides peace of mind, if the item doesn’t fail.

The warranty business has become an industry in of itself. Selling, servicing, and honoring warranties is something that others can deal with outside your organization. The downside is the lack of feedback about failure details so you can affect improvements. A manufacturer shouldn’t hide behind their warranty policy, nor ignore the warranty claim details. It is one-way a customer can voice their expectations concerning product reliability. You should listen.

Repair services

My favorite outsourced repair service story involved a misguided payment structure.

If you pay a repairman based on the value of the components replaced, they will likely always replace the most expensive components. If the repair is accomplished by resetting a loose connector, nothing is replaced, and the repairman is not compensated for the diagnostic work and effective repair. If he instead immediately replaced the main circuit board, and in the process reseating most of the connectors, the repair is fast, effective, and he is handsomely rewarded.

See the problem?

When a failure occurs, it may be natural to offer a repair service as the remedy. It should be quick (not a two-week wait as with my local cable company to restoring a fallen line), and efficient for all parties involved. For the owner of the equipment, we want the functionality restored as quickly as possible and cost effectively as possible. For the manufacture of the equipment, we want cost effectiveness, plus the knowledge concerning the failure.

Does your repair service provide for the needs of both parties as well as the repair technician?

Fail safe

Sometimes when a failure occurs nothing happens. We might not even notice the failure occurs. Other times the product simply goes ‘cold’ or a function is lost. Nothing adverse, no pop or smoke, occurs.

We call this failing safe. It’s more complicated than my simple explanation, yet it is the desired repose to a failure. The product itself should not create more damage, cause harm, place someone in peril. It should fail safely and preferably quietly.

If the ignition falls from the ignition switch, which may be considered a failure to retain the key within the switch, the driver should not lose control of the vehicle. This is in part a safety feature, yet is also a common expectation that the failure of a system should not create other problems.

Failure containment is related.

How does your product fail? Safely?

Maintenance

For some failures, such as the degradation of lubricants, we perform maintenance. When the brake pads or tire tread wears to marginally safe level we replace the brake pad or tire. If we can anticipate the failure pattern we perform preventive maintenance.

Creating a maintainable piece of equipment is one response to failures. It allows creating complex equipment with failure prone elements. Through maintenance, we are able to restore the system to operation or avoid unexpected downtime. If failures didn’t occur, we wouldn’t need maintenance.

We have some control over the nature of the maintenance activities. For some types of failures, we can only execute corrective maintenance. For others, we can use preventative methods. The idea is to anticipate and avoid the widest range of failures through effective maintenance practices, that remains cost effective.

Adding maintenance practices in response to system failures is not the duty of the owner of the equipment. It is a design function to anticipate the system failures that may occur and devise the appropriate maintenance plan to thwart unwanted failures from occurring. The two parties actually have to work together to make this work well.

Expectations

When I buy a product, I know that some proportion of products like the one I just purchased will failure prematurely. I just do not want or desire mine to fail. My expectation is the one I select at the store is a good one. It won’t let me down, stranded, or injured. That is my expectation.

When a failure does occur and I value the functionality the product provides I will want to restore the unit via repair or replacement, sometimes via a service contract or warranty or repair center. To a large degree, my expectation is after a failure all will go well.

As the manufacture of products, when a failure occurs, your expectations may include learning from the failure to make improvements. Or it should.

We know we cannot anticipant nor avoid every failure that may occur. The expectation on both sides is to make robust and dependable products that provide value for all involved. When that approach fails, we fail.

Failure Happens

In response to a failure, it’s how the product, customer, and manufacture responds that matters. A simple failure can turn into a disaster for all involved. Or the failure can provide insights leading to breakthrough innovations and new opportunities.

It’s how we respond that matters.

How do you respond to failures?

The Magic Math of Meeting MTBF Requirements

Recently heard from a reader of NoMTBF. She wondered about a supplier’s argument that they meet the reliability or MTBF requirements. She was right to wonder.

Estimating reliability performance a new design is difficult.

There are good and better practice to justify claims about future reliability performance. Likewise, there are just plain poor approaches, too. Plus there are approaches that should never be used.

The Vendor Calculation to Support Claim They Meet Reliability Objective

Let’s say we contract with a vendor to create a navigation system for our vehicle. The specification includes functional requirements. Also it includes form factor and a long list of other requirements. It also clearly states the reliability specification. Let’s say the unit should last with 95% probability over 10 years of use within our vehicle. We provide environmental and function requirements in detail.

The vendor first converts the 95% probability of success over 10 years into MTBF. Claiming they are ‘more familiar’ with MTBF. The ignore the requirements for probability of first month of operation success. Likewise they ignore the 5 year targeted reliability, or as they would convert, MTBF requirements.

[Note: if you were tempted to calculate the equivalent MTBF, please don’t. It’s not useful, nor relevant, and a poor practice. Suffice it to say it would be a large and meaningless number]

RED FLAG By converting the requirement into MTBF it suggests they may be making simplifying assumptions. This may permit easier use of estimation, modeling, and testing approaches.

The Vendor’s Approach to ‘Prove’ The Meet the MTBF Requirement

The vendor reported they met the reliability requirement using the following logic:

Of the 1,000 (more actually) components we selected 6 at random for accelerated life testing. We estimated the lower 60% confidence of the probability of surviving 10 years given the ALT results. Then converted the ALT results to MTBF for the part.

We then added the Mil Hdbk 217 failure rate estimate to the ALT result for each of the 6 parts.

RED FLAG This one has me wondering the rationale for adding failure rates of an ALT and a parts count prediction. It would make the failure rate higher. Maybe it was a means to add a bit of margin to cover the uncertainty? I’m not sure, do you have any idea why someone would do this? Are they assuming the ALT did not actually measure anything relevant or any specific failure mechanisms, or they used a benign stress? ALT details were not provided.

The Approach Gets Weird Here

Then we use a 217 parts count prediction along with the modified 6 component failure rates to estimate the system failure rate, and with a simple inversion estimated the MTBF. They then claimed the system design will meet the field reliability performance requirements.

RED FLAG Mil HDBK 217 F in section 3.3 states

Hence, a reliability prediction should never be assumed to represent the expected field reliability …

If you are going to use a standard, any standard, one should read it. Read to  understand when and why it is useful or not useful.

What Should the Vendor Have Done Instead?

There are a lot of ways to create a new design and meet reliability requirements.

• The build, test, fix approach or reliability growth approach works well in many circumstances.
• Using similar actually fielded systems failure data. It may provide a reasonable bound for an estimate of a new system. It may also limit the focus on the accelerated testing to only the novel or new or high risk areas of the new design — given much of the design is (or may be) similar to past products.
• Using a simple reliability block diagram or fault tree analysis model to assembly the estimates, test results, engineering stress/strength analysis (all better estimation tools then parts count, in my opinion) and calculate a system reliability estimate.
• Using a risk of failure approach with FMEA and HALT to identify the likely failure mechanisms then characterize those mechanisms to determine their time to failure distributions. If there is one or a few dominant failure mechanisms, that work would provide a reasonable estimate of the system reliability.

In all cases focus on failure mechanisms and how the time to failure distribution changes given changes in stress / environment / use conditions. Monte Carlo may provide a suitable means to analysis a great mixture of data to determine an estimate. Use reliability, probability of success over a duration.

In short, do the work to understand the design, it’s weaknesses, the time to failure behavior under different use/condition scenarios, and make justifiable assumptions only when necessary.

Summary

We engage vendors to supply custom subsystems given their expertise and ability to deliver the units we need for our vehicle. We expect them to justify they meet reliability requirements in a rationale and defendable manner. While we do not want to dictate the approach tot he design or the estimate of reliability performance, we certainly have to judge the acceptability of the claims they meet the requirements.

What do you report when a customer asks if your product will meet the reliability requirements? Add to the list of possible approaches in the comments section below.

Related

How to Calculate MTBF

Questions to ask a vendor

MTBF: According to a Component Supplier

Why Do Reliability Testing

Reliability testing is expensive. The results are often not conclusive.

Yet we spend billions on environmental, accelerated, growth, step stress and other types of reliability tests. We bake, shake, rattle and roll prototypes and production units alike. We examine the collected data in hopes of glimpsing the future. [Read more…]

Considerations When You Calculate MTBF

It is deceptively easy to calculate MTBF given a count of failure and an estimate of operating hours. Just tally up the total hours the various systems operate and divide by the number of failures. Easy.

This simple calculation is the unbiased estimator for the inverse of the parameter lambda for the exponential distribution, or directly to estimate theta (MTBF). We use theta to represent the 1 / lambda.

What could go wrong with such a simple calculation?

What is a failure?

Let’s start with what we count or do not count as a failure. This directly changes the resulting MTBF value. If we only count confirmed hardware failures, and do not count intermittent or unreproducible or software failures, are we under counting what the customer experiences as a failure?

Over what duration do we count the failures? Should we focus only on the first month of operation, the first year, the warranty or service contract period or the entire operating life of the system? How do you calculate MTBF?

Some organizations only count failures they expect to occur. The unexpected ones are ‘special’ causes and require further study before counting as failure officially.

Another organization only counted failures that completely shut down the system. A partial loss of functionality, a degradation of capability or the failure of a redundant element all did not count a system failure.

In my opinion if the customer calls it a failure, it’s a failure. If a failure, by any definition, costs your organization time and money to address, acknowledge, resolve or repair, it’s a failure.

What is operating time?

This one is tricky. If the system does include the appropriate sensors and tracking mechanisms (hour meter) and a way to gather that operating time of units both failed and still operating, then we have a pretty good way to track total operating hours. Some situations and systems make this easy.

Most do not.

Let’s say we ship 100 systems a month for 10 months. At the end of ten months the first shipments have accumulated 10 months of operating time. IF….

… They are all placed into service immediately

… They are all operated full time for the full 10 months

… They are have each failure reported including down time

In general, we do have to make a few assumptions to determine the operating time for shipped systems. We tend to be conservative and err on the side that would make the MTBF value a little smaller than if we had the full set of carefully tracked data. Or do we?

• Some organization count from date/time of shipment ignoring shipping and installation time.
• Some organization assume all systems are installed and operated 24/7.
• Some organization assume no news is good news and the systems with no information are still operating.

And a few organization assume systems run indefinitely, even systems 20 years old, unless notified that it is decommissioned, assume it is still running full tilt. i.e. No retirement or replacement policy.

How about when you calculate MTBF?

By convention when there are no failures we assume in the next instant there will be one failure. This avoid dividing by zero which causes fits for calculators and spreadsheets and mathematicians.

Another issue is how often are the calculations made? Do we gather data hourly, daily, weekly, monthly, annually? Some use a rolling set of data, for example only units shipped in the last year count for both operating time and failures. This result will ignore or discount the longer term wear out failures as the bulk of the units are young.

Some organization do the calculations weekly in order to detect trends. If there are trends you probably should not be using MTBF…. If it’s changing, if there are early life or wear out failure mechanisms, you should not be using MTBF.

Even though you can calculate MTBF easily, the complexities of getting it right still do not provide a useful metric. Instead focus on getting better data including time to failure information so you can explore and report the data with other tools and methods. Treat the data appropriately and make better decisions

Sure, better data will improve the ability to calculate the MTBF value, if you’d like to be like some organizations, that is fine.

How have you seen MTBF calculated poorly? Share your thoughts and stories in the comments below.

Related:

How to calculate MTTF

Perils of using MTBF

Fred talks about the NoMTBF blog and movement

Did you know I was interviewed for the Dare to Know podcast? The interview was fun, check it out here.

The Dare to Know podcast Interview

Tim Rodgers interviews Fred Schenkelberg concerning his blog, No MTBF and his mission to eradicate the common mis-use of MTBF.

Fred Schenkelberg is a reliability engineering and management consultant at FMS Reliability. He’s a lecturer at the University of Maryland, and he’s been an active contributor to both the IEEE and the ASQ Reliability Divisions.

Fred re-established Hewlett Packard’s corporate reliability program in the late 1990s, and also worked as a reliability consultant at Microsoft and a manufacturing engineer at Raychem.

In this episode, Fred Schenkelberg discusses:

• Why MTBF is a poor reliability metric
• Common objections to eliminating MTBF
• Alternatives to MTBF

 

Getting Enough of the Right Professional Development

Learning the basics of reliability engineering is where we all start. Mastering the range of skills and techniques is a never ending quest.

Improving, maintaining, expanding your reliability engineering professional skills takes many forms. There are plenty of options and sources to support your education, yet are do getting enough of the right material?  [Read more…]

Are Your Reliability Engineering Technical Skills Good Enough?

How do you know? How would you know?

There is a lot to know concerning the technical aspects of reliability engineering. From calculating summary statistics to discovering the root cause of a failure, the body of knowledge you should master as a reliability personal is expansive. [Read more…]

How to Avoid Delivering Bad Data

We gather and report loads of data nearly every day.

Is your data “good data”? Or does it fall into the “bad data” category?

Let’s define the difference between good and bad data. Good data is accurate, timely, and useful. Bad data is not. It may be time to look at each set of data you are collecting or reviewing and judge if it’s good or not. Then set plans in motion to minimize the presence of bad data in your organization.

Good data is accurate

By this I mean it truly reprints the items or process being measured.

If the mass is 2.3 kilograms, then the measurement should be pretty close to 2.3 kg. This is a basic assumption we make when reviewing measurements, yet when was the last time you checked? Use a different measurement method, possible a known accurate method to check.

Measurement system analysis includes a few steps to determine if the gage making a measurement is true or not. Calibration may come to mind, as it is a step to verify the gage readings are reflecting standard measures. A meter is a meter is a meter across the many ways we can measure distance.

It also includes checking the common sources of measurement error:

• Repeatability
• Reproducibility
• Bias
• Linearity
• Stability

You may also want to understand the resolution or discrimination of the measurement process.

If these terms and how one goes about checking for accuracy, it may be time to learn a little about MSA.

Good data is timely

If the experiment results are available a week after the decision to launch the product, it will not be considered in the decision. It is not useful for the decision concerning product launch. If the data was available it may alter the decision. Late, we will not know.

Timely means it is in time for someone or some team to make a decision. Ideally, the data is available immediately. When a product fails in the field, we would like to know right away, not two or three month later. If a production line becomes unstable, knowing before another unit of scrap is produced would be timely.

Not all data gathering and reporting is immediate. Some data takes months or an entire year to gather. There are physical constraints in some situation that day the gathering of data. For example is takes on average 13 minutes, 48 seconds, for radio signals to travel from a space probe orbiting Mars to reach Earth [1]. If you are making important measurements on Earth it should be a shorter delay.

The key point here, is the data should be available when it is needed to make decisions.

Good data is useful

Even if the data is accurate and timely is may not be useful. The data could be from a perfect measurement process, yet is measuring something we do not need to know or consider. The data gathered does not help inform us concerning the decision at hand.

For example, if I’m perfectly measuring production throughput, it does not help me understand the causes of the product line downtime. While related to some degrees, instead of the tally of units produced per hour, what we really would find useful is data concerning the number of interruptions to production, plus details on the root cause of each.

Setting up and maintaining the important measurements is difficult as we often shift focus based on the current data. We spot a trend and want to learn more than the current data can provide. The idea is we should not setup and only use a fixed set of data collection processes. Ideally your work to gather data is driven by the need to answer questions.

• Is the maintenance process improving the equipment operation?
• Is our manufacturing process stable and capable of creating our product?
• Will the current product design meet life expectations/requirements?
• Have we confirmed the new design ‘fixed’ the faults seen in the last prototype?

We have questions and we gather data to allow us to answer questions.

How would you describe the data you will look at today? Good or Bad? And more importantly, do you know if your data is good or bad?

—

Time delay between Mars and Earth, Thomas Ormhston, posted 5/8/2012,  European Space Agency, Mars Express Blog, http://blogs.esa.int/mex/2012/08/05/time-delay-between-mars-and-earth/ accessed 4/29/2016

MTBF: According to a Component Supplier

This one made me scratch my head and wonder. Did I read this right?

A reader sent me an except of a document found on Vicor’s site.

“Reliability is quantified as MTBF (Mean Time Between Failures) for repairable product and MTTF (Mean Time To Failure) for non-repairable product. A correct understanding of MTBF is important. A power supply with an MTBF of 40,000 hours does not mean that the power supply should last for an average of 40,000 hours. According to the theory behind the statistics of confidence intervals, the statistical average becomes the true average as the number of samples increase. An MTBF of 40,000 hours, or 1 year for 1 module, becomes 40,000/2 for two modules and 40,000/4 for four modules…”

source: http://www.vicorpower.com/documents/quality/Rel_MTBF.pdf

The except came with the following note and question

“In my opinion this is completely wrong but as I’m fledgling in this subject I’m sensitive to any statements like this.

Could you be so kind and help me a bit on it?”

[Read more…]

Extend Your FMEA Process with Mechanisms

One of the issues I’ve had with failure modes and effects analysis is the focus on failure modes.

The symptoms that the customer or end user will experience are important. If a customer detects that product has failed, that is a failure. The FMEA process does help us to identify and focus on the important elements of a design that improve the product reliability. That is all good.

The issue is the FMEA process doesn’t go far enough to really aide the team focus on what action to take when addressing a failure mode. The process does include the discussion of causes of the failure mode. The causes are often the team members educated opinions on what is likely to cause the failure mode. Often the description of the a cause is a failed part, faulty code, or faulty assembly.

Generally the discussion of causes is vague.

Failure Mechanisms versus Failure Modes

Failures modes are best described as what the customer experiences (no power, loss of function, etc.). Failure mechanisms are the root physical or chemical anomaly that leads to the existence of the failure mode. While we want to remove failure modes, we have to solve, remove, or mitigate failure mechanisms along the way.

The traditional FMEA process in my experience often provides vague classes of causes, hints at potential failure mechanisms, or avoids specifying mechanisms entirely. The actions items from the FMEA study then include investigations to find and understand the actual failure mechanisms (at best) or attempt to address vague classes of mechanisms with broad sweeps of monitoring, testing, or design changes.

Instead focusing the discussion on causes of failures at the level of failure mechanisms, enhances the discussion. Instead of talking about the causes as a component failure, it changes to what happens such that the component fails. Instead a vague average failure rate, it becomes a discussion about design or process errors or variation that leads to the components demise.

The hard part of this approach is the sheer number of ways (root causes) that an item may fail. Consider a simple component solder joint. The potential root causes includes:

• Contamination
• Corrosion
• Dendrite growth
• Cracking
• Shear fracture
• Flex cracking
• Pad lifting
• Gold embrittlement

And many others potential issues. Even these brief descriptions may have underlying causes which are the elements requiring attention in order to solve.

Fault Tree Analysis (FTA) and FMEA

Detailing all possible root causes of each failure mode would be tedious and I would suggest unnecessary. One approach I’ve seen is the common approach to FMEA, where we explore the class or basic expected types of root causes that lead to the listed failure mode. Then for the lines in the FMEA study that percolate to the items requiring attention, we then conduct a detailed FTA that flushes out the range and relative frequency of occurrence of the many different underlying failure mechanisms that lead to a specific failure mode.

If the primary cause of a failure mode is a faulty component, then what are the specific mechanisms that lead to a component being faulty. FTA is the right tool here. Used on conjunction with the highest risks identified in the FMEA permit the team to understand and solve or mitigate the right elements in the design or process to make a difference. Being specific with actions that make a difference is the key.

With your work to identify and resolve risks to reliability performance, how do you insure the solutions are actually solving the right problem? What works for you in your organization? How do you extend your FMEA work into effective action?

Do You Have Enough Data?

To make informed decisions you need information.

To form conclusions you need evidence and a touch of logic.

To discover patterns you need data.

In each case, and others, we often start with data. The data we have on hand, or can quickly gather.

We organize data into tables, summaries into reports, display in dashboards, and analyze the results to form decisions. [Read more…]

The People Skills of a Good Reliability Engineer

Having the technical and business skills is not sufficient to be a good reliability engineer.

You must also work with other people. With your peers, across the management team, with suppliers, contractors, and customers.

The ability to work well with others is often complex and situational. Being aware of a few basic skills will allow you learn and improve. Prette and Prette define social competence as the social skills

that meet the different inter-personal demands in the workplace in order to achieve the goals, preserve the well-being of the staff and respect the rights of each other.

A. Del Prette and Z. A. P. Del Prette, Psicologia das relac ̧o ̃es interpessoais: viveˆncias para o trabalho em grupo, Vozes, Petro ́ polis, 2001.

An engineer needs an awareness of the social situation and how their behavior influences others, along with a capability to correctly understand the behavior and needs of others. The concepts discussed under emotional intelligence include:

• self-awareness
• self-regulation
• Motivation
• Empathy
• and social skills

Goleman, D., Emotional Intelligence: Why It Can Matter  More than IQ. New York: Bantam Books (1995).
Goleman, D., Working with Emotional Intelligence.  London: Bloomsbury Publishing (1998).

The ability to influence others or to aide in understanding a technical situation relies on effective communication. Beyond presenting the facts, finding, and conclusions, your communication must also build upon the audiences’ current understanding and capability. Also, our presentation must address the needs and expectations of the audience. The audience needs are often unstated, thus the need for your ability to correctly assess the social situation.

A Meeting Example

Let’s say two engineers join a meeting to discuss an engineering problem that requires a solution. One engineer, Juan, has social skills and the other, Tomas, does not. As the team assemblies Juan arrives a minute or two early and greets his co-workers and responds to greetings and comments pleasantly. Tomas arrives on time, does not greet anyone and focuses on his laptop catching up on a few emails messages till the meeting is called to order.

A member of the team opens with a short review of the specific technical challenge and as she started with the review of what is known to date, is interrupted by Tomas. Tomas launches into his solution for the problem and remarks that the remainder of the meeting is pointless as he already has an appropriate solution to implement. The solution is not obvious to the remainder of the group which frustrates Tomas as he repeats his assertion that he has a solution. There is social tension building which Tomas does not recognize.

Juan does sense the discontent between Tomas and the rest of the team. Juan does not fully understand the problem nor Tomas’ solution, yet injects a few questions that help guide Tomas to guide the team to better understand the problem and proposed solution. Juan facilitates a discussion between those with knowledge of the problem so the entire team fully understands the issue, plus assists Tomas restate the proposed solution again to help everyone understand the proposal.

The story of this meeting could continue, with more elements of lack of social awareness and skills and possible methods to create progress. It is situations without someone like Juan having the awareness and social adeptness to facilitate effective and socially acceptable communication, that likely end poorly.

Finding a solution is not the only goal of a problem solving meeting. It is finding a solution that the team can implement effectively. This requires the team understand both the problem and the solution. Furthermore, the one meeting is likely part of series of regular engagements for this team, thus impacts the ability of the team to work cohesively going forward.

When social behavior elements such as discussions, questions, and proposals, for example, do not include consideration of the recipients situation that social friction occurs. Those around Tomas may feel belittled, devalued, excluded or ignored. Those around Juan feel heard, included, and accepted. The ability of Juan to adjust his behavior based on his awareness permits the team to hear and understand any proposal, including those from social inept people.

To make a potentially long story short, even is Tomas had the correct solution for the problem, it was Juan’s people skills that permitted the team to find and implement a solution. Juan will likely advance in his career while Tomas will not.

If you are not familiar with emotional intelligence you may want to read a few introductory articles. If you have not examined your ability communicate with individuals or groups, or you have wondered how to improve your ability to influence those around you, look for material (articles, books, seminars, courses) that provide a framework to understand how to communicate effectively.

When I first became an engineer the focus on my education and training focused on technical skills. Later I learned the importance of social skills and found that my technical prowess (little that it was) flourished as others were able to understand and accept my ideas and solutions. Plus, my contributions to meetings helped with the acceptance of other better solutions.

There are a lot of talented people all around us. Our ability to work with them enhances our ability to implement engineering solutions that meet our business and customer expectations. Plus, working well with our team make our work a bit more enjoyable.

The Business Skills of a Good Reliability Engineer

Knowing how estimate sample size or create a Weibull plot is not enough today.

Just having technical skills, while essential, is not sufficient.

Having a master of business administration (MBA) may be helpful it is not required, yet knowing the warranty and brand cost per failure is essential.

You also need to know which analysis to conduct and how it fits into the larger program, organization, and how it impacts your customers. You need to know the business side of your work as well.

You need to understand the business connection as you create plans and finalize analysis. Each test proposed should include a business connection. Each improvement proposed has to balance with the other priorities and objectives and remain compelling.

What is Important to Your Organization?

I don’t know as I write this what is important to your organization today. It varies, even within an organization and over time. You do need to know what is important and why to become a good reliability engineer.

It is not enough to do what someone tells you to do. At first that may get you starting yet how you connect your work to adding value become essential. Practice finding the connection with every task.

Ask questions.

• When do you need this information?
• When will this need an initial review?
• When do you need a budget estimate?
• Who will review this report?
• Who will need this information?
• What level of reliability knowledge does the audience have?
• What level of detail is necessary?

And, so on…

The idea is to find who needs what by when and why?

This helps you plan, focus and deliver what is considered important at the moment in your organization.

Typical Priorities

For a high volume consumer product sold during the holiday period, time to market may be the top priority. This is because a delay to shipping means the loss of sales for the year. Missing the deadline is not an option. Thus, your work as a reliability engineer has to focus on how you can minimize the risk to any delays.

Now, you know that finding a critical reliability issue late in the process may delay the program, therefore focusing on reducing the chance of a late discovery is your focus. Early testing and development work on the highest risk element may help you identify reliability risks that have a long lead time to test and evaluate.

For a industrial product with relatively low volume the time to market pressure is not as intense. In this case, the brand image may be paramount. Thus getting the initial units as reliability as customer expect becomes an overriding priority.

One of the issues with this situation is the lack of prototype systems to evaluate. You may not have the capability to test full systems in any quantity prior to to the start of production, if ever. Thus, you work to identify and characterize each potential failure mechanisms becomes critical. The ability to create a viable system model allows you to prioritize your work on improving the critical few elements that will impact system reliability performance.

Other priorities may focus on cost reduction, cutting edge feature sets, or ease of use. Your organization likely has a clear priority. It’s then up to you to connect your work in reliability engineering to that priority.

Now Connect Each Reliability Task to the Value it Provides

For each reliability task proposed or delivered what is the value it provides connected to the primary priority (or secondary priority) in a clear and concise way. If the task or activity doesn’t add value, why are you doing it?

In the high volume consumer product situation, reducing the risk of a shipment delay provide value. Let’s say you are proposing HALT early in the program. How would that add value? By potentially identifying design or manufacturing faults if discovered late in the program would delay the project, then you arguably reduce the risk of delays by some amount.

For the low volume complex equipment situation, a HALT would improve the ability of the team to find and solve complex issues that may otherwise go undetected. Again, HALT would add value. In each case there is not a hard and fast formula yet there is a clear step by step connection between the task and the value to the organization.

Summary

There are two steps here. One understand the business and customers to the extent that you clearly understand what is important. Second, articulate the value related to the business priorities for each reliability task or activity.

To see more examples and ways to show value, see the book Finding Value: How to Determine the Value of Reliability Engineering Activities.

Your skill at connecting your work to value enhances your ability to focus on what is important and necessary. Thus it helps your customers, organization and your career.