Volume 6, #5, July, 2008
To Go Faster, First Slow Down
A Discoveries Q&A About Six Sigma, VOC, and the Importance of Getting Requirements Right the First Time
We recently had a conversation with Stephen Scharf, Design for Six Sigma Specialist at life sciences company Applied Biosystems, about the intersection of Six Sigma and voice of the customer (VOC). Scharf is a molecular biologist by training who found his way into the Six Sigma world three years ago. Six Sigma's emphasis on data driven-results and measurement appealed to him. When he began contemplating what didn't work about product design processes, he began to see how VOC could dovetail with Six Sigma improvements.
For a bit of perspective, take a look at the 2003 Discoveries article, "Toward Designing a Flawless Product: Integrating Voice of the Customer (VOC) into Design for Six Sigma (DFSS)."
DISCOVERIES: Can you briefly set the stage by describing the experience you've had in both arenas, Six Sigma and VOC?
SCHARF: I have a background as molecular biologist, in human molecular genetics. In 2005, my supervisor in our applied markets division got me involved with classic Six Sigma DMAIC (define/measure/analyze/improve/control) training. This Six Sigma work was all around process improvements, fixing quality processes that are already in place. I did the training and completed a certification project that won an award at our company’s internal conference for best management/process development project. We were looking at reducing the time to commercialize assays for tests we were selling to customers. Many design teams and scientists (including myself) were finding that the one of the principal factors contributing to excessive time to commercialization was, at the time, we had no formal, up-front requirements-generating process.
DISCOVERIES: Why was this significant?
SCHARF: It's a classic problem many companies face. Many companies have this idea for a product, and they want their scientists or design team immediately to go into the lab and get working. So the scientists or engineers would go in to the lab and get to work. But often they weren't really sure what they were working on or why, and marketing frequently changed requirements and features as they were in already in the process of developing products. This creates a non-value added and wasteful process of reiterating design because the requirements keep changing. I realized that the biggest factor was that we had that was affecting product development lead time was that we had no formal process for obtaining, structuring, and prioritizing requirements.
A year after I finished the classic Six Sigma training, one of the VPs of R&D hired a contractor to provide DFSS training. A number of my co-workers also went through this, and it further opened my eyes. I saw that we could use the approach not only for improving existing processes but also to design in quality from the outset. Being a laboratory scientist, that really appealed to me. I could shape my designs from day one. I saw that even if I used all kinds of tools like functional modeling to make sure a design was repeatable, without a clear set of requirements, I still didn't know what to execute. When I started thinking about this, researching and reading some of the academic literature, I realized that VOC was key. I formulated a number of thoughts in this area and about a year later I started working as a DFSS (Design for Six Sigma) specialist in the company.
DISCOVERIES: So you came to see Six Sigma as a real boon to the design process?
In many environments just the mention of Six Sigma raises an immune response -- people have been there, done that, and not obtained the results they hoped for. But I think that's often naïve. If you think deeply about what it's doing, both Six Sigma and DFSS are collections of many types of best practices and techniques that have been pulled together over the last 30 years from their roots in Japanese companies like Toyota, Honda, Mitsubishi, starting with Quality Function Deployment in the early 1970s. It's really common sense. If you think about what all of this really means, it actually does bring a great deal of value to an organization. But you need robust VOC in place first.
DISCOVERIES: Why is that?
SCHARF: When I introduce a new team to VOC through boot camps, I tell people their deliverables are a structured set of requirements that are structured, prioritized and ranked, and they have to be measurable. They need to be measurable so they know how to create a capable functionality or process to fulfill the requirements (capability is a statistical measure of how well the resultant product meets the requirements). If an engineer cannot assess capability, then they can’t assess if design has, in fact, met the requirements. DFSS provides a great means to build a quality house, but the foundation for that house is VOC. The better the foundation, the better the house you can build.
Internally we refer to this process as "design excellence" to avoid that immune response to Six Sigma. But, as Sheila [Mello] has said, it doesn't matter what we call it. We can call it "fish." The bottom line is that these approaches work. Best-in-class companies understand how to create quality and value for customers. Customers' expectations for both are always increasing. Unless you have some understanding of how to achieve both, you won't be delivering on their expectations. Every day, you can see the financial success of companies that know how to do this.
One very naturally follows the other. Once you have a set of structured, prioritized, and ranked requirements in place, you can understand which requirements represent fulfillment of missing functionality for customers and the engineer can say, "What functionality do I need to provide?" If you do a Kano survey [see article about Kano], you know with statistical certainty that these CTQs (critical-to-quality requirements) are the ones we really need to deliver on. If you don't deliver those, customers won't value your product. This is a very powerful thing to provide your design team.
When I am facilitating VOC training or projects, I describe it as an opportunity for innovation. If you keep your VOC work solution-free, you open up many more opportunities for meeting customer needs. If you limit yourself to preconceived solutions, you limit your opportunity to differentiate your product or create new IP for your company. By taking the approach of keeping requirements solution-free, you create more opportunities for innovation and differentiation. These things drive revenue and top-line growth.
DISCOVERIES: So how do you keep requirements free of the burden of a preconceived solution?
SCHARF: One way is to understand customer needs and how they are not being met, then mapping clearly to the functions your product can provide. Now let's say there are two functions in conflict, for example, customers want a cell phone with long battery life that's also small and light. Once you understand where those conflicts are, how they impact the customer's ability to accomplish their goals, and the relative importance to customers of each requirement, then you can have a breakthrough by figuring out how to do something no one else is doing. This gets engineers and scientists really excited. When you're able to make a set of requirements executable, then you begin to see real creativity. You have to get people to open up their minds.
DISCOVERIES: Opening minds sounds like a tall order.
SCHARF: For engineers and scientists, it can be difficult, because they're so solution-oriented and it can be hard to get out of that solution-oriented focus. We say to them, it's great to have ideas, everybody has them. But rather than immediately jumping to a solution, jot your ideas down in a little notebook. Then when we get to the concept-generation phase, using TRIZ, or brainstorming or other tools, then open up your notebook and look at those ideas. We've found it's really helpful to have an independent facilitator for VOC activities -- someone without an agenda. The facilitator keeps people on course and keeps the process honest. It can be easier for the team to hear things from an outsider, not necessarily even outside the company, but outside the team, someone not involved in decision-making for that business unit. And the outside facilitator doesn't have an agenda. If a product manager is facilitating, it might be hard to keep preconceived ideas about the solution from creeping into the process.
DISCOVERIES: Can you describe a corporate culture where melding together Six Sigma and VOC works particularly well?
SCHARF: Companies that are more eastern or Asian in their approach. Asian companies took what Deming had to say to heart [W. Edwards Deming developed a management philosophy that helped the Japanese economy recover after WWII]. Western businesses tend to be very action oriented: get it done now. The eastern sensibility is more reflective. Before taking something on, there's an inclination to learn, think, and reflect, then make a decision as how to move forward. Many western companies are so action-oriented that they don't want to take the time to stop and reflect, plan, and put a truly cross-functional team together as we did when we did our project.
DISCOVERIES: What's the harm in taking action and getting things done?
SCHARF: In order to go fast, first you have to slow down. You have to get your requirements in order. What functions do they fulfill? How do you mediate or resolve conflicts between functions? Does the resolution of conflicts help create opportunities for unique solutions? Too many western-culture companies say, "Just get going." If you're not coding, forging steel, or pipetting, then you're not working. But if you're planning the Allied invasion of Europe in World War II, you don't just jump in. You have to get it right the first time. Yet, so many companies don't understand this. You may not get a second chance to get it right. The competitive landscape is only getting more challenging. For example, I wouldn't want to get into the auto business against Honda. It's impressive to see how seriously they take VOC, the time they're willing to put in up front. They don't just come up with one design. They come up with multiple designs and vet them over time with customers. It's not only doing the ethnographic research up front, it's going back to that target market again and again through the stages of design. [See the article, "How Honda Innovates," in the May 2008 issue of the Journal of Product Innovation Management.]
Often, there's a feeling that "We don't have time to do it right the first time, but we have time to do it over." That's how many companies operate. That's not to say all American companies operate this way. Take the example of Adobe Systems. I was visited by Adobe as a customer, a photographer who shoots motorsports at local California racing circuits. They wanted to understand my workflow for deadline press. They had a four-person team come and interview me about my problems. They videotaped the interview and wrote down everything. Then they created a beta of a program called Lightroom that they made broadly available for all users to test. Every quarter, they iterated the product based on user feedback that they solicited through their website, Adobe Labs. And even though the product, Lightroom, came out almost a year after a competing product from Apple, it surpassed the Apple product in sales within nine months of being introduced.
DISCOVERIES: Six Sigma relies on measurement as one of its cornerstones. How do you see measurement figuring into voice-of-the-customer efforts?
SCHARF: The measurement aspect has definitely helped us understand where the rubber meets the road in terms of translating the fuzzy front end of product development into measurable requirements. Like anything else, it takes experience and practice. I work with introducing teams to VOC in "boot camps." They're called boot camps because the teams really do a lot of work in learning how to write real requirements. When people start out, they might write a requirement for a cell phone that says "Two-week battery life." When I ask why, they say, "Well the customer told me he wanted the battery to last two weeks, so I wrote that." You need to back up to make sure you understand the problem that request would have solved, and then write the requirement in such a way that it's not constrained.
So not only does each requirement have to be measurable, they all have to work together. It's a challenge, which I think often arises because people are not used to working in truly cross-functional teams. Traditionally, product marketing comes up with requirements, throws them over the wall to product development, and then product development throws the product specs over the wall to manufacturing, and then manufacturing says wait a minute, this process is weak. Why? Because it wasn't fully defined up front. You have to realize that at some point, someone will have to define how well you can actually fulfill the functional response, how capable one is of manufacturing the product, and then measuring whether it's on target statistically. If it's off, that will create a problem that causes customers to complain. That's why it's so important to work with a cross-functional team: everybody can work together from the outset and learn what capbility means for each part of the team.
DISCOVERIES: How has this played out at your company?
SCHARF: Our original pilot project had team members from product development, quality assurance, manufacturing who could say to each other, you need to ensure that I can create the capability you're asking for. Why do things need to be measurable? Because someone eventually has to build the thing and determine how well it works. Then the design scientists can understand that when they pass their design onto process development and manufacturing, it creates a measurable functional response. You can see the tie-in between the requirements and the deliverable.
That's what I work with teams to help them understand. To think about the totality, because it's not about checking off a box in a phase review -- it's about fulfilling customer's need with quality and value.
We're starting to see the changes I envisioned when I started to think about this. Parts of the company have really embraced VOC and I'm working with other parts of the organization. We still have our challenges....we don’t have a full head of steam yet, but we are starting to see the wheels really turn on the locomotive.
***
