Shipulski On Design

Archive for the ‘Product Development’ Category

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 »