When Too Much IT Knowledge Is a Dangerous Thing
In recent years, large companies have invested a great deal of money — and faith — in IT systems as a means of leading vital organizational or competitive change. More than half of such investment has been in what I call “process-enabling information technology,” or IT that facilitates the execution of entire business processes rather than individual tasks.1 Such technology includes systems devoted to enterprise resource planning (ERP), supply chain management (SCM), customer relationship management (CRM), and e-commerce operations. The coordination, managerial oversight and marshaling of resources needed to implement any of these systems make for a change effort like no other.
All too often, however, hopes are dashed, and the effort is deemed a failure. Various studies have shown that in 30% to 75% of cases, new systems don’t live up to expectations, register a measurable financial impact, improve work processes, or bring about organizational change.2 In some cases, the result is catastrophe. Nike, for example, spent hundreds of millions of dollars on a system that forecasted sales inaccurately; Hershey Foods suffered through a Halloween season in which it failed to keep its candy in stock with major retailers; and FoxMeyer Drug filed for Chapter 11 at least in part because of problems with its ERP implementation.
Technical snafus are not the reason for these and other failures.3 Nor is the problem a scarcity of good advice for managers. Academics, consultants, IT vendors and managers themselves have conducted research that has generated much valid guidance on one aspect or another of implementation. Nor is such guidance being ignored. Most executives I’ve worked with are keenly aware that implementations are big, risky projects, and they have diligently sought state-of-the-art advice by reading, attending conferences and classes, and hiring experts. In my research, I’ve found that the problem — the fundamental issue — is that managers usually follow what amounts to a universal checklist, one that is supposed to be appropriate for all situations, when they implement a new process-enabling technology. The checklist is assembled from the broad spectrum of IT implementation research on such topics as user acceptance, business-process redesign, system configuration and change management. The assumption is that if all the items on the checklist are attended to, success will follow.
The problem is that the checklist assumes all implementations are basically alike.
References
1. B.J. Gomolski, J. Grigg and K. Potter, “2001 IT Spending and Staffing Survey Results” (Stamford, Connecticut: Gartner Group, 2001).
2. Studies concentrating on process-enabling information technology have found 70% failure rates among IT-based change initiatives (T.H. Davenport, “The Fad That Forgot People,” Fast Company, November 1995, 70–75); 75% among sales force automation efforts (M. Blodgett, “Vendor Tries To Simplify Sales Force Automation,” Computerworld, Dec. 26, 1995, 62); and 30% to 60% among general efforts to improve work processes (J. McDermott, “Improving Productivity Through Technological Innovation,” Merck Bulletin 67 (1987): 3–5; T.K. Bikson and B. Gutek, “Implementation of Office Automation” (Santa Monica, California: Rand, 1984). A recent study of 100 projects by H. Sirkin and K. Dickel, “Getting Value From Enterprise Initiatives” (Boston: Boston Consulting Group, 2000), found that their sponsors considered them fully successful in only one-third of the cases and that tangible financial impact was achieved in only 37% of cases.
3. There is almost universal agreement that large-scale IT failures occur for managerial reasons, not because of technical problems. For a review of literature on this topic, see J. McDonagh, “Not for the Faint-Hearted: Social and Organizational Challenges in IT-enabled Change,” Organization Development Journal 19 (spring 2001): 11–20.
4. As C. Christensen and D. Sundahl maintain, “Unless researchers ground their theory upon robustly defined categories of phenomena, they cannot make statements that have contingent explanatory power — explanations of how the outcomes caused by actions or events will vary, depending upon the circumstances of the categories. … If researchers attempt to short-circuit the process by leaping from phenomena to theory, their work is of less value to future researchers and practitioners than it could be.” See “The Process of Building Theory,” Harvard Business School working paper no. 02-016, Boston, 2001.
5. Of course, simply avoiding the pitfalls described is not a guarantee of implementation success. The model presented assumes that, among other things, a company is capable of maintaining a robust IT infrastructure, employs good project-management techniques (including those listed here as ground rules) and has purchased a process-enabling technology that largely works as promised and is appropriate for its business goals.
6. R. Austin, R. Nolan, M. Cotteler, “Cisco Systems, Inc.: Implementing ERP,” Harvard Business School case no. 9-699-022 (Boston: Harvard Business School Publishing, 1999).
7. Temporary “performance dips” appear to be common following the adoption of process-enabling systems. For an example, see A.P. McAfee, “The Impact of Enterprise Technology Adoption on Operational Performance: An Empirical Investigation,” Production and Operations Management 11 (spring 2002): 33–53.
8. For news accounts of the problem between Nike and i2, see S. Konicki, “Nike Just Didn’t Do It Right, Says i2 Technologies,” Informationweek, March 5, 2001, 32; and T. Wilson, “Supply Chain Debacle —Nike Faces Yearlong Inventory Problem After i2 Implementation,” InternetWeek, March 5, 2001, 1–3.
9. A.P. McAfee, “Rich-Con Steel,” Harvard Business School case no. 9-699-133 (Boston: Harvard Business School Publishing, 1999).
10. M. Boslet, “CRM: The Promise, the Peril, the Eye-Popping Price,” Industry Standard, Aug. 6–13, 2001, 61–65.
11. See, for example, S.J. Kafka, B.D. Temkin, et al., “The eMarket-place Shakeout” (Cambridge, Massachusetts: Forrester Research, 2000); L. Gomes, “Fruitless Ventures: How Lower-Tech Gear Beat Web ‘Exchanges’ at Their Own Game,” Wall Street Journal, Friday, Mar. 16, 2001, sec. A, p. 1 and p. 6; and B. Tedeschi, “As the Shake-out Proceeds, Some Business-to-Business Marketplaces Show Their Staying Power,” New York Times, Monday, July 16, 2001, sec. C, p. 4. According to one estimate, less than 1% of the world’s suppliers are connected to an e-marketplace (S. Kennedy, “Business-to-Business Exchanges Fail To Deliver,” Reuters, Apr. 11, 2001. The article can be accessed at http://www.itweb.co.2a/sections/business/2001/0104111132.asp).
12. The high-tech manufacturing sector’s RosettaNet is one of the best known of these industry-level IT standards bodies.
13. A.P. McAfee and K. Herman, “Alibris (A),” Harvard Business School case no. 9-601-111 (Boston: Harvard Business School, 2002).
14. L. Radosevich, “Quantum’s Leap: One Computer Manufacturer’s Risky Decision To Overhaul Its Worldwide Business Systems in a Single Bound Paid Off,” CIO Magazine, Feb. 15, 1997, 40–44.
15. For a guide on handling small releases, see R.G. Fichman and S.A. Moses, “An Incremental Process for Software Implementation,” MIT Sloan Management Review 40 (winter 1999): 39–43.
16. For a managerial overview of Web services, see J. Hagel III and J.S. Brown, “Your Next IT Strategy,” Harvard Business Review 79 (October 2001): 105–113.
i. See A. McAfee, “When Too Much IT Knowledge is a Dangerous Thing,” MIT Sloan Management Review 44, no. 2 (winter 2003): 83–89; and A. McAfee, “Will Web Services Really Transform Collaboration?” MIT Sloan Management Review 46, no. 2 (winter 2005): 78–84.