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.

Three fallacies about change
Designers’ apparent rigidity about careful planning and sticking to the plan seems to stem from fears of what might happen if they stray from the plan.

Here are three fallacies that lead engineers to fear change.

Fallacy #1: Flexibility is expensive.

Engineers and their managers believe midproject change is expensive because they have seen changes lead to project delays and budget overruns. They attribute those delays and overruns to the cost of being flexible and open to change. But you can reduce the cost of being flexible by preparing for changes rather than treating them as surprises and dealing with them as they arise. For example, the cost of flexibility in the bike-hub example (see The Case of the Bicycle-hub Design Project) was only $5,000 for prototypes. The $70,000 squandered on the wrong design was actually cost of inflexibility, of ignoring uncertainty and failing to seek better information.

Insurance provides a useful analogy. When it comes to fire insurance on your house, you have two options. One is to be careful with fire, assume the odds of a fire are negligible, and be willing to assume the full cost of replacing your house if it burns down. The other option is to pay an insurance premium up front each year. Then, if your house burns down, your cost is much lower. Similarly, if you take the time and pay for exploring uncertainties up front during a design project, the project won’t come off the rails when it’s bushwhacked by an “unforeseen” change, which leads to major schedule slips and budget overruns.

Fallacy #2: Flexibility makes projects unpredictable.

Product designers seem to believe that flexibility is a wild card that injects unpredictably into their projects. Following this logic, they try to improve predictability by planning out all the details and then slavishly following the plan. This works well if the market and technology are stable and little is apt to change. But if change is likely, the plan becomes brittle, and trying to follow it leads directly to unpredictability.

The bicycle-hub example shows that maintaining options, a form of flexibility, actually improves project predictability. While the original plan led to a $70,000 budget overrun and a schedule slip of two months, the flexible plan caused no schedule slip and a small $5,000 bump to the baseline budget.

Think of it this way. If you have a single design path and follow it rigidly, you will likely be surprised greatly by any deviation. You may be faced with either starting over or turning out a design that doesn’t satisfy the market. With flexibility, you open alternative intermediate paths. Then, if the original one fails, you have palatable backups. This broader choice of options improves predictability rather than decreasing it.

Fallacy #3: Flexibility delays market launch.

Another common belief is that starting a project before all details are pinned down leads to wasted effort when the design changes. Here’s a real-world example of this fallacy at work.

A design team was developing a communication device in an industry where compatibility standards were still evolving. After wasting time chasing standards that proved to be moving targets, management put the project on hold. However, a competitor beat the company to market by following the evolution of the standards more wisely. The key, in this case, was to use product architecture to isolate, or “fence off,” the small portion of the design affected by the standards and proceed with the rest. Then, when standards were finalized, the competitor already had most of the design completed and could finish it in time for a quick market launch.

In short, flux in industry standards delayed the competitor’s project but not as thoroughly as it did the inflexible project. Furthermore, the competitor did not waste design resources by continually revising the part of the design subject to evolving standards.

The technique used by the competitor was to identify the gating event (stable standards in this case) and work around it by proceeding with activities that were certain. In this case, the critical time-to-market clock started when the standards were finalized, not when the team started its development.

Focusing on stable features before design standards or other features are firm can accelerate product launch.

What you can do

The first step, of course, is to assume something will change. Then take these steps to take to make projects more change-friendly:
• Move beyond fixed schedules and frozen requirements. Early on, identify areas likely to change and explore options.
• Keep in touch with customers. They are always receiving new information and might change their minds regarding your design.
• If a project relies on emerging technology, keep up to date with changes in that field.
• Encourage, don’t just tolerate, experimentation to explore alternatives both up front and during the project.
• Let development teams make more decisions themselves. They have the freshest information, and waiting for gate meetings is simply too slow.
• Align performance metrics with the chaotic world. Reward people for the quality of their midproject decisions, not for merely sticking to a plan.

Postproject assessments are also critical for reinforcing the idea that changes can be good and don’t always stem from poor planning. For example, to reduce reliance on a frozen plan, assess whether a surprise was due to poor planning or to new information that arose after the planning phase. And outline what could have been done to obtain this information before it became a surprise. Finally, assess the opportunity cost of changes not made. Those who steadfastly follow their plans ignore what it cost to avoid a change. The cost of a lost market can far exceed the cost of making a change.

© 2011 Penton Media, Inc.