Dealing with Change in Design Projects

CEOs consistently name innovation as one of their companies’ top priorities. But curiously, new-product innovation has been steadily declining over the past two decades.

Management probably wants more innovation but gets less of it because innovation means changes. These changes often crop up in the middle of design projects as engineers learn more about the application and technologies they are using. Changes typically lead to a dilemma: If engineers truly innovate with new products, they should expect change as the project proceeds, but experience tells them that changes lead to expensive rework, blown budgets, and schedule overruns. It’s time they and their managers discover that midproject changes need not be expensive, and you can innovate without paying a high price.

Change happens
Midproject change is actually more common than product engineers and managers like to admit. While interviewing product-development leaders, we asked them to identify specific examples of change during a development project. No one had any difficulty in recalling some. This confirms data from Donald Reinertsen, author of The Principles of Product Development Flow. He analyzed data from over a thousand design projects and not one had product requirements that remained stable over the course of the project.

This prevalence of change doesn’t fit with how engineers carry out design projects. Most use a “plan-your-work, work-your-plan” approach. This mind-set may be driven by a corporate focus on process management to eliminate waste and reduce cost or a by desire to replicate in R&D labs the advances won in the factory through lean manufacturing. For example, Marvin Patterson, author of Leading Product Innovation, says that without thorough planning, “This inevitably leads to scrapped engineering efforts, rework, and schedule delays.” The roots of this plan-well, avoid-change approach are deeply embedded in management thinking and corporate culture. An analysis of 13 marketing textbooks backs this up by revealing that product developers are trained to plan thoroughly before they act.

In short, midstream change is common and natural in innovation projects, but engineers and their managers have learned that such changes often have costly consequences. So they plan carefully and stick to the plan to avoid these consequences. Unfortunately, this path does not lead to successful innovation. But there is a middle path: Anticipate changes so you are ready for them when they happen. This makes changes less costly and fosters an environment where innovation can flourish.

A cue from software developers
Software developers have pioneered new methods of dealing with midstream change. Formerly, they used a so-called waterfall method, which was based on heavy up-front planning and strictly sticking to the plan to avoid rework. As the software world became more turbulent, however, this approach began to conflict with reality. Thus, over the past decade, software developers have embraced agile software development (see side bar), which uses an iterative approach to deal with change by relying on a make-a-little, try-a-little strategy. By continually testing design features on real customers, they avoid many of the big surprises that typically crop up toward the end of projects.

Unfortunately, agile development can only be applied directly to software because it depends on some unique characteristics of software, such as object technologies and the ability to automate testing. But agile provides a wonderful list of tips for other engineers on how to accommodate change:
• Identify uncertainties early and work to resolve them.
• Adopt a more iterative style.
• Try things out — experiment a little.
• Defer decisions in uncertain areas.
• Create and maintain options.
• Use product architecture to “fence off” areas likely to change.