Change: embrace it, don't deny it: tools and techniques inspired by software development can introduce the flexibility needed to make changes during product development with minimal disruption

Research-Technology Management, July-August, 2008 by Preston G. Smith

Experimentation takes many forms. It includes: building prototypes, mock-ups and breadboards; testing these; running simulations and building models; and overloading a system to see what fails first (a smoke test). The savvy experimenter looks for experiments that will return as much information and insight as possible for the investment in money and time. This cost-benefit equation has shifted enormously in recent years as computer-aided technologies have greatly reduced the cost of experimentation in many fields, such as exploring molecules in pharmaceutical development, building physical models of mechanical parts for customers to touch, and automating the testing of software and hardware.

Such computerized technologies permit experimenting prolifically at reasonable cost. Many managers employ these computerized tools to cut cost and simply pocket the savings, but Orion, a Massachusetts sensor technology firm, used computerized prototyping in a hand-held surgical laser project to explore seven times more design options than it would normally have while keeping its prototyping budget to only two-thirds of the previous amount (3, pp. 98-100). This gave Orion much more flexibility to find a comfortable, easy-to-use design.

Again, experiments cost money and consume time, so seasoned experimenters seek areas where change is likely and concentrate their experimentation there. Other trade-offs are involved. One is in deciding whether to run several experiments, in parallel (faster) or sequentially (usually cheaper). There are guidelines for making such choices, such as the amount of learning you can apply from one generation of experiments to the next and how cleanly structured you expect the design space to be (3, pp. 102-104).

Explore the Design Space

Experimentation is a good tool for exploring options, but we also need a strategy for applying it, that is, for knowing which experiments to run. Toyota has an excellent strategy, called set-based design, that amounts to a very different way of approaching design.

To illustrate the difference, I contrast the set-based approach with the more normal point-based one by using a non-product-development example attributable to Ward et al. (10). Suppose that you wish to convene a meeting. The traditional way of doing this (point-based) would be for the convener to contact a participant and negotiate a mutually acceptable time. Then the convener proceeds to the second participant, doing the same and perhaps returning to the first participant to renegotiate. This repeats with the other participants.

The set-based approach would be for the convener to request all participants' calendars first. Then the convener (today using modern meeting-scheduling software), looks for a common open time (the intersection of individuals' available times) and sets a time where everyone is free. This not only saves time, but more important, it exposes all possible solutions so that, should something change, the convener is in a strong position to make adjustments easily.