Monday, May 16, 2011

Integrate the DFSS Roadmap Into Your Product Development Process

Executive Summary:
If your business is adopting the Design for Six Sigma (DFSS) methodology, don’t make the mistake of replacing your product development process with the DFSS Roadmap.  Instead, make the DFSS Roadmap fit your existing product development process.

The Rest of the Story:
Design for Six Sigma is a powerful tool for many businesses.  It gives a design team the power to predict the performance and the defect rate of a product before it’s launched.  Actually, it gives the design team the power to control the defect rate of a product.

It is every bit as powerful as it sounds.  DFSS is the key to truly achieving the 3 defects in 1-million opportunities performance that the Six Sigma methodology chases.  However, DFSS isn’t for every business.

Design for Six Sigma requires a substantial investment in skill set development and a strong discipline to spend more time and energy early in the design process so that the latter stages will progress more swiftly.  It requires a significant cultural change for most businesses.

If your business has decided that Design for Six Sigma is the right solution, then I offer you some advice to make the transition much easier.  Do not replace your product development process with the DFSS Roadmap.  Instead, make the roadmap fit into your existing process.

The DFSS Roadmap is a guideline to step us deliberately through the DFSS problem solving methodology.  It must be followed in order for the DFSS method to work, but it is a problem solving approach, not a product development process.

There are several popular DFSS Roadmaps to choose from including PIDOV (Plan-Identify-Design-Optimize-Verify), and DMADV or DMADOV (Define-Measure-Analyze-Design-Optimize-Verify/Validate) to name the most common two or three.  The fact that there are several to choose from should be our first clue that we can manipulate the roadmap to meet our own needs.

Rather than trying to pick the best roadmap, we should instead study the content of the various roadmaps to understand the problem solving method.  Once we understand the method, we can incorporate it into our existing process.

There is a basic sequence that every DFSS Roadmap has in common, regardless of the acronym.
  1. Define what the solution must be, do, or have – define what success looks like
  2. Establish what your current, related production processes can and can’t do, particularly understand the variation of the processes
  3. With process capability in mind, design the solution, optimize performance while minimizing the probability for defects caused by variation
  4. Verify that the solution follows the predictions and performs appropriately before launching it

Look at the sequence again.  Excepting perhaps the investigation into process variation and capability, your product development process probably already follows the same sequence, roughly speaking.

What the DFSS Roadmap does not provide are the triggers for supplier contracts and communication, marketing materials and promotions, packaging design, writing of instructions, and a myriad of other activities needed to smoothly execute a complete product development effort.  Believe me, you do not want to throw out all of the product development knowledge and experience you have established over years or decades of practice.

So how do we follow DFSS if we don’t follow the DFSS Roadmap for product development?  The answer is that we do absolutely follow the DFSS Roadmap, but we follow it within our product development process, not instead of our product development process.

Here is what I mean.  Suppose that you are developing a product that is a complex system including several subsystems, electronics and mechanical components, and potentially more that one manufacturing or assembly facility.  There will not be one round of defining requirements, measuring processes, analyzing capabilities, or designing and verifying (DMADV) 

You will define the overall product requirements, but later, as the product concept starts to become complete you will also need to define specific subsystem requirements.  You may measure and analyze production data, but as you begin detailing the design, analyses may show that certain requirements are not met or that defect rates will be too high.

You will make adjustments to the design that might require changes in suppliers or manufacturing processes, which leads to more measure and analyze steps.  Subsystems will not be designed absolutely concurrently and two subsystems will not move from Analyze to Design or from Design to Verify at exactly the same time.

So if IPDOV or DMADV is not a perfect fit for product development, why do we need it at all?  As I mentioned earlier, it defines a problem solving structure and for DFSS to work we must adopt a discipline of following that structure throughout our design process and decisions.

For a successful incorporation of DFSS into your product development process, here is what I suggest.    Diagram the DFSS Roadmap you have selected, or that your consultant has promoted, as part of your product development process.

For example, suppose that your phase-gate style product development process is defined as Requirements-Concept-Design-Test-Launch.  You can match up the DFSS Define and Measure with Requirements, Analyze with Concept because here is where you are solidifying a plan to satisfy the requirements and the analysis will be part of your confidence the plan is good.  Obviously, Design matches Design, and Verify matches Test.  Launch remains on it’s own.

Now you have a diagram to communicate to managers and design teams alike, how the DFSS methodology and your product development process will work in concert to drive success, or more powerfully, how DFSS and your product development experience have been merged to provide a single methodology for better products and business success.

Don’t get too rigidly glued to the model we just described, however.  The truth of the DFSS roadmap and the method it describes lives at a much lower level of your product design execution.

When you go about collecting voice-of-the-customer data so you can establish your product requirements, if you truly understand and adopt the DFSS methodology, you will first Define your market for the product and the customers to consult, you will Measure or gather data, you will Analyze that data, and then you will use that information to Design your product requirements.  Lastly, you will return to those customers and Verify that if you produced what you defined that they would buy the product for the price you target.

You see, you will treat individual components of the product development process as unique problems and utilize the DFSS methodology to solve each problem.  In this example I outlined the complete DMADV sequence within the single Requirements/Define step of the product development process.

The same thing will happen with the concept, with each subsystem, even with the development of your test plan.  You will define the limits of the test, measure and analyze the noise involved in the test, design the test, and verify that the test apparatus performs before actually testing your prototypes.

None of the DFSS textbooks that I have read, and I’ve read many of them, have explained how to truly incorporate the DFSS roadmap into complete product development activity.  In fact, most of them make it easy for managers and leaders, for any of us really, to misinterpret how to use the method to develop solutions.

As a result, it’s a common mistake to throw away the existing product development knowledge-steeped process and try to replace it with the DFSS roadmap.  I’ve even argued with a few consultants who insisted on doing exactly that.  Don’t make the mistake.

The DFSS roadmap cannot replace years of product development knowhow, which you have carefully built into your process.  It does, however, provide a powerful discipline for addressing each and every step or problem within the process so that your team can predict and control the defect rate of your products.

Take the advice above to heart.  Not only will it make it easier for your teams to incorporate the DFSS methodology into their daily practices, it will make both your product development and your DFSS practices more powerful.

Stay wise, friends.

No comments:

Post a Comment