presents
A
Practical Approach to New Product Development
Introduction
A new product begins when an opportunity is recognized and it is completed
when a need is successfully fulfilled. An invention must do much more that
just "work" to be successful. Creating a profitable product involves finding
a balance among many variables:
-
sales price vs. user benefits
-
supply vs. demand
-
sales methods vs. customer education
-
distribution networks vs. user support
-
growth vs. cash flow
-
timing vs. obsolescence
-
desired features vs. needed features
-
what's possible vs. what's practical
-
development budget vs. development schedule
-
production cost vs. tooling cost
-
production capacity vs. projected demand
These and several other factors, including safety, legal, regulatory, and
intellectual property issues, must be considered in a competitive environment.
Each factor can affect many others. The first part of the above list involves
marketing and commercial issues. The second part is more relevant to the
technical development of a product.
The Process
Technical development proceeds through phases which help list the questions,
gather the facts, find a balanced solution, and produce a working product.
These phases can be called:
Study > Definition > Concept > Proof-of-Concept > Design >
Build > Test > Use
Phases usually overlap and it is often necessary to go through several iterations
-- in other words, one must often "go back to the drawing board" after learning
that things won't work as envisioned. The key to a sensible strategy is to
identify, research, test and evaluate unknown technology. This will prove
the viability of high risk items and reduce the chance that an entire system
could fail because of a weak and untested link.
Defining the Project
-- the Design Control Specification
A Design Control Specification (DCS) is a document which describes
the opportunity, defines the problem to be solved, and states the requirements
of a system that will fill the need. It also documents previous attempts
at finding solutions. The DCS can be started during the Study phase, but
it is mostly developed during the Definition phase. As work progresses, the
DCS will also describe and rank concepts for new solutions. Before the final
Design phase can begin, the DCS must be complete and a solution must have
been selected.
The DCS also begins to outline the "Structured Systems" required to implement
one or more of the most promising concepts. In its simplest form, this can
be viewed as a parts list and assembly diagram. But, more completely, it
encompasses all of the tools, equipment, facilities and systems needed to
produce and support a product throughout its life cycle.
Planning the Project
-- the "Development Matrix"
Conventional planning and scheduling techniques are too cumbersome when exploring
new concepts. Discoveries can demand frequent changes to the scope and sequence
of work as product concepts are reconfigured. Updating schedules that detail
the sequence of work too far in advance can require more labor than doing
the work being planned. A simpler planning tool called a "Development
Matrix" can be a better aid for visualizing new product development in
the early stages.
Everything needed to produce a product must pass through each development
phase to some degree. A Development Matrix can be pictured as a grid. The
structure of the system under development is listed down the side -- for
example, the list of parts, components, and subassemblies needed to make
the product. All of the phases needed to develop them are listed across the
top of the grid. The project will be finished when each phase is completed
for every part and all the elements are integrated into a tested, working
system. Each square in the grid can be marked as it is completed.
Development Matrix
|
Study |
Define |
Concept |
Proof
of
Concept |
Design |
Build |
Test |
Use |
Press Machine |
X |
|
|
|
|
|
|
|
Frame |
X |
|
|
|
|
|
|
|
Wheel Assembly |
X |
X |
X |
X |
|
|
|
|
Wheel Plates |
|
|
|
|
|
|
|
|
Belts |
|
|
|
|
|
|
|
|
Hardware |
|
|
|
|
|
|
|
|
Hot-Block Assembly |
|
|
|
|
|
|
|
|
Heaters |
|
|
|
|
|
|
|
|
Hot-Block |
|
|
|
|
|
|
|
|
Insulation |
|
|
|
|
|
|
|
|
Feed Mechanism |
X |
|
|
|
|
|
|
|
Control Panel |
|
|
|
|
|
|
|
|
Guards |
|
|
|
|
|
|
|
|
Power Supply |
|
|
|
|
|
|
|
|
All the tooling, equipment, and facilities required to produce and assemble
a product could also be shown in a Development Matrix. Developmental stages
are often "nested" within one another. In other words, the completion and
use of an entire working model may be only one step in the Proof-of-Concept
testing for a higher stage of development.
Opinions of Cost and Schedule
-- Ballpark Budget "Guestimates"
Accurate estimates can be generated when there is a history of nearly identical
work as a basis. By definition, that is impossible for the invention of a
new product. Such an opinion of cost and schedule can only be an educated
guess. It should not be considered an estimate in the same sense as when
one gets an estimate for constructing a building. Opinions given early in
a project for design and development work could easily be off by a factor
of 3 or more. However, these items are usually not the dominant costs for
launching a new product.
A Development Matrix can be used to convey opinions of the magnitude of work
for each Part+Phase combination. A value is assigned to each square and then
shown as a graph. This highlights the impact of adding or eliminating elements
and simplifying phases.
Development Matrix with Work Load
|
Another function of a Development Matrix is to convey opinions of the risk
associated with each element. This can be viewed as the likelihood that something
cannot be made to function as hoped after applying the highest reasonable
level of resources envisioned.
As more unknowns are eliminated, the cost and schedule are brought into focus.
Tooling and production costs can be based on quotes from job shops or experience
with prototypes. The sequence of events can be detailed and subjected to
a "critical path" analysis. But, "plan no project before its time." Detailing
too much too soon makes a project plan appear more fixed and certain than
it actually is. This leads to wasting resources on work that no longer makes
sense.
Doing the Project
-- Tasks
A Task is an attempt to define work which will result in progress
while using no more time or resources than should be consumed between reviews.
The elements of the Development Matrix can be used to describe the work.
Selecting an appropriate sequence involves assessing which elements are most
crucial to the success of the overall project, the risk of failure for those
elements, and whether alternative solutions are available. This, combined
with opinions of the time and resources needed to complete each element help
formulate short-term plans.
Selecting which elements to do at each step requires considerable judgment
and experience. Identifying the risky, but easy to test concepts can produce
tremendous savings by finding problems early on.
The temptation to do the "easy to define" work first must be avoided. This
can provide a false sense of security and control as work is completed on
a fixed schedule and at a fixed price. However, the hard to define study
and exploration work is usually what exposes unforeseen issues which result
in major changes to the overall project. It is often necessary to review
the understanding of the opportunity and refine the definition of the problem
to be solved.
Controlling the Project
-- Tracking and Reviews
Periodically tracking expenditures and progress helps avoid surprises for
each task. It is common for Tasks to vary considerably from the plan. Some
tasks are easier than expected and others are harder. These peaks and valleys
often average out over a project. Even so, it is best to know when a task
looks like it will take considerably more resources than planned. This could
be a reason to have a mid-task review to decide whether to continue or to
take a different approach.
A review should be conducted as each task is completed. Included in the review
should be updates and changes to the Design Control Specification and the
Development Matrix based on what has been learned. Subsequent tasks are selected
for consideration. The depth of a review should be in proportion to the resources
planned for the next step. In other words, look extra hard before you leap
if it's a big jump.
Conclusion
-- Exploring
Researching a new product idea is like finding your way through unexplored
territory. Explorers often don't know where they'll end up or how they'll
get there. You may believe that there's a promising destination off in the
distance, but you don't know how far until you climb above the trees and
survey the forest. Scouting various paths helps map the area. You may even
be shocked to find evidence that others have preceded you. There are several
possible paths. Some look easy, but may lead to a dead end. You could go
in circles or have to back track.
However, if you have a good compass and enough supplies to survive the journey,
you might make it. You may be surprised to find a destination that is different,
and maybe even better, than the one you planned.
An experienced explorer can help even if they've never been where you hope
to go. No one can tell you exactly how to get where you want to go or how
long it will take. But, their survival training and experience with similar
expeditions may provide much needed guidance through rough terrain. Pack
plenty of provisions, but use them wisely. |