Let’s start by understanding the difference between engineers and engineering designers.
The work we do as reliability engineers may require a different approach when working with these different types of engineers.
Jack Howe, an architect and engineering designer, has said:
I believe in intuition. I think that’s the difference between a designer and an engineer … I make a distinction between engineers, and engineering designers …. An engineering designer is just as creative as any other sort of designer. Pg. 20.
Richard Stevens, an industrial designer, has said:
A lot of engineering design is intuitive, based on subjective thinking. But an engineer is unhappy doing this. An engineer wants to test: test and measure. He’s been brought up this way and he’s unhappy if he can’t prove something. Whereas an industrial designer — is entirely happy making judgements which are intuitive. Pg. 20.
These quotes are from the book Engineering Design Methods: Strategies for Product Design, 3rd Edition, Wiley 2000 by Nigel Cross in Chapter 2 Design Ability. [note: I believe there is a 4th edition available now] Nigel explores the different ways designers and engineers approach and solve problems. He cites a number of studies, yet in summary, it appears there are two prevalent approaches.
Engineers and scientists tend to systematically work to understand the problem. Based on this understanding then identify underlying rules and thus create an optimum solution. On the other hand, designers tend to initially explore the problem and propose a variety of possible solutions. They then work to find a solution that is satisfactory.
Cross sums up with:
The evidence from the experiments suggests that scientists problem-solve by analysis, whereas designers problems-solve by synthesis; scientist use ‘problem-focused strategies’ and designers use ‘solution-focused strategies’. Pg 22.
What we do as reliability engineers is the problem analysis (root cause analysis), search for underlying rules (physics of failure modeling) and find an optimum solution. We are solving the problem and hopefully an entire class of problems.
On the other hand, the design engineers we often work with during product or system development are solving a different type of problem. They are focused on providing a viable solution to deliver functionality within a bewildering array of constraints.
Elements of a Successful Designer
Cross explores how one learns to become a successful engineering designer.
Our (reliability professionals) understanding of what makes a successful designer, and thus fosters successful product and system designs permit us to support and encourage the designer and the process. The approaches that we use to solve problems is not, in general, the same approach the design team will employ.
By recognizing the difference is approaches and tailoring our support, advice, and influence efforts to fit within the design teams approach, we have an increased ability to improve the reliability performance of the product or system. By working in concert with the design process we support and encourage the design teams problem-solving approach.
Let’s explore six behaviors of successful designers and who we can support that behavior with our reliability engineering role.
1. Clarify requirements by asking sets of related questions that focus on the problem structure.
Setting reliability goals connected to business objectives and based on customer requirements or expectations is our role here. Early reliability models that lay out a framework to define the reliability requirements may enhance the requirements setting process.
Mission profiles, day in the life descriptions, and types of perils or risks are additional ways to clarify requirements.
2. Search for information actively while critically checking given requirements.
As the problem to solve become clear the design team may alter the boundaries of the problem. They may change requirements as they learn about the problem and gather information. We often can supply the environmental and use conditions, from weather data to ergonomic forces.
Plus, we can supply the information related to risks to product performance —from potential failure modes to underlying failure mechanisms.
3. Summarize available information concerning the problem formulation into requirements and begin prioritization.
This is a refinement of the requirements. In short, the requirements take time to evolve.
The reliability related requirements may also change. The understanding of the market, possible solutions, business priorities, all may impact the evolution of the reliability requirements.
4. Hold and consider initial ideas for a solution, then further clarify the problem (an iterative approach of ideas to solve the problem as a means to understand the problem better).
Not every design idea is either good or bad, each is a step closer to understanding the problem well enough to find a design solution.
As reliability engineers, we almost always examine a design with an eye toward how it can fail. This has value, yet the design team is looking for ways to understand the design problem, not how this variant will not work. Therefore, if we work to identify what elements of an idea are reliable and which are not, and why, we are providing information instead of only criticism.
We don’t need life models and test plans at this point, instead an overview of the reliability performance posture.
5. Not fixated on early possible solutions during the conceptual design stage.
Just as a successful designer will quickly let go of an unworkable early design idea, we have to avoid fixating on potential problems in design concepts that are still under evaluation.
Our voice is one of many contributing to the design process. Our support is in the framing of requirements, assisting in understanding how a particular design may or may not meet the requirements. Solid information based on quick experiment, proofs of concept, and simulations allow the design to evolve, instead of finding only a disapproving reliability engineer at the end of the table.
6. Periodically assess and evaluate possible solutions or variants, created in limited numbers, in order to reduce the number of variants.
Early in the design process, there will be mock-ups, rough prototypes, breadboards, and functional models.
While we understanding finding and fixing reliability issues early in a program is valuable, we often have to hold back from the design verification activities until a design solution takes final shape (or at least close enough to final shape).
The early variants may provide clues to the types of reliability issues that may occur with the final solution. Keep note of defects, anomalies, and outright failures as if the related particular elements make their way into the final design, the associated problems may as well.
Designing a product is a difficult task and requires a unique problem-solving approach to finding viable solutions. We support or hinder the process as reliability engineers every step of the way from defining the problem to vetting potential solutions to verifying final designs.
By understanding the process and what makes for a successful design process, allows us to work well with our design team early in the process.
Related:
Descriptive Models of the Design Process (article)
5 books for a professional reliability engineer (article)
CRE in Application (article)
Leave a Reply