An Incremental Process for Software Implementation
Eighteen months had elapsed since New World Electronics began implementing an advanced software-based scheduling system for the factory floor.1 From the beginning, all the traditional elements were present for a smooth implementation: support of senior management, adequate staffing and funding, a good fit between the needs of the organization and the capabilities of the software, and a solid information technology (IT) infrastructure. Yet after a vigorous start, the project team had lost its way. What had seemed like a relatively straightforward task — configuring desired software functionality and specifying complementary organizational changes — turned out to be surprisingly burdensome. As the team engaged in cycle after cycle of analysis and configuration, it continually approached but never quite reached a complete and sound model tailored to the company’s manufacturing environment. Milestone dates passed; resources and attention drifted away. The team wondered how to refocus its energies.
New World Electronics’ conundrum is not unique.2 Gone are the days of turnkey packages — technologies that, at least in principle, could be physically installed, turned on, and used with minimal alteration by most organizations. Nearly all advanced production technologies today — CAD/CAM, executive support systems, digital imaging, work-flow management, enterprise resource planning, groupware — either have a substantial software component or come entirely embedded in software.3 The broad flexibility of modern software can be both the boon and bane of technology implementation. This flexibility enables new ways of working that amplify the potential benefits of IT investments, but can transform almost any implementation project into a potentially risky program of organizational innovation and change. It offers users an abundance of functionality, but demands that they choose well from this abundance to ensure that their chosen configuration is not only internally consistent, but also complements organization processes, policies, structures, and measures. Moreover, this flexibility is conducive to the application of new strategies for managing the process of implementation itself, but users must choose wisely from among alternative strategies.
The root of the problem at New World Electronics was not a poor endowment of resources or some other project factor, but rather an ineffective implementation process.4 Team members employed a traditional approach to software implementation, characterized by a lengthy period of off-line effort to select and configure software functionality, which would conclude with a “big-bang” finish — a concentrated interval when the complete system would be turned on.
References
1. Although New World Electronics is a pseudonym, this description is based on an actual example.
2. An estimated 50 percent to 75 percent of organizations experience some form of failure when implementing advanced production technologies. See:
A. Majchzak, The Human Side of Factory Automation (San Francisco: Jossey-Bass, 1988). Up to 70 percent of business reengineering implementations fail to achieve intended goals. See:
B.J. Bashein, M.L. Markus, and P. Riley, “Preconditions for BPR Success,” Information Systems Management, volume 11, Spring 1994, pp. 7–13.
3. J.B. Quinn, J.J. Baruch, and K.A. Zien, “Software-Based Innovation,” Sloan Management Review, volume 37, number 4, Summer 1996, pp. 11–24.
4. Until recently, the bulk of innovation research focused on implementation factors rather than process. Factor models of implementation identify individual characteristics of the technology (e.g., complexity, trialability), the organization (e.g., centralization, formalization), or the technology-organization combination (e.g., compatibility, top management support) that either facilitate or inhibit implementation success. See:
A.D. Meyer and J.B. Goes, “Organizational Assimilation of Innovations: A Multilevel Contextual Analysis,” Academy of Management Journal, volume 31, December 1988, pp. 897–923; and
C.A. Beatty, “Implementing Advanced Manufacturing Technologies: Rules of the Road,” Sloan Management Review, volume 35, Summer 1992, pp. 49–60.
Process models, by contrast, describe holistic implementation strategies and processes. See:
B.W. Chew, D. Leonard-Barton, and R.E. Bohn, “Beating Murphy’s Law,” Sloan Management Review, volume 32, Spring 1991, pp. 5–16;
E. Brynjolfsson, A.A. Renshaw, and M. Van Alstyne, “The Matrix of Change,” Sloan Management Review, volume 38, Winter 1997, pp. 22–40; and
W.J. Orlikowski and J.D. Hofman, “An Improvisational Model for Change Management: The Case of Groupware Technologies,” Sloan Management Review, volume 38, Winter 1997, pp. 11–21.
5. D. Leonard-Barton, “Implementation Characteristics of Organizational Innovations,” Communication Research, volume 15, May 1988, pp. 603–631.
6. The initial concepts for the RDI strategy were developed in 1994 by Scott Moses and other implementation consultants working for i2 Technologies, a vendor of supply-chain management software headquartered in Irving, Texas. Over the course of applying the strategy on several large implementations, it was formalized into a methodology and adopted as the recommended approach for implementing the firm’s software products.
7. M.J. Gallivan, J.D. Hofman, and W.J. Orlikowski, “Implementing Radical Change: Gradual Versus Rapid Pace,” in Proceedings of the Fifteenth International Conference on Information Systems (Vancouver: Fifteenth International Conference on Information Systems, 1994), pp. 325–329; and
D.B. Stoddard and S.L. Jarvenpaa, “Business Process Redesign: Tactics for Managing Radical Change,” Journal of Management Information Systems, volume 12, Summer 1995, pp. 81–107.
8. In selecting a case example for use in this article, we set out the following ideal criteria: (1) faithful application of the RDI methodology, (2) willingness to provide researcher access to key implementation personnel and documents, and (3) experience with multiple applications of the methodology. Of the ten sites employing the RDI methodology, Herman Miller best met these criteria and had the additional advantage of being a site Moses already knew well, having served as a lead implementation consultant.
9. S. Zuboff, In the Age of the Smart Machine (New York: Basic Books, 1988);
M. Hammer, “Reengineering Work: Don’t Automate, Obliterate,” Harvard Business Review, volume 66, number 4, July–August 1990, pp. 104–112; and
N. Venkatraman, “IT-Enabled Business Transformation: From Automation to Business Scope Redefinition,” Sloan Management Review, volume 35, Winter 1994, pp. 73–87.
10. Although much of the prior research on the costs and challenges of process innovation have focused on the implementation of production equipment, the same principles apply to the implementation of process innovations entirely embodied in software. See:
R.G. Fichman and C.F. Kemerer, “The Assimilation of Software Process Innovations: An Organizational Learning Perspective,” Management Science, volume 43, issue 70, October 1997, pp. 1345–1363.
11. D. Leonard-Barton, “Implementation as Mutual Adaptation of Technology and Organization,” Research Policy, volume 17, number 5, October 1988, pp. 251–267.
12. Leonard-Barton defines divisibility as permitting the division of “a technology into stages or segments, each of which delivers some benefits even if no further segments are adopted.” Based on a set of fourteen case studies of technological innovation involving diverse technologies and organizational settings, Leonard-Barton concludes that most technologies have the potential for divisibility — although it is common for organizations to overlook this property. See:
Leonard-Barton (1988a).
13. W.M. Cohen and D.A. Levinthal, “Absorptive Capacity: A New Perspective on Learning and Innovation,” Administrative Science Quarterly, volume 35, March 1990, pp. 128–152.
14. Ibid.
15. P. Senge, The Fifth Discipline (New York: Doubleday, 1993), p. 63.
16. R. Nelson and S. Winter, An Evolutionary Theory of Economic Change (Cambridge, Massachusetts: Harvard University Press, 1982), pp. 73–95.
17. Even so, mechanisms do exist to facilitate learning even under the constraint of an all-at-once approach. Chew et al. identify four levels of learning — vicarious learning, simulation, prototyping, and online learning — the first three of which can be employed throughout all-at-once implementations. They note that the most effective mechanism for organizational learning is online learning —also referred to as “learning by doing” — in which learning occurs as the technology is used in the ongoing operations of a business. They argue that in most cases online learning is cost-prohibitive; however, it appears this is based on an assumption that the technology is indivisible. Our position is that when a technology is divisible, and this divisibility is used to enable a RDI approach, online learning becomes a key mode of learning. See:
Chew et al. (1991).
18. Schaffer and Thomson use this same analogy in describing the problems with diffuse, non-results-driven programs of change. See:
R.H. Schaffer and H.A. Thomson, “Successful Change Programs Begin with Results,” Harvard Business Review, volume 70, January–February 1992, pp. 80–89.
19. T.E. Potok and M.A. Vouk, “The Effects of the Business Model on Object-Oriented Software Development Productivity,” IBM Systems Journal, volume 36, number 1, 1997, pp. 140–161.
20. C.J. Gersick, “Time and Transition in Work Teams: Toward a New Model of Group Development,” Academy of Management Journal, volume 31, number 1, March 1988, pp. 9–41.
21. The data supporting this analysis were collected by i2 Technology from a survey of its customers and project managers.
22. Principles shared by RDI and the accelerated value method include: (1) breaking the implementation into small segments, (2) defining the content of each segment by business value, and (3) defining each increment in such a way that it provides value even if no further segments are implemented.
23. E.M. Rogers, “The ‘Critical Mass’ in the Diffusion of Interactive Technologies in Organizations,” in The Information Systems Research Challenge: Survey Research Methods, volume 3, K.L. Kraemer, J.I. Cash, and J.F. Nunamaker, eds. (Boston: Harvard Business School Research Colloquium, 1991), pp. 245–264.
24. Brynjolfsson et al. (1997).
25. Orlikowski and Hofman (1997).
26. W. Orlikowski, “Learning From Notes,” The Information Society, volume 9, number 3, July–September 1995, pp. 237–250.
27. Leonard-Barton (1988a).
28. R.G. Fichman and C.F. Kemerer, “The Illusory Diffusion of Innovation: An Examination of Assimilation Gaps,” Information Systems Research, in press.