Your Reliability Engineering Professional Development Site
This article series will help guide organizations in optimizing the value of products being developed, while minimizing both development and operational costs.
Consider the “wasted energy” during product development on products that don’t meet customer needs or product requirements. Multiple prototypes, rework and redesigns are often needed, and substantial time and effort is typically invested post-development to reduce product costs.
These articles aim to address this problem by enhancing readers' understanding of product development, project management and process improvement tools and methodologies.
With these disciplines, company culture and competitiveness can be significantly improved by leveraging skilled, efficient teams and collaborative problem-solving.
Sign up for the “Product Development and Process Improvement” email list to receive weekly articles.
Lean product development might mean different things to different organizations, but let’s start with the 5 principles of lean manufacturing and see how it can be applied to the product development process. [Read more…]
One of several reasons for emphasizing product requirements includes enabling modeling and simulations of designs, as well as ensuring adequate verification and validation testing.
Recall the fundamental framing of a requirement as:
Note the framing (within the requirement) of a mathematical and/or experimental relationship where “Y” is the output as a function of “(x)” as the input….Y = f(x) or as a function of multiple inputs Y = f (x1, x2, x3…xn). Let’s expand on this for a moment:
While previous articles focused on requirements writing, another element of products requirements is design constraints.
A design constraint might not be a requirement in the purest sense, but must be accommodated in product requirements (and, ideally, identified as such). Design constraints almost always make their way into product requirements.
Let’s use a simple example whereby a specific housing material is specified (a polyester thermoplastic elastomer).
The requirement might simply be: “The housing material shall be made of a polyester thermoplastic elastomer”. The PRD is then provided to the designer, essentially telling him he must use this material.
Managing requirements for complex systems can be challenging, however, establishing a hierarchical framework of key questions (answered at each layer of the hierarchy) can be quite helpful.
While some regulatory authorities (such as the FAA) may require various layers of documentation and traceability, this article isn’t necessarily advocating a bureaucratic development process. The process can be scaled based on the complexity of your system, your ability to model it’s (system) design performance and/or based on the amount of product development risk the organization is willing to assume. [Read more…]
In this article we’ll explore the topic of requirements, and attitudes about identifying requirements before the design work begins.
In my experience, I’ve had design resources literally state “I hope there are no requirements”. (Unconstrained design and no requirements certainly made this designer’s job much easier.)
There are several other reasons requirements are sometimes neglected:
In recent articles I focused on a ‘linear’ approach to product development by understanding customer needs, establishing requirements (“what the design provides”), establishing a conceptual design, etc.
In this article, I’ll discuss a framework whereby an idea for a product or design might kick-off the process.
Also, rather than a commercialized product, we will assume our goal is to successfully demonstrate the idea’s feasibility. (This is common for a start-up company, where the business model might be to demonstrate product success with a goal of obtaining more venture capital, or to sell the intellectual property. Alternatively, a large company might want a separate idea development process that takes invention off the critical path.)
Significant savings in product development costs can be realized with robust validation processes, starting with requirements validation. Validation confirms the product meets customer needs for the products intended use, and answers the question “are we designing the right product?” The “right product” therefore starts with the “right” product requirements. Even a product designed with detailed requirements, but incorrect specification limits, can be considered the “wrong product” (since the product would be rejected by the customer.) [Read more…]
Quality Function Deployment (QFD) is an excellent tool to ensure linkage of customer needs to product requirements. This article will provide a high-level overview on creating a ‘first-level’ QFD and how it can be used to guide design optimization.
(There are many additional features of QFD , however, and readers of this article are encouraged to research the methodology further.)
As stated above, we use the QFD matrix (similar to a cause-effect matrix) to ensure linkage of customer needs to product requirements using the critical thinking / questions as follows: [Read more…]
In recent articles I framed the structure of a market analysis to ensure we understand customer needs and value, product requirements are “the what” the design provides (to ensure customer needs are met); the design is “the how” the product requirements will be met.
Product requirements are determined by answering the following question: “What shall the (product) design provide (output) @ input conditions? (Input conditions are functional inputs provided by the user, or environmental conditions.)
A complex product may have several outputs that interface with a system, however, and/or several inputs may be needed in order to enable the product to perform it’s intended function. System integration is therefore required.
Let’s assume your product is a subsystem. The questions become:
How do we establish optimum system performance? We would expect the customer (system designer) would model system performance and provide functional inputs, outputs and specification limits (for your subsystem) in order to achieve optimum system performance.
Accordingly, subsystem integrators should understand system performance well-enough to help system designers with overall system design optimization…at the very least, understand gaps in requirements and associated system/subsystem development risks. The subsystem requirements document therefore is a key deliverable, reviewed in detail and approved by the customer.
An integrated approach to ensuring customer needs and value should be embedded in the product life cycle process, and can save your company (and your customers) millions of dollars in product development costs.
Wouldn’t it be great if we could require the stock market to provide us 15% increases in our portfolio every year…or if we could simply require a sunny day for a picnic?
You might be familiar with the term ‘market requirements’ or a ‘market requirements document’ as a deliverable in the definition phase of a product life cycle process. To understand why market requirements don’t really exist, we must first provide the definition of a requirement. [Read more…]
Given our primary goal of developing a profitable product, our objective in the design process is to maximize customer value and minimize cost. From a financial analysis standpoint: we pursue products with the highest possible margins (ie. charge the customer “as much” as possible, and make the product for “as little” as possible). Of course we also want to sell “as many” as possible. [Read more…]
A generally accepted principle for a successful business is great people, processes & products. This can be further simplified as “maximizing customer value and minimizing cost” of the product.
Consider the following:
