The Bank Wins (2)

Transitioning a company’s entire IT environment to a new platform is no trifling matter. The same held true for the project at Zuger Kantonalbank (ZGKB): In addition to some 380 future users, at peak times, more than 200 employees of the four project partners were involved in about a dozen subprojects. The project team customized more than 200 interfaces and put nine modules into operation. “Under these conditions, a project can succeed only if objective definitions, assignments, procedures, and the resulting contracts are jointly agreed upon,” stated Beat Mathys, the member of ZGKB management who holds responsibility for the project. “At the outset, it must be clear which delivery items will be accepted using which procedures.” During the project, it is very tempting to include small enhancements and improvements everywhere. “You can’t allow that to happen. The trick is to concentrate on the important things without blocking future opportunities,” explained Teddy Keiser, director of finances.
Tried and tested methods are essential for the success of a complex project. In addition to planning and managing the entire course of the project — consisting of project preparation, business blueprint, implementation, production preparation, system acceptance, and production — it is important to consider a number of aspects that are often underestimated. Project preparation requires time and careful attention. Time invested well at this stage is more than made up for when the project is in progress. In addition to project definition and selection of partners, preparation activities include data cleansing in the legacy system and updating of documentation for system and bank operations. The auditing department should be included at this point to avoid the time-consuming corrections needed to add its input later.

Software Projects Are Top Priority

Despite all diligence, however, new questions are inevitably raised, questions that require the establishment of quick escalation and decision-making processes. To this end, during the project at ZGKB, members of the boards of all companies participating in the project were represented in a steering committee. Furthermore, an IT committee met weekly to decide upon issues as they arose. Members of this IT committee included CSC and ZGKB project managers, SAP, the bank’s quality manager, the director of integration, and representatives of all three departments. The committee was headed by ZGKB executive board member Beat Mathys.
To get the project on the right track at the outset, subprojects and their integration were the direct responsibility of overall project management. During implementation, however, departmental aspects and integration became the main focus. ZGKB accommodated this shift by adapting its organization to the project’s progress and by combining the technical teams, development teams, and test management.

Organization Charts
Organization Charts

One of the most critical objectives at KGKB was to avoid jeopardizing the viability of the new platform’s release through in-house developments: The SAP standard should be sufficient. To meet this requirement, the IT committee had to approve all deviations from plans, project definitions, and customization of the standard software.

Communication Reduces Uncertainty

If — as in the case of the project — the processes and workflows of an entire bank are altered, the importance of communication within and from the project cannot be underestimated. Along with establishing factual information, emotional issues related to the fear of change are a significant factor. “Transparent information helps alleviate uncertainties that would otherwise lead to blockades,” Beat Mathys explained. For this reason, a ZGKB team was dedicated to communication right from the start. This team published a brochure at regular intervals, organized events, and narrowed the information gap between project members and future users.
Moreover, ZGKB formed a change management team that prepared user training and organizational adaptation of the bank to the new platform. These changes affected processes, infrastructure, company organization, and of course employees. In the project, change management adapted processes, work instructions, and authority structures to the changed requirements. It was responsible for user training, test management from the bank’s perspective, and finally, for the actual system transition.

Banking Professionals and IT Gurus Speaking the Same Language

The most important aspect of an SAP introduction in a complex bank system is the integration of numerous interfaces — and not simply in a technical sense. It’s just as important to match banking-specific knowledge with technical know-how, and to coordinate the various subprojects. For this reason, representatives of each field established individual processes in elaborate workshops and created overall plans across various areas of expertise. In the process, banking professionals and IT specialists learned to develop a solution that was understood by both sides and served as the basis for the new platform.
It was also important to avoid resource conflicts. Shortly before the new platform is introduced, the presence of key individuals involved in the project is required at several project sites simultaneously. To improve this situation, it is important to get an early start on tasks such as development of training materials, training of trainers, and creating test scenarios. Conversely, it’s also vital that the project knowledge be disseminated to a segment of the future users, so that they can offer support during testing and migration.

One-Hundred Percent Quality

Customers expect a bank to provide one-hundred percent quality, which is why the tests conducted in several steps over nine months were of great importance. ZGKB initially tested isolated functions of the platform. The bank subsequently expanded these tests, including comprehensive integration tests with a full data set. These also included year-end tests and non-functional tests: system stress tests and catastrophic scenario tests. The actual cutover was tested as well. In parallel with the testing, dry runs of data migration were conducted and refined.
Preparing and running the tests is highly demanding because external systems such as the stock market, currency market, payment transactions, and automatic teller machines must be included. Date changes must also be considered. Moreover, glitches during tests just come with the territory. “Therefore, the test environment should be flexible enough in terms of technology and resources,” recommended Alexander Wüest, director of change management. “In addition, time must be allotted for adverse situations, such as multiple rebuilds of systems.”

The Entire Bank Played a Part

During the decisive final days of the project leading up to its going operational at Easter 2002, it became apparent that communications efforts and change management had been successful. All of the bank’s employees supported the project team with great enthusiasm. Almost no glitches occurred; the few shortcomings that remained resulted primarily from handling errors in IT or banking operations that could have been prevented by improved knowledge transfer from the project to the company. “A project of this scope just isn’t completed on the day it’s introduced,” so the summary of Zuger Kantonalbank.

Manfred Philipp
Manfred Philipp