By Dray Barnes
Introduction
Cisco Systems, Inc, has been a technological monolith in the hardware and software industry for years. Founded in 1984, the company experienced massive growth due to high demand for its products, most specifically the router. 1997 marker Cisco’s first year on the Fortune 500 (Austin, R., Nolan, R., & Cotteleer, M., 2002). Cisco’s massive growth prompted internal change within the company. The company wanted a more viable software system to handle the large demand for its products, software that more fitted the needs of the company and its employees. This software manifested in the form of ORACLE, a conglomeration of programs that operated much more efficiently and transparently than its predecessor.
Because Cisco had grown to such a large company, implementation of this software was risky and put the structural integrity of the entire company at risk. Therefore a very specific and organized plan was created in order to make the transition to ORACLE as smooth as possible. In Cisco Systems, Inc.: Implementing ERP the details of this experiment were documented and I will place myself as project manager of this operation in order to present both the pros and cons of this process.
UNIX Based-software
In order to analyze the risks and benefits of Cisco’s implementation policy of ORACLE it must be quickly noted what its predecessor was and why it needed to be replaced. ORACLE’S predecessor was a “UNIX-based software package” which navigated the order entry, manufacturing, and financial aspects of Cisco’s business (Austin, R., Nolan, R., & Cotteleer, M., 2002). Company CIO during the transition Pete Solvik stated of UNIX, “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.” Essentially UNIX had reached its maximum potential for the company and its functions were no longer applicable to the needs of the company. Along with routine crashes of the system UNIX was becoming more of a hassle than a helper. Therefore a small KPMG team of about 20 people came in to find a better alternative.
On the policy of finding appropriate team members for this projects Solvik states, “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.” As the saying goes, if you want the best you have to be the best. As project manager this should always be the approach to hiring team members while staying within the labor budget. Hiring the most qualified applicants will always lead to better productivity and overall higher company morale.
Randy Pond, the eventual vice president in manufacturing and co-leader of the project makes the claim, “Everybody in the company knew this was happening and it was a priority for the business”. Cisco could have handled the integration in a private matter, only giving employees as much information as they needed to know but instead they chose a far more transparent implementation of the new software. This allowed everyone to be on a common accord and reduced confusion of redundancy in the project. As project manager it is important for all members of the team to be not just on the same page but reading the same sentence at the same time. With the ORACLE project emerging “as one of the top seven goals for the year” this project gained momentous energy and provided focus and novelty to Cisco’s employees. Cisco’s process for implementation relied on what is termed ‘rapid iterative prototyping” (2002). This method involved breaking the implementation into segments called “Conference Room Pilots (CRP) (Austin, R., Nolan, R., & Cotteleer, M., 2002). This greatly benefited the company as a whole because it allowed members of the company to review what has been done and observe any flaws or errors in previous work. As project manager it is essential that team members are not only prepared for upcoming enhancements but also understand what has been done and the effects that will have upon the company. These were very significant areas that Cisco handled correctly and I would conduct no alterations. Now I will evaluate the cons of Cisco’s implementation process.
Decision-Making Process
When making the final decision as to which software package/company that Cisco would use, in choosing Oracle SVP of manufacturing Carl Redfield states, “ 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 promises regarding the long term development of functionality in the package.”, yet it is later noted that, “…not all of these promises were met in the time frame agreed to during contract negotiations.” (2002) While it most likely wasn’t possible that Redfield was aware that Oracle wouldn’t be able to meet all their projections, as project manager one has to use empirical evidence to either refute or support the offers being made by a joint company. If under analysis one sees that ORACLE would not be able to reasonably meet the conditions set forth in the contract then certain penalties must be put into place in order to remove culpability from Cisco. Therefore had I been project manager, I would have enacted some contractual buffer between Cisco and ORACLE so as to be prepared for situations as this.
After ORACLE was chosen as the best option, leaders of the selection team need to pitch this company and its product to the board of directors. Solvik states, “Instead of developing a formal business case (i.e, a financial analysis) to demonstrate the impact that the project would have on the company, the team chose to focus on the issues that had sparked the analysis in the first place.” (2002) While the motive for phasing out UNIX was honorable, what matters most in all private sector businesses is the bottom line. There should have been a clear cut, specific financial analysis of all the costs and expenditures that implementation of ORACLE would create. For the costs or ORACLE to be swept under the rug leads the board of the company to believe that there is something to hide or some major financial underpinning. Luckily UNIX systems crashed the day of the ORACLE pitch so maintaining the status quo was not an option. The final issue I noticed with implementation related to the CRP phases. The author writes, “The first effort focused on getting the team trained on the Oracle applications. Cisco directed Oracle to compress its normal five-day training classes into two 16-hour days” (Austin, R., Nolan, R., & Cotteleer, M., 2002). There are two problems with this alteration; the first being that chances are ORACLE has a better handle on the implementation process than Cisco and requiring employees to absorb 16 hours of information in one day is absurd. While understood that Cisco was on a rapid acceleration implementation, in altering the routine that ORACLE has had for success with other integrations it may have caused unnecessary confusion may have forced needless administrative errors. The stress of implementation should not be redirected to company employees. Having 16 hour workshops is a detriment to the company and employees. It is scientifically noted that for the vast majority of people the brain can only hold so much information, certainly not 16 hours worth. Even if rigorous notes were taken some of the information may have fallen through the cracks which would further hinder the integration process and also decrease company morale through mere exhaustion.
The problem posed at the beginning and end of the research is whether the team members that conducted this integration deserved a bonus, and if so how much? As project manager it would have been helpful to create a rubric for amateur, novice, and professional work regarding different areas of implementation and to use that rubric to grade each member of each team. Using the results one could attach a formula to quantify the dollar amount of each bonus. This would have allowed a fair and unambiguous method of rewarding hard work and left both the employees and the company satisfied.