Designs change. Deal with it!

Study after study shows that while CEOs espouse the importance of innovation, their companies are turning away from significant new product innovations in favor of simple product renovations.  I think one important cause of this split personality is that companies don’t have a good way to deal with mid-project changes.  They avoid changes by favoring simple product extensions in stable, well-known markets.

These companies would be better off to realize that change is an inevitable part of product innovation–It’s just not realistic to expect project planners to know everything about an opportunity before they start development.

An article Preston Smith and I wrote about this dilemma was published in the March 17, 2011 issue of Machine Design.  You can read it on my website here.  We discuss how change is the rule, not the exception, for product innovation.

Three prevailing fallacies about the cost of project flexibility may be hobbling developers with outdated development processes that can’t deal with mid-project changes:

  • The first fallacy is that flexibility is prohibitively expensive.  It doesn’t have to be.  Recognizing and preparing for uncertainties eliminates most of the typical cost of change.
  • The second fallacy is that flexibility makes projects unpredictable.  In fact it’s rigid planning that drives up budget and schedule variance when change is forced on a project.
  • The third fallacy is that development flexibility delays a product’s market launch.  The article gives an example of how flexibility speeds market launch by allowing developers to start work before requirements are completely stable.

In short, project flexibility has gotten a bum rap.  You need to change and adapt to what you learn in the middle of a project, and new flexible development tools give developers what they need to deal effectively with changes.

One Response to “Designs change. Deal with it!”

  1. In private emails, a senior electronics designer commented on the article, saying that, despite statements to the contrary, Agile Software practices can be applied to hardware design by using programmable components, such as FPGA, DSP, or SoS chips. Such components easily tolerate late changes without adding any significant cost.

    This remark is quite right. When cost and performance goals permit their use, programmable components are a good way to “fence in” uncertainties that might otherwise drive costly change late in a project.

    However, most hardware products include important elements that can’t be realized with programmable chips. These may be mechanical components or elements that require performance not available in a programmable chip. In these cases, the techniques described in the article can be used to deal with mid-project design changes.