| ||||
The exchange of information is the lifeblood of product development. When an electronics company's circuit designers know what the casing designers are doing, they design a better-fitting circuit for the casing. And when the casing designers know what the circuit designers need, they design a casing where it's easier to put in a better circuit. Such flows of information allow for experimentation and innovation, and for that reason, many companies encourage feedback and iteration in their product development processes. This practice is known as concurrent engineering.
But excessive iteration can have drawbacks. A continual back-and-forth of work inevitably consumes time and resources. And many of the iterations may turn out to be only marginally beneficial or even wasteful. For example, at a telecommunications company that my colleagues and I advised, there were as many as 20 regular iterations among the teams working on two key technical specifications. The result was that few people worked carefully on specifications in the early stages, because everyone knew that extensive rework would occur down the line.
The lesson is clear. Iteration must be carefully planned and managed. Good iteration should be encouraged and bad iteration eliminated. To do that, managers need representational tools to help them identify and model iteration.
Unfortunately, the standard project-management tool kits such as Microsoft Project don't contain such tools. The most commonly used project-planning tools — principally PERT and CPM network diagrams — are graphic descriptions of task flows. In them, tasks are usually represented by boxes or circles, and sequencing is represented by arrows. In a complex project, a chart can run to tens or even hundreds of pages, and each page accommodates only so many readable circles and arrows. A boxes-and-arrows depiction of the design process for a car's suspension, for example, would run to more than 30 pages. If the project is made up of tasks that can be completed in sequence without fear of rework, manageable charts for small chunks of work can be generated.
 | |
| It is almost impossible for managers to comprehend … the complete organization of [a hundred-page chart] with a conventional project-management tool. | |
 |
But the tools become very hard to use if what happens on page 60 forces you to rework a task on page 18, and, thus, many of the subsequent tasks down to page 60 again. It is almost impossible for managers to comprehend, let alone change, the complete organization of such a process with a conventional project-management tool. In addition, by their nature, high-tech product development processes usually involve many interwoven tasks.
There is, however, a tool that managers can use to obtain a simple and meaningful representation of such complex processes. This tool, the Design Structure Matrix (DSM), differs fundamentally from conventional project-management tools in that it focuses on representing the information flows of a project rather than the work flows. As a result, it is better able to depict the key dynamic of innovation processes such as product development. What's more, it can often provide representations of complex development processes on a single page. In this article, we will explain how the DSM works and show how a manager can use it to make development processes more efficient.
· · · ·