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

Change from plans during a new-product development project is a topic that increasingly places developers and their managers in a dilemma. On the one hand, change is becoming increasingly commonplace. Customers, who are presented with more and more options today and can turn to the Internet for competitive product information, change their minds more frequently and are more insistent on being satisfied. Such changes by customers put pressure on development programs to make changes accordingly.

In addition, markets shift more often and abruptly as the competitive arena becomes more turbulent and complex. For example, as globalization "flattens" the Earth, competitors appear from unexpected places, and they often bring with them new, disruptive business models. For example, Huawei appeared from nowhere in China to become a major threat to telecommunications equipment giants such as Cisco and Alcatel-Lucent, and Haier likewise has given Whirlpool a rough ride (1). Another market shift is the one in consumer goods regarding the relative power between manufacturers (Procter & Gamble and Rubbermaid, for example) and retailers (such as Walmart and Home Depot) (2). Such market shifts raise the likelihood of changes midstream in a development project.

Finally, technology--both the technology that goes into the product and the technology (like computer-aided design tools) used to develop it--is changing at an accelerating pace. New technologies appear and existing ones become obsolete or simply passe. Sometimes a new technology provides unexpected benefits that one would like to exploit during a project, such as the enthusiastic reception of portable music players by runners and others exercising physically, which, in turn, demands unexpected changes during product development to incorporate resistance to rain, perspiration and vibration. Alternatively, sometimes the benefits touted by the purveyors of the new technology don't pan out. This opens more opportunities for change in the midst of development.

On the other hand, many managers, at all levels, do not welcome change during a project. For them, mid-project changes open the door to product cost and development budget overruns, schedule slippage and product defects. Hard-pressed to deliver profit on a quarterly basis, managers, especially at higher levels, rightly see change as disruptive. Consequently, management has built development systems aimed at predictability and certain success, such as: phased development (including StageGate[R]), Six Sigma and Project Office. Although such systems clearly have benefits, their gains in predictability come with a corresponding side effect of rigidity.

In summary, although change during development is increasingly common, I instead see managements adopting systems that are increasingly resistant to change. This article shows how to introduce the flexibility needed to make changes during product development with minimal disruption, which I believe will separate the future winners from the losers.

Consider this example of turbulence encountered by Quadrus, a Calgary-based software development company, in developing an application for a Canadian online drugstore. This is a volatile market driven by ongoing supplier, political, regulatory, and legal thrusts. Extreme change was the essence of the management challenge Quadrus faced. In addition, its client was coming from behind in a bid to become a market leader. Quadrus responded by using very short (two-day) development iterations--each producing working software--and weekly online deployments, which not only kept up with the changing environment but aggressively led the change. By having a positive attitude toward change and employing systems that could reorient quickly, Quadrus' client could respond to competitive challenges and regulatory demands faster than competitors, thus leading the change to gain competitive advantage (3, p. 249).

A Model for Flexibility

In this article, flexibility refers to the ability to make changes in the product being developed or in the process by which it is developed, even relatively late in development, without being too disruptive. Such flexibility is rare today because managements have opted for systems that actually restrict flexibility in favor of predictability (as mentioned earlier), but there is an important exception: software development. Over the past several years, software developers, such as those at Quadrus, have felt the need to accommodate change during development and have developed systems that reintroduce flexibility. These fall under the label of agile software development, and they stem from the Agile Manifesto (AgileManifesto.org). Although there are several variations in methodology, all agile methods employ some rather revolutionary approaches:

* They all develop software iteratively in loops of typically two weeks but never more than six weeks.

* They all deliver working software at the end of each of these iterations (in contrast to the more common deliverable of documentation).