The mitial design was too complex. It required the user to work with the elbow, the mouse and both hands! To address the problem, a company called Interpix was brought in to evaluate the system from a usability perspective. Interpix observed users working on paper mockups of the screens, using the pen as a mouse to see how users\" intwition would guide them to place buttons on the paper mockups. Videotapes of CSR's using the mockups showed how they interacted with the system and resulted in designing a simpler version of the interface. THE IMPLEMENTATION PLAN As software development neared completion, Cooper's team was making its final plans for implementation. The sheer size of the implementation resulted in numerous challenges that had to be dealt with, and several key decisions had yet to be made. The first decision facing the team was the timing of the hardware and software installations. Implementing the new systen would reguire replacing all the CSR's PC hardware in each of the branches with new Windows-based PCs. Some banks that had completed rollouts of CSR systems, such as BMO and Canadian Impenal Bank of Commerce (CIBC), chose to mmplement the hardware and software simultineously. Teams could go into the bank at the same time to replace the old hardware and install the new software simultaneously. This meant a single period of disruption for the branches, which ultimately meant less disruption for clients. Most important of all, savings would be realized quickly. Page 10 SBOSEDND1 But several members of Cooper's team advocated a two-stage approach. The CSRs, used to working in a DOS environment, would have to become familiar with the Windows operating system and with mouse navigation as part of the hardware change. A survey of the users indicated that 83 per cemt were comfortable with navigating in a GUI (gmphical user interface) environment. Nonetheless, there were some who were quite worried about the change. One CSR was so terrified by the thought of having to comfortable with navigating in a GUI (gmaphical user interface) environment. Nonetheless, there were some who were quite wornied about the change. One CSR was so terrified by the thought of having to lzarn the new application that she fielt she might have to leave the bank. Implementing the software was an equally big task. CSRs would have to leamn the new paperless transaction processes embedded in the new software and adjust to a new way of working. Cooper wondered whether it would be more appropriate to separate the installation of hardware and software. The team could introduce the hardware several months in advance of the installation of the new software. This would limit the amount of change taking place at any one time and would start to create momentum for the project. But it created other challenges. If hardware was to be installed before software, it would have to be compatible with both the old way and the new way of conducting transactions. Finding hardware m 2003 that was DOS-compatible was somewhat challenging. For instance, the old system printed receipts from impact printers. Cooper's team needed to upgrade the printing facility to thermo printers that could print 52 lines per second, but if they installed the hardware first, they also had to make sure that these new machines were compatible with the DOS environment. This issue would entail another level of testing in the field Finally, hardware was the largest cost on the project, and yet, until the software was installed, none of the benefits would be realired. A second cntical decision dealt with the geographic rollout of the system. Historically, RBC had introduced new programs and systems at the same time across different geographic regions. It was politically important to be seen as treating all regions equitably. Cooper explained: We usually go to our geographic unit partners, and we treat them all as equals, and everybody has their turn at the same time. We mount implementation teams that are in the position to start everywhere. So, we start in British Columbia at the same time as we start in Omtario or Cuebec. Everyone wants to have their turn equally and fairdy at the same trme. But with this Service Platform project, obtmning business benefits would depend heavily on the volume of transactions processed by the new system (and thus not subject to higher costs at Symeor). Therefore, Cooper was contemplating a move away from the standard approach by beginning with the largest branches in the busiest regions. This would mean meeting the financial targets of the system sooner, which was important to the steering committee and to the overall perception of the project among semior management. But it also meant violating long-standing norms at RBC for how such projects should be carried out. Cooper wondered whether this was appropriate and, if so, how the negative impacts should be managed. A variety of other decisions related to the overall scope of the project. Because this large-scale infrastructure project, with semior sponsorship, touched all branches across the country, the tcam was inundated with requests to add other requirements to the project. As Cooper noted: There is this natural gravitation in the organization that, a5 soon as people become aware that there 15 an approved, large-scale nitiative that is going to take us out into the network, everyhody wants to attach their project . . . onto your project. This team has a reputation for being excellent executers when it comes to implementing. 5o it tends to be, \"Oh well, everybody wants to attach their project . . . onto your project. This team has a reputation for being excellent executers when it comes to implementing. So it tends to be, "Oh well, get Kathy to do that. Get Kathy's group to do that. Kathy's group will know how to do Page 11 98058001 that." So we just become the popular place to try and land other initiatives when they want to get something done. Four specific requests that had yet to be considered were a change to the CITs to accommodate the future design of Visa cards, bandwidth upgrades to various branches that were still operating with 56kpbs communication line speed, network operating system conversions, and replacement of cash dispensing units. By 2003, CITs mostly read data from magnetic strips of cards, but it was predicted that within five years, chip-enabled CITs would become mainstream technology. As part of its processes for combating fraud, RBC Visa was planning to move towards cards with embedded chips that were considered more fraud resistant. But this move would require CITs that could read the embedded chips. Such terminals were available now but were more expensive than the currently needed terminals. Did it make sense to implement the CITs now for future processing, or should this be left for a later project? About 200 branches had lower bandwidth available than was considered ideal for the new system. This was identified as a potential problem for the new application and for other applications, such as digital imaging, that were also in development and expected to deliver to the branches at about the same time as the Service Platform. But because the bandwidth upgrade cost of approximately $5 million had not been planned for in the project, a case would have to be made to the steering committee for this change Third, the branches were currently running token ring networks, and it was viewed that it would be ideal to migrate to Ethernet during the hardware replacement rollout. Ethernet was a more current networking standard, and the conversion of branches made a lot of sense. The PCs that would be purchased for the new system would come standard with Ethernet cards. If a conversion was not made, token ring cards would have to be purchased, the price ranging from Can$120 to Cdn$400. All other areas of RBC were operating in an Ethernet environment. Therefore, continuing to support a separate architecture at the branch level would be costly for the bank. But converting branches from token ring to Ethernet requiredoperating in an Ethernet environment. Therefore, continuing to support a separate architecture at the branch level would be costly for the bank. But converting branches from token ring to Ethernet required upgrading the winng of all branches across the country at an estimated capital expenditure of in excess of 525 million and would add a tremendous amount of work that could jeopardize the timeline of the Service Platform project and the targeted business case. Although it was just 2 matter of time for RBC's branches to be switched to Ethernet, was it the nght time to do s0 as part of this project? Finally, Cooper had to evaluate whether the replacement of cash dispensing units (CDUs) should be attached to the Service Platform project. There was no cash locked in C3Rs\" drawers; CSRs retrieved cash from a central device called a cash-dispensing unit by having CSR Financial send a message to the device. The current CDUs were neardy 15 years old, were operationally problematic and would be the only piece of CSR's equipment left unreplaced. 'While the 530 million of capital cost to fund the CDU wpgrades had a separately approved business case, to integrate CDUs into the hardware upgrade, Cooper's team would have to purchase approximately 1,000 additional new PCs to dnve these CDUs and to run software that allowed CDUs to properly interface with the rest of the systems in the bank. Cooper was not sure whether this addition would delay the progress and/or affect the business case. These requests essentially asked Cooper to reconsider the scope of her project. While each had merits, Cooper wondered whether any or all of them should be incorporated into the Service Platform project. Figuring out how actual implementation should be accomplished in the field was a further decision to be made in developing the implementation plan. Typically, the bank hired implementation officers for its projects. These people would be brought in from various areas within the bank on special assignment for a Page 12 SBOSEDD1 24- to 36-month period, tramed and used dunng the rollout. At the end of the project, if suitable positions could not be found, many would be terminated with appropriate severance packages. For this project, Cooper was wondenng whether other approaches might be better. The implementation timeline was much shorter, only 12 months, and was considered very aggressive, given the scope and scale of the project, but necessary to achieve the business case financial targets. Would it be possible, for example, to outsource this function? How much internal RBC expertise was necessary for the implementation officers, particularly on the hardware side? Were there other ways to accomplish this task? The decisions on the software side were not amy easier. Bremner was in charge of promoting this web- based application, traming 10,000 C5Ks across Canada and making sure each one would be comfortable with a brand new work experience. However, there were both full-ime and part-time CSRs in each branch, with high turnover rates, particularly in wrban areas. Bremner and Cooper had to evaluate the feasibility of gathering C5Rs and putting them into a classroom without interrupting daily operations at each branch. The benefit of sending C5Rs to traditional classroom training sessions was that CSRs could interact with the instructor and with one another. The learming expenence could be enhanced by social interaction and face-to-face commumecation in a classroom setting. Another alternative of delivering tramning lessons was to make use of RBC's intranet, RBCnet. Once the new hardware was ready, each CSK would have access to RBCnet and could review learming materials posted on the CSR website. But could CSRs obtain enough confidence and experience from self-regulated leaming through online materials? How should the leaming materials be designed to ensure that CSRs would be ready for a new way of serving clients? Finally, the queshon remained as to how well this new system woald be accepted. On one hand, the new system would be a vast improvement over the old way of doing things, and it was aimed to renew the work life of C5Rs. On the other hand, it was a huge change. In addibon to the change for CSRs, equally important was that this was also a huge change for RBC's clients. Cooper wondered how and when to best tell the clients that RBC was introducing paperless transactions. As Cooper mulled over these issues, she also contemplated what other things needed to be considered in her implementation plan. Had she overlooked any issues that might jeopardize the success of this project? Was the timeframe for implementation reasonable? What could go wrong? RBC ROYAL BANK: SERVICE PLATFORM IMPLEMENTATION Phoebe Tsai prepared this case under the supervision of Professor Deborah Compeau solely to provide material for class discussion. The authors do not intend to illustrate either effective or ineffective handling of a managerial situation. The authors may have disguised certain names and other identifying information to protect confidentiality. Ivey Management Services prohibits any form of reproduction, storage or transmittal without its written permission. Reproduction of this material is not covered under authorization by any reproduction rights organization. To order copies or request permission to reproduce materials, contact Ivey Publishing, Ivey Management Services, co Richard Ivey School of Business, The University of Western Ontario, London, Ontario, Canada, N6A 3K7: phone (519) 681-3208; fax (519) 681-3832, e-mail cases Divey.two.ca. Copyright @ 2004, Ivey Management Services Version: (A) 2009-09-28 It was June 2003, and Kathy Cooper, vice-president of RBC Banking business & information solutions at RBC Royal Bank (RBC), was reflecting on the progress of the Service Platform project. The goal of this large effort was to replace the hardware and software used at the branch level by customer service representatives (CSRs) with a state-of-the-art paperless transaction system. Begun in 2001, the project was now in the design/build phase. In partnership with the bank's information technology (IT) group and IBM, Cooper and her team had successfully identified the requirements of the system, and after some negotiation, had agreed on the deliverables. Now a team from IBM and RBC was building the system, with an expected completion date of September 2003. After the software was developed, it would be Cooper's responsibility to ensure that the implementation was completed successfully. But converting the 10,000 CSRs in 1,100 branches in 12 months (beginning in January 2004) would be no easy task, and Cooper wanted to ensure that she had a solid plan for this critical phase of the project. RBC ROYAL BANK Originally formed as a private commercial bank in 1864, the Merchants' Bank of Halifax was renamed the Royal Bank of Canada in 1901. Initially, the bank focused on fishing timber and the flow of goods from Europe. In the early 20th century, the business territory of the company expanded to South and Central America. During the first two decades of the 20th century, Royal Bank acquired several enterprises including Union Bank of Halifax, Quebec Bank and Union Bank of Canada. Surviving the Great Depression, the Montreal-based Royal Bank of Canada continued its growth and became the largest Canadian bank, as measured by assets ($328 billion as at October 2002) and market capitalization ($36.2 billion as at October 2002). It was also one of North America's leading diversified financial services companies. RBC Royal Bank was one of five major lines of business operating under the brand name of RBC Financial Group. The other four were wealth management (RBC Investments), insurance (RBC Insurance), corporate and investment banking (RBC Capital Markets) and securities custody and transaction processing (RBC Global Services).Page 2 98058001 Growth was important to RBC to retain its market leadership. With the entrance of much larger international banks into the Canadian market over the past decade, growth had become even more of a priority for Canadian players. The plan for Royal Bank of Canada to grow by merging with Bank of Montreal was suspended when Canadian Finance Minister Paul Martin rejected the proposal in 1998. Martin believed that the newly merged bank would be a giant of unacceptable powers. The ban was set to be valid through to September 2004. Because of the blockage of the merger, RBC had to find other growth avenues to remain competitive. One way of remaining competitive was by reducing operating costs through corporate downsizing. In November 1999, RBC announced plans to cut costs by $400 million and lay off 6,000 employees by 2001. Growth expansion into North American markets was a further strategy for the bank. A key decision made by Gordon Nixon, as new chief executive officer (CEO) of Royal Bank of Canada in 2001, was to globalize the brand by changing its name from Royal Bank of Canada to RBC in order to signal its goal of competing in global markets." Although seven U.S. banks had been acquired by 2002, the need for RBC to enhance its efficiency in domestic operations was never more urgent. In fact, operating efficiency at home was seen as a prerequisite for RBC to compete in international financial markets. One key to higher operating efficiency was to further leverage technology to automate and streamline business processes. Information Systems at RBC Royal Bank By 2003, it was next to impossible for banks to operate without information technology. The products and services available in a bank simply could not be delivered without retrieval of timely, accurate information. It was 1961 when RBC became the first Canadian bank to install its own computers. By 1967, RBC was also the first mover in the Canadian banking industry to provide computer-processed customer transactions (c.g. a deposit). Later, a new channel to serve clients was introduced into the banking industry. On July 28, 1972, the headlines in Toronto newspapers read: "Tomorrow morning at 9 a.m. the Royal Bank will open and never close again", as 14 automated banking machines (ABM) called Bankefte were installed in Toronto. In 1980, RBC launched a nationwide automated banking machine network along with a large-scale ABM installation initiative to locate a minimum of one ABM in every branch. By 1985, each ABM processed an average of 10,000 transactions per month, which exceeded the most optimistic expectations of management at the time. In 1994, Royal Direct offered an "at anytime, from anywhere" telephone banking service powered by its telecommunications centre in Mississauga, Ontario. So, even prior to the era of Internet banking (starting in 1995), RBC had multiple channels through which clients could choose to do business with RBC. Physical branches were no longer the only medium through which RBC provided products and services. One challenge of these multiple channels, however, was the lack of integration between them, as each channel had established its own processes and supporting technology. For example, RBC's ABM channelOne challenge of these multiple channels, however, was the lack of integration between them, as each channel had established its own processes and supporting technology. For example, RBC's ABM channel provided the capability for clients to identify their accounts by number (e.g. chequing account #1). But this information was available only when using the ABM network, so when the client came into the branch and The name Royal Bank remained part of the retail and commercial banking business, which became known as RBC Royal Bank. "RBC Royal Bank boosts availability of online banking. " IBM website, www- 306 ibm. com/software/success/essdb.ns//CS/NAVQ-5052JJ?OpenDocument&Site=default, accessed August 18, 2004. Page 3 98058001 asked the CSR to make a deposit to their chequing account #1, the CSR was not able to tell to which account the client was referring to. CSR Financial By 1989, approximately 6,000 personal computer (PC) workstations were installed in RBC's branches across Canada to support CSRs. RBC's current teller system, CSR Workbench, was developed in the late 1980s. It ran on a DOS platform using a keyboard interface. The system consisted of separate applications for client financial transactions (CSR Financial), foreign exchange (RFX), maintenance transactions, client demographics and account inquiries. Since DOS was not a multitasking operating system, it was impossible to run multiple applications simultaneously. Most transactions often involved multiple aspects of the overall system. For example, if a client came to the branch to do a transaction but forgot to bring their account number, the CSR had to open and close two applications to complete the task. First, the CSR had to close the current application for banking transactions and open an application for searching names. Once the account number was identified, it was written on a piece of paper, and the application was closed. The CSR would then reopen the original application in order to post the transaction. Foreign currency transactions were also processed using a separate application called RFX (Royal Foreign Exchange). If a client had included a U.S. cheque or U.S. cash in their deposit, the CSR would have to go into the RFX application to convert the U.S. currency to its Canadian equivalent, close out of the REX application and open CSR Financial ina U.S. cheque or U.S. cash in their deposit, the CSR would have to go into the RFX application to convert the U.S. currency to its Canadian equivalent, close out of the RFX application and open CSR Financial in order to post the deposit. Even for simple transactions, the need to go through multiple applications (or application components) was high. For example, about 80 per cent of clients asked for a balance before proceeding with a transaction. But checking the balance of an account represented a different sub-system than processing a withdrawal. Thus, even a simple withdrawal transaction required two distinct steps. CSR Financial was the transaction processing application that had been used by the bank's tellers for the past decade. During this time, the bank's focus had been on deploying new hardware and software to support the sales organization and to enhance the capabilities of the retail banking sales force. CSRs continued to live in the text-based world of DOS, affectionately referred to as the "green monster," using nine-inch monochrome monitors. At the same time, however, the demands on CSRs had changed. By 2003, the CSR role had become a blend of service and sales activities, and CSRs had specific sales targets to meet. Instead of merely executing transactional banking, CSRs were also expected to promote various banking products to clients and to refer clients to personal bankers for other products (e-g. mortgages, investments, financial planning). Their sales activities were supported by RBC's CRM (client relationship management) technology that centrally generated potential sales leads to the desktop. The CSR desktop had been adapted to assist with this process, using a 39-character field to highlight "offers and opportunities" that could be used to identify client needs. However, the limitations of the field display provided only minimal information, and CSRs could not update the field once they had discussed the offer with a client; as a result, the same offer might be made to the same client numerous times, resulting in frustration for both clients and CSRs. Page 4 98058001 Organization of the Information Technology FunctionPage 4 98058001 Organization of the Information Technology Function RBC's IT function was staffed by approximately 2,000 employees. IT operated as a functional unit within headquarters of RBC. The unit was responsible for maintaining the overall IT architecture of RBC and for developing technology solutions to address business needs. Three processing centres across Canada housed the equipment for transaction processing. Three centres were used to mitigate risk from having highly centralized processing and to facilitate local processing due to the time zone changes that existed across Canada (see Exhibit 1). Various groups residing in the business units designed business processes and provided IT with the business specifications and user requirements for technology-based solutions. For example, the business & information solutions (bis) group, managed by Cooper, had responsibility for all the front-end technologies in use at RBC Royal Bank (see Exhibit 2). This included information systems and information technology used by sales and service personnel, CSRs and the bank's call centre agents. While the IT function at RBC undertook the technical work related to these systems, the bis group owned the financial and operational side of these systems. For the bis group, the IT function was their key partner in realizing the benefits of information technology in order to achieve business goals. THE SERVICE PLATFORM PROJECT The Service Platform project was one of numerous transformational systems projects underway at RBC in 2003 designed to create a comprehensive c-business architecture. Another initiative related to digital imaging - scanning and storing cheques and other documents for immediate on-screen retrieval by employees and for online banking clients. Several transformational initiatives revolved around straight- through processing and system integration that would share client information and data between applications in order to streamline product fulfillment processes. The genesis of the Service Platform project could be traced to late 2000, when Rod Pennycook, executive vice-president - RBC Banking, was looking for a way to reduce RBC's proof processing costs to that of its competitors - BMO Financial Group (BMO) and TD Bank Financial Group (TD). Further investigation resulted in the realization that RBC incurred higher costs because RBC did not follow the same proof process as TD and BMO, resulting in increased work effort by Symoor, the outsourced proof processing partner common to all three banks. The RBC proof process differed in that it included both debit and credit items (e.g. cheques, deposits and general ledger vouchers, resulting in mixed proof), whereas the other financial institutions had removed all credits and purified their proof to cheques only, making it easier and cheaper for Symcor to process on their behalf. In addition, RBC used general ledger (GL) entries extensively in order to balance the proof However, these vouchers added to their processing costs. Significant savings could be realized if RBC could eliminate the use of GL entries and remove the credits from the proof.could eliminate the use of GL entries and remove the credits from the proof. The RBC proof process required the preparation of paper deposits and withdrawals. Ron Brandow, semor manager of RBC Banking business & information solurions, described the process as follows: For example, when a client comes into the branch to make a withdrawal, we prepare a manual withdrawal slip and request the client to sign it as recond of funds withdrawn, The CSH. using CSE Financial, posts the withdrawal to the client's account, draws a line through the withdrawal slip to confirm the transaction has been posted and then places the Page 5 SBOSEDD1 withdrwwal slip in the bundle of work destined for the reconciliation centre. The following day, the centre verifies accurate posting of the transaction. Our challenge was to figure out how to get out of this manual process. Other banks had reduced their costs by taking all their credits out of the proof. So basically they were sending down a batch of chegues, with one credit at the back of the balanced proof batch. This approach made it easy and less costly for the Symcor proof operator to run and balance the batch. Brandow questioned: How can we get ourselves from this mixed batch of debits and credits and the need for GL entries to a process that 15 paperless and is punfied? Cooper and her team recognized that the saving associated with less proof processing, elimination of stationery and less storage and retrieval of documents not to mention the benefits of integrating RFX and CSR Financial, which could also be accomplished in this project would make a beautiful business case. However, a DOS-based computing environment just could not enable such a change. Brandow commented: DOS is too old, and there is no way we can change the existing system. You know, it's not going to be supported by Microsoft much longer. DOS 15 too old, and there is no way we can change the existing system. You know, it's not gomng to be supported by Microsoft much longer. Thus, RBC had to upgrade both the software and hardware at the branch level in order to significantly reduce the cost of processing manual entries. Yet, this was not the first time for RBC to contemplate upgrading information systems at the branch level. In 1996, a previous attempt was made to replace DOS- hased applications with a system mnning on [BM's 052, This was an ambitious project, which would completely overhaul the suite of applications used by CSRs. It also encompassed significant changes in process, driven by particular business prionties. For instance, instead of relying on signature cards to identify themselves, under the new system, clients would swipe a bankcard and enter a personal identification number (PIN) through a customer interface terminal (CIT) to confirm their identity. This change was part of a new function of fraud management that had been added into the system. The pilot test went well in Vancouver, but the project encountered tremendous resistance from both CSRs and clients when launched in Ontano. First, the speed of O5/2 was slower than that of DOS, and CSRs were dissatisfied about degradation of service times to their clients. Moreover, the concept of \"swipe and PIN was relatively new in 1996, and clients at that time were not accustomed to this procedure. Offen they would forget their card or their PIN. Even if a client was well known to the CSR, the preferred way of completing the transaction was with card and PIN. At that ime, Kathy Cooper was vice-president personal banking. Based on her operations background and knowledge of the in-branch processes, she was asked by the executive sponsor of the project to assess the viahility of continuing with the 052 implementation. Cooper observed that implementation was being resisted for what appeared to be good reasons: the software stll had flaws, although the technical pilots had been launched in spite of this problem in order to have some deliverable out to the branches. Moreover, the development process had taken longer than anticipated, and [BM was moving away from 052, While these changes in information systems were meant to be beneficial for CSRs and clients, they proved to be too advanced. CSRs could not rely on the performance of the application, and clients were required to change therr banking behaviors too dramatically. Thus, Cooper felt they had no choice but to unplug the project. Page 6 98058001 Other proposals to upgrade the DOS-based CSR Financial application over the ensuing years were no longer given priority as the focus had shifted to providing technology capabilities that would enable the acceleration of the organization's sales culture and sales capabilities. Project Initiation The business case for the project was approved by the board in November 2001. In addition to the improved efficiency of proof processing, the project promised several additional benefits: simplifying branch transactions, ensuring errorless transactions, and enhancing sales and service support. A key part of this was unifying clients' banking experience across different channels. As Cooper noted: When we talk about channels, we are talking about trying to get to, from a client's perspective, the same experience regardless of choice of point of entry into the organization. Right now, it's different. If you decide to do business through the call centre today, it's a different experience than if you went into a branch. We are trying to make that consistent. Numerous costs were required to fulfil the project - new hardware and software, as well as the time of various bank personnel on the project team - in total, the project was estimated to cost around $50 million. Initial estimates, however, showed a favorable business case with an annual savings of between $12 million and $15 million with a payback on the investment within four years, well within the bank's hurdle rate. Selecting a System Initial investigations by Cooper's team, as well as by the IT group at RBC, identified four possible approaches to sourcing the system. The first one was a packaged solution, which came from a U.S. vendor. The vendor was a niche player, specializing in teller solutions software, with thousands of implementations completed in the United States and Europe. The vendor was capable of developing the system in a guaranteed time, and the product seemed to fit well with the needs of the CSRs. Nevertheless, the architecture of the system was server-based while RBC was moving away from this very architecture. In addition, the U.S. clearing system was very different than Canada's and it would require great efforts to Canadianize the software. These were the two major concerns that the bis group had with the option of working with this U.S. vendor. Internal development was the traditional mode for RBC and, indeed, for most Canadian banks. In U.S. banks, approximately 80 per cent of the software was purchased; in Canada, about 80 per cent was developed in-house. Building the system internally would allow customization to the specific needs andbanks, approximately 80 per cent of the software was purchased; in Canada, about 80 per cent was developed in-house. Building the system internally would allow customization to the specific needs and experiences of the bank and would produce a system that was tailor-made for RBC. However, in-house development had a high risk in terms of meeting timelines for deliverables. A proposal from IBM would see the system developed in that company's WebSphere platform, a set of Java-based tools that allowed developers to create and manage sophisticated business web sites. WebSphere was designed for use across different operating system platforms, and it also included Studio, a development environment with additional components that allowed web pages to be created and managed. Even though IBM had completed some small projects using WebSphere (including one with RBC), IBM Page 7 98058001 was keen to complete a larger project for a strong reference client. The proposal put the bulk of the actual development responsibility on IBM, with responsibility for requirements analysis, using their Rapid Application Centre (RAC) process, shared between RBC and IBM.' The bis group would maintain primary responsibility for business requirements of the system. Integration of the system with other RBC applications and testing would largely fall to the IT group at RBC. It was projected that after the phase of system integration and testing (SIT), the end product would be ready for implementation in September 2003. Implementation and training would then be the responsibility of the bis team (as was the case with all the options considered) A final proposal was to port the existing systems from DOS to Windows NT, using offshore resources. This approach would also provide a relatively inexpensive alternative that would update the software but would not provide additional functionality. Thus, it was rejected early on. After completing a request for proposal (RFP) the IT group strongly recommended the IBM solution. This was the very first time that RBC embarked on a large-scale project that involved extensive participation from the vendor side. IBM was selected as the vendor, and a project timeline (see Exhibit 3) was constructed.Hardware Selection The hardware requirements for the new system were also significant. There were over 8,000 wickets in the bank's 1,100 branches; each wicket had a PC with a monitor, a keyboard and a printer. All these would have to be replaced. Pre-installation branch visits to each site were conducted between August 21, 2002, and April 30, 2003, to investigate ways of fitting new hardware into the current work environment. Cooper recalled: We had no good inventory of what was already out there. So we contracted with a vendor who went out and visited every single branch and took pictures of where the existing equipment was installed, confirmed how many CSRs, including full and part-time were working, how many actual wickets they had in use and that we needed to equip. The team also learned that there were numerous counter configurations throughout the branch network. Some branches were 50 years old, and some were as recent as five years old. Layouts and surface materials varied considerably. Brandow knew that a few years ago, BMO had experienced similar problems when launching an information system upgrade. In their case, BMO renovated every branch because there was no other way around it. Their counters were designed specifically for nine-inch screens. For RBC, remodelling all branches was not critical to the success of the implementation as Cooper's team had already decided to purchase hardware that was of industry standard size. Project Leadership The project leadership entailed two distinct groups: the project team and a steering committee led by the executive sponsor, Rod Pennycook. "RAC was an IBM methodology for gathering business requirements in an application-centred, rapid approach by putting IT professionals and business professionals together in a common space to facilitate a close, intensive working relationship to drive out business requirements and accelerate the pace of delivery.Page 8 98058001 The Project Team Cooper counted on the expertise and talents of her team members to help design and execute the implementation plan. The core members of Cooper's team included Ron Brandow, senior manager of business & information solutions; Jan Bremmer and Liane Stangenberg, program managers service platform RBC Banking bis Group; and Janine Hayworth, program manager - RBC Banking bis Group. Brandow, like all other team members, once worked as a teller at the bank. He had previously worked in the bank's audit function, and he became involved in the service platform project in 2001, conducting the benchmarking of proof processing against other financial institutions. Jan Bremner was the software lead with responsibility for managing the design and implementation planning of the software component. She also created and managed the CSR Advisory Council, which had been put in place to provide user feedback and input as RBC went through the software design process and training tool development. Liane Stangenberg was the hardware lead on the project with responsibility for providing the hardware specifications, overseeing the pre-installation visits and inventory database, and implementation planning Both Bremmer and Stangenberg were also to play key roles in the design and development of the training program and in the training of the various support teams that would provide telephone support to the CSRs once they were using Service Platform. Janine Hayworth was assigned as overall program manager and developed and managed a fully integrated project plan to include design, development, testing, training, communication and implementation. She facilitated weekly status meetings, issues tracking and escalation. The Steering Committee A steering committee for the project, including members from both RBC and IBM, met monthly to review the status of the project and deal with critical decisions. Exhibit 4 shows the members of the steering committee. Cooper and Irene Sobolewski (senior vice-president - RBC Banking Technology) were given a discretionary limit to approve costs associated with scope change requests (SCRs) if both agreed. SCRs that had costs beyond this discretionary limit had to be approved by Pennycook through this executive steering committee. Financial reviews of the project were also rigorous, to ensure costs and scope remained in line with the approved business case. Project Progress To expedite the development of the new information system for RBC, IBM brought from India 17 systemdevelopers. It was a long haul waiting for the approval of their work permits, due mainly to raised concerns for security in North America after September 11, 2001. As soon as the system develops arrived in Canada and started to work on the service platform project, the speed of system development was significantly boosted. RBC was very satisfied with this offshore sourcing arrangement. Although RBC was responsible for the salaries and cost of living of the developers, the total cost for the human resource was still more economical and timely than acquiring local expertise. Page 9 98058001 By June 2003 the development effort was well in hand. Problems had emerged as development proceeded, but they had largely been resolved. The biggest "surprise" for the bank occurred in January 2003 at the Commitment to Deliver (CTD) milestone for the project. The project costs had ballooned by 50 per cent between signing the Document of Understanding (DOU) and reaching CTD. The initial estimates for developing application interfaces had been too low because IT had not taken into account the cost associated with interfacing to all required systems. After this additional effort was taken into account, the full cost was determined to be higher and the development time longer. Cooper worked closely with Pennycook, along with Sobolewski and Marty Lippert, chief information officer (CIO) of RBC, and senior management at IBM to expeditiously resolve this issue. A reassessment of the business case, in light of what had been learned so far, determined that the project was still very feasible. Aggressive price negotiation on the hardware costs had reduced the initial cost estimates, and the capitalization period for hardware could be extended to six years from the original four. With these changes incorporated, the project was rebaselined, and the business case was still found to be compelling Managing the scope of the project had also been a challenge. After some debate, it was determined that integrating paperless e-bill payment into the initial development of the system would be considered as a future phase. As long as bill payments were handled separately from other transactions, the costs of processing at Symcor would remain higher. But including e-bill functionality into the system would add significantly to the project time line. Thus, e-bill payment was put on the back burner and planned for development in 2005. System testing began to reveal some problems in usability. As Brandow humorously noted:Case Evaluation Rubric (with Grade Breakdown) for Individual Case Stud W Grading Range! Alternative Solutions Analysis of alternatives Recommendation with lustification Quality* of PowerPoint Slides Mormally two, three or four issues. For each issue make sure you identify how you would measure whether or not you have addressed the issue. Minimum three/four reasonable mutually exclusive actions designed to address the issues raised above. Try to avoid \"Do Nothing\" as an alternative. Be creative. You can ignore case period if reasonable. You should do both qualitative and quantitative analyses for each alternative (independent). Use additional slides if needed or use the 'Note Section' of the slides. Should be one of the alternatives from above. Compare with the other alternatives to justify your selection. Make sure your recommendation (one or more alternatives mentioned above together) meets all the key issues mentioned in step 1 above. Excellent Quality > 90% Superior Quality >89 - 75% Average Quality > 60 - 74% Poor Quality 50% 90% Superior Quality >89 - 75% Average Quality > 60 - 74% Poor Quality 50% 89 - 75% Average Quality > 60 - 74% Poor Quality 50% 90% Superior Quality >89 - 75% Average Quality > 60 - 74% Poor Quality 50%