Hi, welcome to Quality during Design, for products, others love for less. This is where we talk about quality and reliability engineering concepts and how it fits into product development and design engineering. Today, instead of talking about a particular tool or technique, we're going to take a look at the big picture, namely quality as a strategic asset to new product development versus quality as just a control.
There are some known cornerstones of quality and reliability engineering. They both use risk-based thinking, where we identify ways to control risk, either with detection or prevention controls. They both are intentional with data, whereas what are we going to be collecting? What kind of data? When are we collecting it? And why? What is the answer that we're trying to get out of collecting the data? They both bring it back to people, both internal and external customers. And there's an understanding of variation and how we need to control it.
New product development processes pose their own challenges. Sometimes in typical design development, we usually don't spend a lot of time or effort in developing the concept before engineering development begins. In fact, we start engineering development right after the first iteration of concepts, and it's natural! It's the way engineers think. We also deal with unexpected design failures that can lead to a redo of the concepts themselves, mid development. This leads to a lot of frustration and a lot of effort at the end of the development cycle. We're fighting fires through project end. When I speak with my quality and reliability engineering friends, this is a common theme and a common source of frustration for them. "I wish they had involved me earlier," is what the quality and reliability engineers say about new product development.
We can and are allowed to change how we do things. We can put more effort up-front in concept development before engineering design begins. Early failures, prompt, design improvements, not concept changes. Steady development through engineering and test means easier planning and more consistent activities: reduced firefighting.
There are a lot of benefits to an improved early development: more effort, and more time spent in concept development. Academic people have studied it and they show that projects are at least three times as likely to succeed with "sharp fact-based product definitions before development begins". They're twice more successful if the team does "solid, upfront homework - doing the front end activities well." These activities are also associated with increased market shares, which also leads to improved profitability. Cross-functional teams that are empowered, resourced and accountable affects the new product development process and strategy. It increases performance dimensions.
Just the matter of improving the design quality itself has benefits. There's a higher perceived value with our customers, which leads to more money that we can charge for it, and higher profitability. An improved design quality also means that there's an improved quality and conformance in how it's made, which reduces manufacturing and source and component costs, which also increases profitability.
What's the biggest difference between what many of us experience in new product development versus the ideal state? The biggest difference is that there is more cross-functional team effort and time in concept development before engineering design.
There are many deliverables at concept that contribute to the user needs and design inputs, which affect the design itself. Those that have a closer relationship to the customer, and even the customers themselves, are more empowered during the development process. And we can also plan tests to discover and eliminate or reduce design failures early.
I'm not saying that we should brainstorm novel and innovative ideas within a group setting. There are other studies that say that innovation is best done with a small group or even individuals. But I am saying that there is a lot of concept development work that can and should be done before we start engineering solutions. And this is where we can think of quality as a strategic asset for new product development processes.
Only 24% of our organizations view quality as a strategic asset for a competitive advantage over other companies doing the same kind of things. The rest of us see quality as a compliance activity or for a continuous improvement, or as just a way to fix problems and mitigate risks.
We need to shift our thinking! Quality and reliability engineering is a strategic asset for product development processes, and we need to proactively use it to help us improve the development process. We can use it to add more concept development and provide information to help us make decisions. Quality engineering and reliability engineering methods effectively prune the development process by helping teams uncover ideas and make decisions with data, use risk-based thinking, and consistently keeping the voice of the customer at the forefront. The team can cut off the development of ideas and development paths that are not going to contribute to a product that is safe, usable, and dependable, which allows us to focus our efforts and resources on getting the product that fits: the fruit of our labor that is the best we could produce.
The framework to use quality as a strategic asset is P.R.U.N.E.:
- people-focused
- risk-based thinking
- uncover ideas
- navigate decisions
- empower teams
By their very nature, quality and reliability engineering methods are people focused and risk-based - it's part of the cornerstones of their disciplines. But how can they help with early concept development and help with ideas, decisions, and teamwork.
It's important for you as design engineers to search out information from your cross-functional to team, to uncover ideas. This needs to be a proactive thing. You make decisions daily about the product that affects all aspects downstream from manufacturing to distribution, to the users, to disposal. Not asking and working with the cross-function team is a missed opportunity.
I've worked in situations where user information was developed by a group of people and experts over here. Then it was thrown over the wall for the design engineers to interpret into something technical. I also talked with a prominent usability experience expert and asked him what his experiences were with working with design engineers. And his answer was that he typically didn't work with the design engineers. He worked with a project manager who then disseminated his summaries and information to the design engineers to interpret. This is dangerous because it leaves things open to interpretation and information gets lost in translation. We want to remove the buffers between us and either the customers or the people on our cross-functional team that work most with the customers. We don't want to lose information in translation. And even if they're available to ask questions, we don't always know what to ask if we don't work with them.
We can use quality to facilitate ideas with our cross-functional team members. Quality frameworks can help with structured conversation. These conversations could be exploratory, or they could have specific goals or outputs. Team built graphical tools like flow charts, SIPOC, and fish, bone diagrams get everyone on the same page and help teams explore ideas and details. FMEA (or failure mode effects analysis), 5-whys, and tree diagrams help to get to the root of potential issues.
Early concept work includes usability engineering, including the users, their environment, and the big-picture steps of how to use the product. We haven't designed the product, yet. We're only thinking about a concept, but there's still a lot of usability engineering information that we can use to help drive the design. Technical assessments are performed early in the concept work, and they include early reliability engineering concepts and Designfor Excellence concepts. Risk management can be performed with just a concept: use overarching evaluation of the risk associated with the full system. This would get information for us to be able to make risk-based decisions. With all of these, the focus is on the customer and what they need. These are the types of information that we should have before we even start engineering drawings. Analyzing this with our team early helps us to uncover the design ideas that, in the end, will help us make the best design choices that we can.
Quality Engineering and reliability engineering methods are also used to help us navigate decisions about the concept and the design iterations. These methods can be themselves iterative, starting with what the team may know and further developing as the team learns more about the use case and design concept. Quality and reliability engineering methods can help us turn qualitative ideas into quantitative rankings of priority numbers that we can make decisions against. They can help us identify gaps in understanding between our customers and engineering. We can evaluate the usability of our concept by using quality methods that have been used in manufacturing processes for years. And other tools like accelerated life testing and failure mode and effects analysis can be used by the team to develop concepts and requirements that are controlled by the product design itself.
Designing-out issues and designing-in features that our customers will love is most easily done at the concept phase before we started building or creating anything. A lot of the iterative and early concept evaluations can us determine what those ideas should be before prototyping. Even before that, before you start engineering solutions, stop and facilitate some discussions with your greater cross-functional team, your customers, and those that are closest to working with your customers. Remove that barrier and speak directly with them. If you can, use quality and reliability methods to facilitate those meetings. Work with them and start a dialogue to open ideas for more questions for better designs. And, begin talking about the bad things that happen so you can design-out issues.
You may not know where to start. You can use some quality engineering tools as frameworks to help get the dialogue started. Create a process flow of your user's process and see if you understand gaps. Or notice where you can redesign or develop a different concept idea that would eliminate some of those bad things from happening. You can also reach out to a quality engineer or reliability engineer for help. You can also reach out to me. Visit qualityduringdesign.com and subscribe.
Let's prune the development process. Let's use quality as a strategic asset to product development and go from the old way of doing things to a better way so we get better success.
