Your Reliability Engineering Professional Development Site
Think of the “wasted energy” involved with products that require rework, redesigns, or fail to meet customer needs. In addition, a great deal of time and effort is often put into products after they have been developed to make them more profitable.
The goal of this article series is to help organizations proactively focus on maximizing customer value of products, and minimizing cost of operations during the product development process. Readers will also improve their understanding of problem solving and process improvement tools and methodologies. Some articles will provide high-level perspective while others will deep-dive into specifics.
While product development is not always perfect, companies can emphasize teamwork, establish a framework for innovation & problem solving, and eliminate waste. Meanwhile, employees can develop transferable, marketable skillsets with their knowledge of problem solving tools and methodologies. This article series will also help contribute to these objectives.
Sign up for the “Product Development and Process Improvement” email list to receive weekly articles.
[display_form id=38]
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: