Planes must fly, cars must steer, and Velcro must stick. But, at every turn, there are risks, reasons why a new design won’t work, and it’s the engineer’s job to make the design insensitive to these risks. (Called reducing signal to noise ratio in some circles.) At a fundamental level engineering is about safety, and at a higher level it’s about sales – no function, no sales.

That’s why at every opportunity engineers reduce risk . (And thank goodness we do.) It makes sense that we’re the ones that think things through to the smallest detail, that can’t move on until we have the answer, that ask odd questions that seem irrelevant. It all makes sense since we’re the ones responsible if the risks become reality. We’re the ones that bear ultimate responsibility for product function and safety, and, thankfully, it shapes us.

But there’s a dark side to this risk reduction mindset – where we block our thinking, where we don’t try something new because  of problems we think we may have, problems we don’t have yet. The cause of this innovation-limiting behavior: problem broadening, where we apply a thick layer of problem over the entirety of a new concept, and declare it unworkable. Truth is, we don’t understand things well enough to make that declaration, but, in a knee-jerk way, we misapply our natural risk reduction mindset. Clearly, problems exist when doing new, but real problems are not broad, real problems are not like peanut butter and jelly spread evenly across the whole sandwich. Real problems are narrow; real problems are localized, like getting a drip of jelly on your new shirt.

How to get the best of both worlds? How to embrace the risk reduction mindset so products are safe and help engineering folks to try something radically new? To innovate?

We’ve got the risk reduction world covered, so it’s all about enhancing the try-something-new side. To do this we need to combat problem broadening; we need a process for problem narrowing. With problem narrowing, engineers drill down until the problem is defined as the interaction of two elements (the jelly and your shirt), defined in space (the front of your shirt) and time (when the knife drops a dollop on your shirt). Where problem broadening tells us to avoid making peanut butter and jelly sandwiches altogether (those sandwiches will always dirty our shirts), problem narrowing tells use to put something between the knife and the front of your shirt, or to put on your new shirt after you make your sandwich, or to do something creative to keep the jelly away from our shirt.

Problems narrow as knowledge deepens. Work through your fears, try something new, and advance your knowledge. Then define your problems narrowly, and solve them.

Innovate.

It’s a simple formula, but it provides a framework to focus on fundamentals. While all parts of the organization contribute to profit in their own way, engineering’s work has a surprisingly broad impact on the equation.

The market sets price, but engineering creates function, and improved function increases the price the market will pay. Design the product to do more, and do it better, and customers will pay more. What’s missing for engineering is an objective measure of what is good to the customer.

To read the complete article, click this link.

Manufacturing is about cost, waste, efficiency, and yield (how to make it), and engineering is about function (what it does) – fundamental differences but not the why. The consequence of failure is the why. If manufacturing doesn’t deliver, the product is made like last year (with a bit more waste and cost than planned), but the product still sells. With engineering, not so much. If engineering mistakenly designs the Fris out of the Frisbee or the Hula out of the Hoop, no sales. That’s the why.

No function, no sales, no company, this is fear. This is why it feels dangerous to push on engineering; push on engineering and the wheels may fall off. This why the organization treads lightly; this is why the CEO does not push.

As technical leaders we are the ones who push directly on engineers. We stretch them to create novel technology that creates customer value and drive sales. (If, of course, customers value the technology.) We spend our days in the domain of stress, strain, printed circuit boards, programming languages, thermal models, and egos. As technologists, it’s daunting to push effectively on engineering; as non-technologists even more. How can a CEO do it without the subject matter expertise? The answer is one-page thinking.

One-page thinking forces engineers to describe our work in plain English, simple English, simple language, pictures, images. This cuts clutter and cleans our thinking so non-technologists can understand what’s happening, what’s going on, what we’re thinking, and shape us in the direction of customer, of market, of sales. The result is a hybrid of strong technology, strong technical thinking, and strong product, all with a customer focus, a market focus. A winning combination.

There are several rules to one-page thinking, but start with this one:

Use one page.

As CEO, ask your technical leaders (even the VP or SVP kind) to define each of their product development (or technology) projects on one page, but don’t tell them how. (The struggle creates learning.) When they come back with fifteen PowerPoint slides (a nice reduction from fifty), read just the first one, and send them away. When they come back with five, just read the first. They’ll get the idea. But be patient. To use just one page makes things remarkably clear, but it’s remarkably difficult.

Once the new product (or technology) is defined on one page, it’s time to reduce the fear of pushing on engineering – one-page thinking at the problem level. First, ask the technical leaders for a one-page description of each problem that must be overcome (one page per problem and address only the fundamental problems). Next, for each problem ask for baseline data (test data) on the product you make today. (For each problem they’ll likely have to create a robustness surrogate, a test rig to evaluate product performance.) The problem is solved (and the product will function well) when the new one out-performs the old one. The fear is gone.

When your engineers don’t understand, they can’t explain things on one page.  But when they can, you understand.

To start, we must make a couple commitments to ourselves.  1. We will do what it takes to manufacture products in the US because it’s right for the country. 2. We will be more profitable because of it.

Next, we will set up a meeting with our engineering community, and we will tell them about the two commitments. (We will wear earplugs because the cheering will be overwhelming.) Then, we will throw down the gauntlet; we will tell them that, going forward, it’s no longer acceptable to design products as before, that going forward the mantra is: half the cost, half the parts, half the time. Then we will describe the plan.

On the next new product we will define cost, part count, and assembly time goals 50% less that the existing product; we will train the team on DFMA; we will tear apart the existing product and use the toolset; we will learn where the cost is (so we can design it out); we will learn where the parts are (so we can design them out); we will learn where the assembly time is (so we can design it out).

On the next new product we will front load the engineering work; we will spend the needed time to do the up-front thinking; we will analyze; we will examine; we will weigh options; we will understand our designs. This time we will not just talk about the right work, this time we will do it.

On the next new product we will use our design reviews to hold ourselves accountable to the 50% reductions, to the investment in DFMA tools, to the training plan, to the front-loaded engineering work, to our commitment to our profitability and our country.

On the next new product we will celebrate the success of improved product functionality, improved product robustness, a tighter, more predictable supply chain, increased sales, increased profits, and increased US manufacturing jobs.

On the next new product we will do what it takes to manufacture products in the US because it’s the right thing for the country, and we will be more profitable because of it.

If you’d like some help improving the US economy one company at a time, send me an email (mike@shipulski.com), and I’ll help you put a plan together.

a

p.s. I’m holding a half-day workshop on how to implement systematic cost savings through product design on June 13 in Providence RI as part of the International Forum on DFMA – here’s the link. I hope to see you there.

The first step in the redesign program was determining what needed to change. A steering committee with representation from engineering, manufacturing, marketing, and business leadership spent weeks trying to determine what was required from a product standpoint to deliver radical improvements in both product performance and product economics. As a result of that collaboration, the team established aggressive new targets around robustness and reliability in addition to the goal of cutting the parts count and labor costs nearly in half.

See link for entire article

When Hypertherm (www.hypertherm.com) was getting ready to design its next generation of metal cutting CNCs, the engineering team’s goal was to make improvements. But the controllers, which automate the Hanover, New Hampshire-based company’s advanced cutting tools and systems, were already well-accepted in the marketplace and highly regarded in the industry. So why redesign? And how would they go about it?

See this link for the full article - Using DFMA to Control Controller Design

Identify specific failure modes, prioritize them, and go after the biggest ones first. Failure modes can be identified through multiple sources. Warranty data is sometimes coded by failure mode (more precisely, symptom type), so start there. The number one failure mode in this type of data is typically “no problem found”, so be ready for it. Analysis of the actual products that come back is another good way. Returned product is routed to the appropriate engineer who analyzes it and enters the failure mode into a database. A formal design FMEA generates a list of prioritized failure modes through the risk priority number (RPN), where larger is more important. To do this, engineers are hauled into a room and a facilitator helps them come up with potential failure modes. One caution – the process can generate many failure modes, more than you can fix, so make the top five or ten go away and don’t argue the bottom fifty. It makes no sense to even talk about number eleven if you haven’t fixed the top ten. But the best way I have found to identify failure modes (problems) that are meaningful to the customer is to ask the technical services group for their top five things to fix. They will give you the right answer because they interact daily with customers who have broken product. They won’t expect you to listen to them (you never listened before), so surprise them by fixing one or two on their list. They will be grateful you listened (they’ll likely want to buy you coffee for the rest of your career) and your customers will notice.

Once failure modes are identified, define the physics of failure – why the product breaks. This is tough work and requires focused thought and analysis. If, when you break the product, it “looks like” the ones coming back from the field, you have defined the physics of failure. This is the same thing as replicating the problem in the lab. Once that’s defined, create an automated test rig or experimental setup that breaks the product in a way that captures the physics of failure. I call this test rig a robustness surrogate because it stands in for the actual failure mode seen in the field. The robustness surrogate should break the product as fast as possible while retaining the physics of failure so you can break it and fix it many times before product launch. The robustness surrogate should be designed to break the product within minutes, not hours or days – the faster the better.

To know if product robustness is improved, the baseline (or existing) design is broken on the robustness surrogate. The new design must survive longer on the robustness surrogate than the baseline design. The result is A/B data (baseline design/ new design) that is presented at the design review using a simple bar graph format which I call big-bar-little-bar. Keep improving robustness of the new design even if it outperforms the baseline design by a factor of ten – that’s not good enough for your customers.

Don’t stop improving robustness until you run out of time, and don’t stop if you meet the arbitrary MTBF specification. Customers like improved robustness, and in this case too much of a good thing is wonderful.

Using this method, I reduced warranty cost per unit by 75% over a five year period. It worked.

Every company is at a different stage in their formalized product robustness efforts, so it’s challenging to talk meaningfully to everyone. But there are two especially meaningful principles that have served me well through the years.

I had the privilege of working with Don Clausing - Total Quality Design, The House of Quality, Enhanced QFD, and Robust Quality. I vividly remember the conversation where Don shared one of his secrets. As we watched a robustness test run, Don, in his terse way, barked out a guiding principle of improving product robustness. He said:

“Improve robustness at the expense of predicting it.”

I asked Don what the hell he meant (he liked to make his students work for it), and after some prodding, he went on to explain why it’s so important. He said people spend far too much time running tests to predict robustness and then spend even more time calculating mean time between failures (MTBF). If that’s not enough, then they spend time arguing about MTBFs and the confidence intervals. He said companies should dedicate all their time and energy improving robustness. “That’s what matters to the customer,” he said. And then he continued with something like: “Predicting robustness is worse than a simple waste of time.” (He wasn’t that polite.) But I still didn’t get it. What’s the big deal about predicting robustness?

There are several reasons why this is a big deal. Improving product robustness is hard. It requires new thinking and a singular mindset that demands focus, clear thinking, and a significant amount of emotional energy. Arguing about MTBFs distracts us in a major way and causes our thinking to shift away from what’s important the customer. Just when it’s time to make a difference, to design out a fundamental problem that has been a feature in your product, it distracts thinking away from what is important.

Predicting robustness puts us into the wrong mindset. Just when our engineering team should be relentlessly eliminating failures, driving them completely out the product, stopping at nothing to eradicate them, we start comparing MTBFs against the specification.  We tell the engineers that failures are okay and can be tolerated. Think about the MTBF specification – it’s an arbitrary level of acceptable failures pulled out of the ass of some program manager who can barely spell MTBF; it’s an acceptable level of failures. How can we flog the engineering teams to eliminate failures while we bookkeep them against an acceptable level of failures? As I tell my kids: “That’s not okay.”

In product development the schedule is king, and every second counts. Every second talking about predicting robustness is a second not improving it. And discussions on predicting robustness consume lots of time. As engineers, we think it’s sport to dig into topics just for the sake of digging in and we like to argue about subtleties. There’s plenty of fodder for that with reliability prediction. There’s that crazy Weibull math with its equally intriguing graph paper, the subtleties of assuming the right distribution so the statistics come out right, and the ever-popular calculation of confidence intervals.  All the while, the clock is ticking.

Tests to predict robustness take a long time and consume expensive, shared resources like test stations and test engineers and technicians. Every second testing to predict robustness is a second not testing to improve it. Simply put, those resources should be running tests to improve robustness not predict it.  Customers care about improved robustness not the predicted kind.

The second principle is from Don, too, though not his language – the censors would never have it. If you’re not using the words “failure modes” in every other sentence, you are not improving robustness. If you don’t define the specific failure mode you’re trying to eliminate, you don’t know what the hell you are doing. If you don’t know how and why it breaks, you can’t eliminate the failure mode.

“It’s all about failure modes.”

Mindset aside, if you focus on eliminating specific failure modes you’re on your way. But there’s a big problems with failure modes. We engineers hate them. We hate to write them down and we hate doing Failure Modes and Effects Analyes (FMEA) even more. There is no amount of cajoling that can get us to like working with failure modes, but we must learn to tolerate them if not embrace them. It’s good for us, like medicine – tastes like crap and a year later you feel better.

One last thing about failure modes. Don’t try to fix them all. Pick handful of the most important ones and eliminate them altogether.

To summarize, a strong focus on improving product robustness is magical. Your customers will notice the difference.

A customer walks up to your product, turns it on, and it works without breaking or getting in its own way.

Bad product robustness is bad for your brand. Very bad. Customers do not like when they pay money for a product and it doesn’t work, especially when they rely on those products to make money for themselves. And they remember the experience in a visceral way.

You can’t fix bad product robustness with great marketing; you can’t fix it with spin selling; you can’t tell customers you fixed it when you didn’t (since they use your product, they know the truth); and you can’t hide it because customers talk (so do competitors). There is no quick fix – it takes tools, time, training, and new thinking to improve product robustness. And when you do manage to fix it, customers won’t believe you until the see it for themselves. They don’t want to get burned again.

No product is infinitely robust, nor should it be. It doesn’t make financial sense. The product would be infinitely expensive and would take an infinite amount time to develop. But how much robustness is enough? An easier, and possibly more important, question to answer is – how much is too little? Or, stated another way, what is the minimum level of product robustness?

The specialists won’t agree with my assertion that there is a minimum threshold for product robustness, but I don’t care. I think there is one. I call this minimum value the brand-damaging threshold. Here’s an operational definition of product robustness that’s below the brand-damaging threshold:

Customers don’t buy your product because they know it breaks or gets in its own way and they go out of their way to tell others about it.

It is difficult to know when customers don’t buy, never mind know why they don’t. But there are some tell-tale signs that product robustness is below the brand-damaging threshold. Here are a few.

The CEO takes enough direct calls about products that don’t work to feel obligated to send you a thoughtfully-crafted, four word email saying something like “Fix that @#&% thing!” Customers have to be really pissed off to call the CEO directly, so the situation is bad. It’s also bad for a reason that’s closer to home – the CEO sent the email to you.

You get a little sick to your stomach when sales increase. You know you should be happy, but you’re not. Deep down you know you’ll see many of those products again because they’ll be sent back by angry customers, in pieces.

The volume of returns is so significant you create a refurbishment department. Or you create a new group to scavenge the reusable stuff off the piles of returned product. Not good signs.

Your product’s lack of robustness is the headline message in your customers’ marketing literature.

Now that the brand-damaging threshold is defined, the next logical topic is how to improve product robustness so it’s above the threshold. But that’s for another post.