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
Bibliographic record
Abstract
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). …
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.012 | 0.031 |
| Meta-epidemiology (narrow) | 0.001 | 0.001 |
| Meta-epidemiology (broad) | 0.000 | 0.001 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.004 | 0.015 |
| Scholarly communication | 0.012 | 0.024 |
| Open science | 0.002 | 0.008 |
| Research integrity | 0.007 | 0.009 |
| Insufficient payload (model declined to judge) | 0.014 | 0.011 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".