O'CTS Logo
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
Development Matrix with Workload

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.

site design & maintenance by The SiteCafe

Copyright © 1999 O'Connor Technical Systems