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

The other is loose-tight planning in which you alternate periods of tight planning and control with more relaxed periods in which to regroup. This is what the iterative approach of agile software development does by delaying planning of features to be implemented until the beginning of an iteration and then planning only those features to be implemented in the next iteration. During an iteration, planning is tight, but between iterations all remaining work is reassessed. This is also how Boeing developed its 777 airliner by alternating periods of design with periods of stabilization (12).

Another part of project management you must handle differently under heavy change is risk management. Good practice under light change is to integrate the risk management process with the rest of the project management process so that risk management actions are identified, planned and executed methodically as part of the project plan. When change dominates the project, risk management instead must be intrinsic, that is, everything you do to manage the project is done to manage its risk: you keep close to customers to manage the risk of customer change, you fence in modules to manage the risk of pervasive design modification, and so forth.

Maintain Flexibility in Upper Layers of Process

Although the illustration suggests that the development process is not the place to devote improvement effort, there is nevertheless much you can do to make your development process more flexible. First, recognize that because a project has many dimensions, you may find that, in one project, you need flexibility in certain areas while you will need strict control and accountability in certain other areas. For instance, a project may have disastrous consequences if the product has defects but its essence may be to extend a new technology through market adaptation. Consequently, in this project you will need tight control over quality while your technology experimentation program should be open and extensive to provide flexibility. In the next project, these areas of control and openness may shift completely. Boehm and Turner show how to combine flexibility with tight control based on a project's specific needs (13).

Software developers have learned a useful lesson about building flexible development processes: standardize in the lower layers of process (13, p. 152). For example, standardize how you run a test, how you assess its results, and how you apply tolerances to a certain type of component. Then maintain flexibility by leaving freedom in the upper layers of your process, that is, in how you assemble the basic activities. We do this because the upper layers provide the flexibility while the lower layers provide the quality control.

Consider language as an analogous situation. We do not change the letters; there are exactly 26 in English. Words are mostly standardized, but new ones do arise or are borrowed from other languages: blog, biosphere and ciao. There are rules for constructing sentences, but many variations are acceptable too. Looser still are paragraphs, and almost anything goes in the document layer.