Shipulski On Design

Archive for the ‘Product Development’ Category

Axiom 1 – Time is short, so make sure you’re working on the most important stuff.

Axiom 2 – You can’t design out what you can’t see.

In product development, these two axioms can keep you out of trouble. They’re two sides of the same coin, but I’ll describe them one at a time and hope it comes together in the end.

With Axiom 1, how do you make sure you’re working on the most important stuff? We all know it’s function first – no learning there. But, sorry design engineers, it doesn’t end with function. You must also design for lean, for cost, and factory floor space. Great. More things to design for. Didn’t you say time was short? How the hell am I going to design for all that?

Now onto the seeing business of Axiom 2. If we agree that lean, cost, and factory floor space are the right stuff, we must “see it” if we are to design it out. See lean? See cost? See factory floor space? You’re nuts.  How do you expect us to do that?

Pareto to the rescue – use Pareto charts to identify the most important stuff, to prioritize the work. With Pareto, it’s simple: work on the biggest bars at the expense of the smaller ones. But, Paretos of what?

There is no such thing as a clean sheet design – all new product designs have a lineage. A new design is based on an existing design, a baseline design, with improvements made in several areas to realize more features or better function defined by the product specification. The Pareto charts are created from the baseline design to allow you to see the things  to design out (Axiom 2). But what lenses to use to see lean, cost, and factory floor space?

Here are Pareto’s three lenses so see what must be seen:

To lean out lean out your factory, design out the parts. Parts create waste and part count is the surrogate for lean.

To design out cost, measure cost. Cost is the surrogate for cost.

To design out factory floor space, measure assembly time. Since factory floor space scales with assembly time, assembly time is the surrogate for factory floor space.

Now that your design engineers have created the right Pareto charts and can see with the right glasses, they’re ready to focus their efforts on the most important stuff. No boiling the ocean here. For lean, focus on part count of subassembly 1; for cost, focus on the cost of subassemblies 2 and 4; for floor space, focus on assembly time of subassembly 5. Leave the others alone.

Focus is important and difficult, but Pareto can help you see the light.

The data-driven people in our lives tell us that you can’t improve what you can’t measure.  I believe that. And it’s no different with product cost. Before improving product cost, before designing it out, you have to know where it is. However, it can be difficult to know what really creates cost.  Not all parts and features are created equal; some create more cost than others, and it’s often unclear which are the heavy hitters. Sometimes the heavy hitters don’t look heavy, and often are buried deeply within the hidden factory.

Measure, measure, measure.  That’s what the black belts say.  However, it’s difficult to do well with product cost since our costing methods are hosed up and our measurement systems are limited. What do I mean? Consider fasteners (e.g., nuts, bolts, screws, and washers), the product’s most basic life form. Because fasteners are not on the BOM, they’re not part of product cost. Here’s the party line: it’s overhead to be shared evenly across all the products in a socialist way.  That’s not a big deal, right?  Wrong.  Although fasteners don’t cost much in ones and twos, they do add up. 300-500 pieces per unit times the number of units per year makes for a lot of unallocated and untracked cost.  However, a more significant issue with those little buggers is they take a lot of time attach to the product.  For example, using standard time data from DFMA software, assembly of a 1/4″ nut with a bolt, locktite, a lockwasher, and cleanup takes 50 seconds.  That’s a lot of time. You should be asking yourself what that translates to in your product. To figure it out, multiply the number nut/bolt/washer groupings by 50 seconds and multiply the result by the number of units per year. Actually, never mind.  You can’t do the calculation because you don’t know the number of nut/bolt/washer combinations that are in your product. You could try to query your BOMs, but the information is likely not there.  Remember, fasteners are overhead and not allocated to product. Have you ever tried to do a cost reduction project on overhead?  It’s impossible.  Because overhead inflicts pain evenly to all, no one is responsible to reduce it.

With fasteners, it’s like death by a thousand cuts.

The time to attach them can be as much as 20-50% of labor. That’s right, up to 50%.  That’s like paying 20-50% of your folks to attach fasteners all day. That should make you sick.  But it’s actually worse than that.  From Line Design 101, the number of assembly stations is proportional to demand times labor time. Since fasteners inflate labor time, they also inflate the number of assembly stations, which, in turn, inflates the factory floor space needed to meet demand. Would you rather design out fasteners or add 15% to your floor space?  I know you can get good deals on factory floor space due to the recession, but I’d still rather design out fasteners.

Even with the amount of assembly labor consumed by fasteners, our thinking and computer systems are blind to them and the associated follow-on costs. And because of our vision problems, the design community cannot be held accountable to design out those costs.  We’ve given them the opportunity to play dumb and say things like, “Those fastener things are free. I’m not going to spend time worrying about that.  It’s not part of the product cost.”  Clearly not an enlightened statement, but it’s difficult to overcome without cost allocation data for the fasteners.

The work-around for our ailing thinking and computer-based cost tracking systems is simple: get the design engineers out to the production floor to build the product.  Have them experience first hand how much waste is in the product.  They’ll come back with a deep-in-the-gut understanding of how things really are. Then, have them use DFMA software to score the existing design, part-by-part, feature-by-feature.  I guarantee everyone will know where the cost is after that. And once they know where the cost is, it will be easy for them to design it out.

I have data to support my assertion that fasteners can make up 20-50% of labor time, but don’t take my word for it. Go out to the factory floor, shut your eyes and listen.  You’ll likely hear the never ending song of the nut runners. With each chirp, another nut is fastened to its bolt and washer, and another small bit of labor and factory floor space is consumed by the lowly fastener.

There is a healthy tension between level of improvement, or level of innovation, and time to market. Marketing wants radical improvement, infinitely short project schedules, and no change to the product. Engineers want to sign up for the minimum level of improvement, project schedules sufficiently long to study everything to death, and want to change everything about the new product. It’s healthy because there is balance – both are pulling equally hard in opposite directions and things end up somewhere in the middle. It’s not a stress-free environment, but it’s not too bad. But, sometimes the tension is unhealthy.

There are two flavors of unhealthy tension. First is when engineering has too much pull; they (we) sandbag on product performance and project timelines and change the design willy-nilly simply because they can (and it’s fun). The results are long project timelines, highly innovative designs that don’t work well, a lack of product robustness, and a boatload of new parts and assemblies. (Product complexity.) Second is when Marketing has too much pull; they ask for radical improvement in product functionality with project timelines too short for the level of innovation, and tightly constrain product changes such that solutions are not within the constraints. The results are long project timelines and un-innovative designs that don’t meet product specifications. (The solutions are outside the constraints.) Both sides are at fault in both scenarios. There are no clean hands.

What are the fundamentals behind all this gamesmanship? For engineering it’s technical risk; for marketing it’s schedule risk. Engineering minimizes what it signs up for in order to reduce technical risk and petitions for long project timelines to reduce it. Marketing minimizes product changes (constraints) to reduce schedule risk and petitions for short project timelines to reduce it. (Product development teams work harder with short schedules.) Something’s got to change. Read the rest of this entry »

There is no question that Six Sigma helps companies make money. So much so that everyone in the manufacturing community knows the five hallowed letters: DMAIC (Define, Measure, Analyze, Improve, Control). It’s straightforward and fully wrung-out. But that’s not the case for the wicked step sister Design for Six Sigma (DFSS). She’s fundamentally different and more complicated. To start, it’s an alphabet soup out there. Here are some of the letters: DMADV, DMADOV, IDOV, and DMEDI, and there are likely more. Does everyone know these letters and what they stand for? Not me. But here is the fundamental difference: with DMAIC the thing to be improved already exists and with DFSS the thing to be created does not. In essence, there is no formalized problem to solve. So what you say?

With DMAIC it’s all about reducing variation relative to the specification; with DFSS there is no specification. In fact, there is no product yet a process on which we can measure variation. First the product itself must be created and its functional performance must be defined over a range of parameters. Only then is manufacturing variation measured relative to the range functional parameters (DMAIC). But I got ahead of myself.

Before creating the thing that does not exist and make sure it meets the functional specification, some mind reading of customer needs is required, an even lesser defined thing. So, there is a round of reading customers minds followed by round of creating something that does not exist to satisfy the customer needs define in the mind reading sessions. Oh yea, then the tolerances must be defined so the product always functions the way it’s supposed to. All this before we turn the DMAIC crank.

My point with all this is to help set expectations when dealing with product design/DFSS. It is wrong to expect the predictability and standardization of DMAIC when doing product design/DFSS.  It’s different.  Product design/DFSS is not the same turn-the-crank kind of operation. That is not to say there is zero predictability and standard work or that predictability is not something to strive for. It’s just different. With product design the problems are unknown at the start and sometime even the fundamental physics are unknown. Please keep this in mind when your product development projects are late relative to hyper aggressive, non-work-content-based schedules or when new products don’t meet the arbitrary cost targets.

Congratulations. You’ve managed to keep your product development engine running. Good work.  But now the hard part. Marketing and sales know new products are a key to profitability, and so does the CEO. So they’ve all asked for more new products, and now you have more active product development projects in the pipeline. The product development folks will do whatever they can to crank out the products. But can they get it done?

When does the product pipeline become too much for your product development engine to handle? We all know you can’t keep adding more new product development projects without adding capacity or improving productivity. Sure you can ask your product development engine to do more (and more), and it will try; but at some point it will run out of gas. So, ask yourself: Has your product development engine run out of gas? How can you tell? If it hasn’t, do you know how many miles are left in the tank?

If you don’t measure it you can’t improve it, that’s what the black belts say. But what to measure? What are the right metrics to tell you if your product development engine is out of gas? One of the best books on the subject is Managing the Design Factory, by Don Reinertsen. The rest of the post is strongly shaped by Don’s book, if not taken directly from it. Remember, genius steals.

The best metrics are simple, relevant to the objective, and are leading indicators. Simple so they’re easy to interpret; relevant so they move you toward the objective, in this case launching more new products; and are leading indicators, in that they are predictors of outcomes, so you can take action before catastrophic outcomes occur.  Here are three good ones. Read the rest of this entry »

It was Monday night after dinner.  My thirteen year old son and I got in the car and started on the drive to hockey practice.  I drove and he texted.  I was in the middle a struggle to come up with a topic for this post.  My son finished a text, snapped his phone shut, and blurted out “Mozart wrote a note to his dad.  He told him that he thought silence was the most important part of music.”  I responded, “Really.”  “He was a rule breaker,” he said.  He paused then continued, “The music of the time was smooth with a regular pattern.  But he did things that weren’t pleasing to the ear like using 7^th notes and Bs right next to B flats.  Do you know what else he did?”  “No,” I said.  “He put a fermata right in the middle of one of his pieces.  That’s a rest that’s as long as you want it to be.  When you use a fermata you can stop, go out and get a cup of coffee, and come back later and start playing and that’s okay.”  “Really,” I said.

I dropped him off at the rink and pulled into a parking spot so I could write in the car (don’t knock it until you try it).  I jotted down some scattered thoughts, and it hit me.  Jackie!  It was Jackie.  His piano teacher was behind all this.  That morning she taught him about Mozart.  I now had my topic.

Jackie is a great piano teacher – really great.  Sure, she’s got the pedigree, but more importantly she has the ability to reach my son.  She can help him grow his thinking, help him think differently, help him build new thinking for himself.  And this new thinking isn’t the kind that stops at his head, but makes it all the way into his chest.  He feels this new thinking in his chest.  We can learn a lot from Jackie.  I want to look at her system for teaching new thinking, which she does under the cover of teaching piano, and compare it to how we improve our engineering thinking under cover of developing new products.  Sounds like a stretch, I know, but I’ll take a shot at it.

The framework for Jackie’s system can be described by the three Ts – tools, training, and time.  Let’s start with tools. Read the rest of this entry »