Shipulski On Design

Posts Tagged ‘Engineering Mindset’

As an engineering leader I work with design engineers every day. I like working with them, it’s fun. It’s comfortable for me because I understand us.  Yes, I am an engineer.

I know what we’re good at, and I know we’re not good at. I’ve heard the jokes. Some funny, some not.  But when engineers and non-engineers work well together, there’s lots of money to be made. I figure it’s time to explain how engineers tick so we can make more money. An engineer explaining engineers, to non-engineers – a flawed premise?  Maybe, but I’ll roll the dice.

Everyone knows why design engineers are great to have around.  Want a new product?  Put some design engineers on it.  Want to solve a tough technical problem?  Put some design engineers on it. Want to create something from nothing? Design engineers. Everyone also knows we can be difficult to work with. (I know I can be.) How can we be high performing in some contexts and low performing in others? What causes the flip between modes? Understanding what’s behind this dichotomy is the key to understanding engineers. What’s behind this?  In a word, “change”.  And if you understand change from an engineer’s perspective, you understand engineers.  If you remember just one sentence, here it is:

To engineers, change equals risk, and risk is bad.

Why do we think that way?  Because that’s who we are; we’re walking risk reduction machines. And that’s good because in this time of doing more, doing it with less, and doing it faster, companies are taking more risk.  Engineers make sure risk is always part of  the risk-reward equation.

The best way to explain how engineers think about change and risk is to give examples.  Here three examples.

Changing a drawing for manufacturing

Several months after product launch, with things running well, there is a request to change an engineering print.  Change the print? That print is my recipe. I know how it works and when it doesn’t.  That recipe works.  My job is to make sure it works, and someone wants to change it?  I’m not sure it will work.  Did I tell you it’s my job to make sure it works? I don’t have time to test it thoroughly. Remember, when I say it will work, you expect that it will.  I’m not sure the change will work.  I don’t want to take the risk.  Change is risk.

Changing the specification

This is a big one.  Three months into a new product development project, the performance specification is changed, moving it north into unknown territory.  The customer will benefit from the increased performance, we understand this, but the change created risk. The knowledge we created over the last three months may not be relevant, and we may have to recreate it. We want to meet the new specification (we’re passionate about product and technology), but we don’t know if we can. You count on us to be sure that things will work, and we pride ourselves on our ability to do that for you.  But with the recent specification change, we’re not sure we can get it done. That’s risk, that’s uncomfortable for us, and that’s the reason we respond as we do to specification changes.  Change is risk.

Changing how we do product development

This is the big one. We have our ways of doing things and we like them. Our design processes are linear, rational, and make sense (to us). We know what we can deliver when we follow our processes; we know about how long it will take; and we know the product will work when we’re done. Low risk. Why do you want us to change how we do things? Why do you want to add risk to our processes? All we’re trying to do is deliver a great product for you. Change is risk.

Engineers have a natural bias toward risk reduction. I am not rationalizing or criticizing, just explaining. We don’t expect zero risk; we know it’s about risk optimization and not risk minimization.  But it’s important to keep your eye on us to make sure our risk pendulum does not swing too far toward minimization. The great American philosopher Mae West said, “Too much of a good thing can be wonderful.”   But that’s not the case here.

When it comes to engineers and risk reduction, too much of a good thing is not wonderful.

Improving product robustness is straightforward and difficult. Here’s how to do it.

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.

In a previous post I defined the term brand-damaging threshold and said I’d talk about how to improve product robustness. So, here goes.

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? Read the rest of this entry »

2009 is a tough year, especially for CEOs.

CEOs have a strong desire to do what it takes to deliver shareholder value, but that’s coupled with a deep concern that tough decisions may dismantle the company in the process.

Here is the state-of-affairs:

Sales are down and money is tight.  There is severe pressure to cut costs including those that are linked to sales – marketing budgets, sales budgets, travel – and things that directly impact customers – technical service, product manuals, translations, and warranty.

Pricing pressure is staggering.  Customers are exerting their buying power – since so few are buying they want to name their price (and can).  Suppliers, especially the big ones, are using their muscle to raise prices.

Capacity utilization is ultra-low, so the bounce-back of new equipment sales is a long way off.

Everyone wants to expand into new markets to increase sales, but this is a particularly daunting task with competitors hunkering down to retain market share, cuts in sales and marketing budgets, and hobbled product development engines.

There is a desire to improve factory efficiency to cut costs (rather than to increase throughput like in 2008), but no one wants to spend money to make money – payback must be measured in milliseconds.

So what’s a CEO to do?  Read the rest of this entry »