Your Reliability Engineering Professional Development Site
Quality during Design is the place for product designers to use quality thinking throughout the design process to create products others love, for less.
Sometimes we need to gather with our team and come up with some ideas, whether we’re looking for new product ideas, trying to discover possible solutions, or we need to improve a service.
Gathering a team to come up with ideas is common. What are some of the ways we approach this activity? We talk about systematic and structured methods and new approaches to brainstorming.
As engineers, we need to write reports all the time.
Are ours getting returned by reviewers frequently?
Or are we not getting any feedback and are not sure when our report is ‘done’?
We explore the spirits of technical writing past, present, and future – they help us to write for ALL of our audiences. We explore how and why in the episode.
What are the gifts others bring to new product development?
It takes intentional actions and acknowledgement to understand how to bring design inputs into our designs from other people.
We consider project teams like a neighborhood and how this frame of mind can help our designs.
During product development, we’re consistently looking for ways to learn more about the product in order to make design decisions. Some of that comes from test.
What do we do when our test results are…surprising?
We talk about some next steps I typically take when tasked with surprises.
We have a reliability target for our system. But we’re not meeting it.
To avoid this scenario, what is something we can do in early development?
When we’re figuring out our concept, we can better learn about our options. We can work with Reliability Engineers to understand what we know, the risk in what we don’t know, and to prioritize reliability of the modules to be able to meet the reliability of our whole system.
We talk about using reliability allocation to help us choose reliability goals for modules of our product design. And we talk about its limitations.
New product development projects are really exciting at the start.
Even though we know very little about what the final product is going to look like, we can still use a quick graphical tool to help us direct our engineering attention.
We talk about ways to use a very simple System Architecture Diagram to help us get started and ways we can continue to iterate on it throughout development to help us communicate and make decisions.
During the product development process, are there so many design prototypes but the team’s still not getting buy-in?
Are design concepts changing mid-development after it’s “too late” to change the design?
Are designs picked-apart only after they’re nearly done?
Late in development, are there many fires to fight with too many surprises at test?
Quality during Design is not about compliance activities. It’s about being proactive with our team in early development. And knowing how to have conversations that gets us what we need so we can engineer designs.
We explore why Quality can help us PRUNE the development process just by the nature of how it’s used.
And we highlight the 3 areas that we focus on in Quality during Design: risk-based decisions, quality and reliability engineering partnership, and the user’s process.
Where do we sometimes need to look for inspiration? Books!
We talk about 11 books in 5 different topics that are useful for different perspectives on engineering and design topics.
And I tell you what I’m most looking forward to reading next.
What book recommendations do you have for me? Please add them to the comments, below.
What is engineering in the color economy?
We explore facets of sustainable economic models: Green, Blue, Yellow, and Orange.
Where do you fit in now? Where would you like to be? And how can you make design choices within each (or all!) of these color economies?
What makes a great design?
It depends.
We talk about the spectrum of designs (from great to spam), the various customers engineers need to design for, and how engineers can work with their team toward defining what a great design should be.
We worked on a project with our team and met our goal!
Except, management isn’t happy – they expected something else.
Seeing if we have alignment on goals is easy if we gather the team and stakeholders for 10 minutes and use a continuum.
There are certain categories that goals will fall within. A continuum is a way we can list those categories, get alignment, and gain an understanding of how ‘big’ of a project this is going to be. We get clarity on our goals.
Is it hard? Not at all. Is it eye-opening? Sometimes. It can help us move forward with a discussion to help ensure we’re all successful.
Relationships matter! And they can be difficult to understand.
We’re taking relationships between variables. Does one variable affect another? Or do they just correlate? Understanding which matters to the values of our decisions.
We talk about the saying “Correlation does not imply causation”, how to find a confounding variable, and ways to check that we’ve got the triggering cause that’s going to affect our outcome.
Meetings to ADD productivity to our day? Yes!
We need our time to be productive, individually.
We also need input from our team. We can use meetings to add productivity to our day, if done right.
We break it down: hours in a day, limits of humans, and the minimum requirements of a good meeting.
We have test results but realize that testing didn’t go as planned.
What can we do to help prevent this scenario?
We talk about ways to partner with test engineers and test technicians and the importance of still maintaining their independence.
I’ve mentioned in previous episodes that it’s best to do FMEA early in the design concept phases of development.
Well, if we do FMEA early, then what can with do with it?
We explore a bit how to study any risk analyses (system risks, FMEA, hazard analysis) to help design-out problems, set-up design inputs, and help us figure out test methods. We also talk a bit about why a team is a necessary part of risk analyses.
