CIS600 Project Management - Enterprise Resource Management (ERP)

CIS600 – Project Management Case Study 6: Cisco ERP (50 points)

Case: Cisco Systems, Inc.: Implementing ERP, Robert D. Austin, Richard L. Nolan, and Mark Cotteleer, Harvard Business Publishing (9-699-022). Key elements: • •

• Enterprise Resource Management (ERP) systems Identifying and managing stakeholders Incremental vs. big bang implementation Questions:

1. Describe the initial approach for IT decision making at Cisco. Why was this approach ineffective? 2. Why did the Cisco functional managers resist the new ERP system? How did the project team overcome their resistance? 3. Was the ERP implementation team smart or lucky? Give examples from the case to support your answer. 4. What best practices for managing an ERP implementation were demonstrated by Cisco in the case?

For the exclusive use of J. Williams, 2020. 9-699-022 REV: MAY 6, 2002 ROBERT D. AUSTIN RICHARD L. NOLAN MARK J. COTTELEER

Cisco Systems, Inc.: Implementing ERP Pete Solvik, Cisco Systems chief information officer (CIO), considered the last remaining line item of his ERP (Enterprise Resource Planning) implementation budget. Cisco had a history of rewarding performance with cash bonuses, but the amount allocated for rewarding the ERP team, over $200,000, was unprecedented. To be sure, they had delivered a lot in a time frame that no one had believed possible. It had not been easy either. The team members, Solvik included, had taken a risk in joining the project. Rewards should, and would, be generous. The size of the bonus pool, though, made Solvik think: they had done well, but how well? What had gone right? What had gone wrong? Given another project of this magnitude and risk, would they be able to do it again? History of Cisco Cisco Systems, Inc. was founded by two Stanford computer scientists in 1984 and became publicly traded in 1990. The company’s primary product is the “router,” the combination of hardware and software that acts as a traffic cop on the complex TCP/IP1 networks that make up the Internet (as well as corporate “Intranets”). With the rise of Internet technologies, demand for Cisco’s products boomed and the company soon began to dominate its markets. By 1997, its first year on the Fortune 500, Cisco ranked among the top five companies in return on revenues and return on assets. (See Exhibit 1 for Cisco’s financial performance.) Only two other companies, Intel and Microsoft, have ever matched this feat. Perhaps even more impressive, on July 17, 1998, just 14 years after being founded, Cisco’s market capitalization passed the $100 billion mark (15-times 1997 sales). Some industry pundits predicted that Cisco would be the third dominant company—joining Microsoft and Intel—to shape the digital revolution. Don Valentine, partner of Sequoia Capital and vice chairman of the board of Cisco,2 was the first to invest in Cisco; he took a chance on the young company when other venture capitalists were more cautious. One way Valentine protected his $2.5 million initial investment was by reserving the right to bring in professional management when he deemed it appropriate. 1 Transmission Control Protocol and Internet Protocol, together known as TCP/IP, provided a robust standard for routing messages between LANs and created the potential to connect all computers on an ever-larger Wide Area Network (WAN). 2 Don Valentine was previously the outside executive chairman of the board of Cisco. Cisco has maintained its chairman of the board as an outside director. Currently, John Morgridge serves as an outside director and chairman of the board. ________________________________________________________________________________________________________________ Postdoctoral Research Fellow Mark J. Cotteleer prepared this case under the supervision of Professors Robert D. Austin and Richard L. Nolan. HBS cases are developed solely as the basis for class discussion. Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management. Copyright © 1998 President and Fellows of Harvard College. To order copies or request permission to reproduce materials, call 1-800-545-7685, write Harvard Business School Publishing, Boston, MA 02163, or go to http://www.hbsp.harvard.edu. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means—electronic, mechanical, photocopying, recording, or otherwise—without the permission of Harvard Business School. This document is authorized for use only by James Williams in CIS600 Spring 2020 taught by Tim Rodgers, University of Colorado - Boulder from Jan 2020 to Jun 2020. For the exclusive use of J. Williams, 2020. 699-022 Cisco Systems, Inc.: Implementing ERP In 1988, Valentine hired John Morgridge as CEO. Morgridge, an experienced executive in the computer industry, immediately began to build a professional management team. This team soon clashed with the founders and, after Cisco’s initial public offering in 1990, both founders sold all of their stock and left the company. This departure left Morgridge free to continue his plans to install an extremely disciplined management structure. Morgridge believed that many Silicon Valley firms decentralized too quickly and did not appreciate the proven ability of the functional organization to grow without sacrificing control. Accordingly, Morgridge maintained a centralized functional organization. While Product Marketing and R&D were decentralized into three “Lines of Business” (Enterprise, Small/Medium Business, and Service Provider), the manufacturing, customer support, finance, human resources, IT, and sales organizations remained centralized. History of IT at Cisco Pete Solvik joined Cisco in January 1993 as the company’s CIO. At the time, Cisco was a $500 million company running a UNIX-based software package to support its core transaction processing. The functional areas supported by the package included financial, manufacturing, and order entry systems. Cisco was “far and away” the biggest customer of the software vendor that supported the application.3 Solvik’s experience and the company’s significant growth prospects convinced him that Cisco needed a change. We wanted to grow to $5 billion-plus. The application didn't provide the degree of redundancy, reliability, and maintainability we needed. We weren't able to make changes to the application to meet our business needs anymore. It had become too much spaghetti, too customized. The software vendor did offer [an upgraded version], but when we looked at it we thought “by the time we’re done our systems will be more reliable and have higher redundancy but it will still be a package for $300 million companies and we’re a $1 billion dollar company.” Solvik’s initial inclination was to avoid an ERP solution. Instead, he planned to let each functional area make its own decision regarding the application and timing of its move. Keeping with Cisco’s strong tradition of standardization, however, all functional areas would be required to use common architecture and databases. This approach was consistent with the organizational and budgetary structures that Solvik had installed upon his arrival. Solvik felt strongly that budgetary decisions on IT expenditures be made by functional areas while the IT organization reported directly to him. Solvik’s objection to ERP solutions was also born out of concerns about the types of “mega-projects” that ERP implementations often became. A Defining Moment In the following year, little progress was made. Randy Pond, a director in manufacturing4 and eventual co-leader of the project, described the dilemma facing the functional areas in late 1993: 3 Most customers of the software vendors ranged from $50 million to $250 million in revenue. 4 Subsequent to the implementation Randy Pond was promoted to the vice president level in manufacturing at Cisco. 2 This document is authorized for use only by James Williams in CIS600 Spring 2020 taught by Tim Rodgers, University of Colorado - Boulder from Jan 2020 to Jun 2020. For the exclusive use of J. Williams, 2020. Cisco Systems, Inc.: Implementing ERP 699-022 We knew we were in trouble if we did not do something. Anything we did would just run over the legacy systems we had in place. It turned into an effort to constantly band-aid our existing systems. None of us were individually going to go out and buy a package. . . . The disruption to the business for me to go to the board and say “Okay, manufacturing wants to spend $5 or $6 million dollars to buy a package and by the way it will take a year or more to get in . . .” was too much to justify. None of us was going to throw out the legacies and do something big. The systems replacement difficulties of functional areas perpetuated the deterioration of Cisco’s legacy environment. Incremental modification continued while the company sustained an 80% annual growth rate. Systems outages became routine. Product shortcomings exacerbated the difficulties of recovering from outages. Finally, in January of 1994, Cisco’s legacy environment failed so dramatically that the shortcomings of the existing systems could no longer be ignored. An unauthorized method for accessing the core application database—a workaround that was itself motivated by the inability of the system to perform—malfunctioned, corrupting Cisco’s central database. As a result, the company was largely shut down for two days. Cisco’s struggle to recover from this major shutdown brought home the fact that the company’s systems were on the brink of total failure. Solvik, Pond, and a number of other Cisco managers came to the conclusion that the autonomous approach to systems replacement they had adopted was not going to be sufficient. An alternative approach was needed. Solvik described what they did: We said, “we can’t wait casually by while Order Entry, Finance, and Manufacturing go out and make three separate decisions.” It would take too long to get those applications in place. We needed to take faster action. At that point we got sponsorship from the SVP of Manufacturing, Carl Redfield. He was with Digital before Cisco, in PC manufacturing. He took the lead and said, “O.K., let’s get on with this.… let’s start from the manufacturing perspective, and see if we can get the Order Entry and Financial groups in the company interested in doing a single integrated replacement of all the applications, instead of taking a longer time doing separate projects.” And so in February, about a month after the [company shutdown], we went about putting together a team to do an investigation to replace the application. Redfield understood from previous large-scale implementation experiences at Digital how “monolithic” IT projects could take on lives of their own. He echoed Solvik’s concerns about project size and had strong views about how Cisco should approach a large implementation project. I knew we wanted to do this quickly. We were not going to do a phased implementation, we would do it all at once. We were not going to allow a lot of customization either. There is a tendency in MRP systems5 for people to want the system to mirror their method of operation instead of retraining people to do things the way the system intended them. This takes a lot longer. Also, we wanted to create a schedule that was doable and make it a priority in the company as opposed to a second tier kind of effort. 5 MRP represents a class of systems, often thought of as predecessors of ERP that focus on planning the material requirements for production. Forecast or actual demand is fed to MRP either manually or from other types of systems. MRP functionality is embedded in the offerings of all leading ERP vendors. 3 This document is authorized for use only by James Williams in CIS600 Spring 2020 taught by Tim Rodgers, University of Colorado - Boulder from Jan 2020 to Jun 2020. For the exclusive use of J. Williams, 2020. 699-022 Cisco Systems, Inc.: Implementing ERP Selecting an ERP Product Cisco’s management team realized that implementing to meet business needs would require heavy involvement from the business community. This could not be an IT-only initiative. It was critically important to get the very best people they could find. Solvik elaborated: “Our orientation in pulling people out of their jobs [to work on the project] was if it was easy then we were picking the wrong people. We pulled people out that the business absolutely did not want to give up.” Consistent with the need for a strong Cisco team, the company would also need strong partners. Solvik and Redfield felt it was particularly important to work with an integration partner that could assist in both the selection and implementation of whichever solution the company chose. Great technical skills and business knowledge were a prerequisite. Solvik explained the choice of KPMG as the integration partner: KPMG came in and saw an opportunity to really build a business around putting in these applications. They also saw this as kind of a defining opportunity, to work with us on this project. As opposed to some other firms that wanted to bring in a lot of “greenies,” KPMG was building a practice of people that were very experienced in the industry. For instance, the program manager that they put on the job, Mark Lee, had been director of IT for a company in Texas that had put in various parts of an ERP system. With KPMG on board, the team of about 20 people turned to the software market with a multipronged approach for identifying the best software packages. The team’s strategy was to build as much knowledge as possible by leveraging the experiences of others. They asked large corporations and the “Big Six” accounting firms what they knew. They also tapped research sources such as the Gartner Group.6 By orienting the selection process to what people were actually using and continuing to emphasize decision speed, Cisco narrowed the field to five packages within two days. After a week of evaluating the packages at a high-level, the team decided on two prime candidates, Oracle and another major player in the ERP market. Pond recalled that size was an issue in the selection. “We decided that we should not put Cisco’s future in the hands of a company that was significantly smaller than we were.” The team spent 10 days writing a Request For Proposals (RFP) to send to the vendors. Vendors were given two weeks to respond. While vendors prepared their responses, the Cisco team continued its “due diligence” by visiting a series of reference clients offered by each vendor. Following Cisco’s analysis of the RFP responses, each vendor was invited in for a three-day software demonstration and asked to show how their package could meet Cisco’s information processing requirements. Cisco provided sample data, while vendors illustrated how key requirements were met (or not met) by the software. Selection of Oracle was based on a variety of factors. Redfield described three of the major decision points: First, this project was being driven pretty strongly by manufacturing and Oracle had a better manufacturing capability than the other vendor. Second, they made a number of 6 The Gartner Group is a leading industry resource for information on ERP and other information systems and manufacturing related research. 4 This document is authorized for use only by James Williams in CIS600 Spring 2020 taught by Tim Rodgers, University of Colorado - Boulder from Jan 2020 to Jun 2020. For the exclusive use of J. Williams, 2020. Cisco Systems, Inc.: Implementing ERP 699-022 promises regarding the long term development of functionality in the package.7 The other part of it was the flexibility offered by Oracle’s being close by.8 Cisco also had reason to believe that Oracle was particularly motivated to make the project a success. Pond provided his impression of Oracle’s situation: “Oracle wanted this win badly. We ended up getting a super deal. There are, however, a lot of strings attached. We do references, allow site visits and in general talk to many companies that are involved in making this decision.” The Cisco project would be the first major implementation of a new release of the Oracle ERP product.