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

As you can see from this example, set-based design is a subtractive process; it employs logical intersections. You define the initial feasible space and proceed to impose constraints, for instance constraints on the design due to manufacturability, cost, weight, or physics. Each constraint reduces the feasible design space methodically. You thus maintain a space of feasible designs so that you can turn to another point in the space if a change renders the current design point unsatisfactory. In short, it is a continual pruning process.

[GRAPHIC OMITTED]

This subtractive process and the design space it maintains are quite different from the normal design process that proceeds with one (or at most a few discrete) design that the designer hones to a final point. With such point-based design, if something changes, the designer has no information on adjacent designs and must usually retrace many steps. The set-based designer can merely shift to another place in the current design space.

Build Strong Teams

You have probably read much about strong development teams and have made improvements in your teams accordingly. Nevertheless, there is much we can learn from software development about the value of strong teams and how we might build them. For a starter, the initial statement of the Agile Manifesto is "Individuals and interactions over processes and tools.... That is, while there is value in the items on the right, we value the items on the left more."

In building a model to estimate the time and effort needed to develop a piece of software, software methodology researcher Barry Boehm identified 22 multipliers on project labor cost and collected data for these multipliers over a broad range of development projects (11). I have grouped these multipliers into categories in the illustration below. Thus, the labor cost multipliers associated with the people assigned to the project combine to produce a possible range of 33 to 1 in project labor cost, the multipliers associated with the product being developed span a range of 10 to 1, and so forth.

This illustration suggests strongly that the factors associated with people far outweigh the others, so devoting effort toward improving how the team works is likely to pay far bigger dividends than investments anywhere else. This stands in contrast to the great attention and investment that firms usually devote to processes, methodologies and tools.

New data from Don Reinertsen, Gary Olson, Judith Olson, and the agile software development community show that co-location is a powerful factor in improving team performance (3, pp. 142-146). This is disturbing news in an era in which globalization and "virtualization" are pushing teams away from co-location. However, there is much you can do to obtain many of the benefits of co-location even if your team is not completely co-located. These include co-locating all members in each metropolitan area and establishing norms for using tools like e-mail--for instance, a rule that any team e-mail must be answered within four hours.