A Leadership Journey: The Working Years (Part 3 - RBS2GSI)

Given the basic premise of the takeover, the teams from the RBS heritage always knew that the first step of the entire programme was to provide the scaled-up environment in production, designed to be capable of supporting multiple brands with the same underlying set of systems, and proven to be effective by running the existing RBS business on the new environment. The new environment was the Group Systems Infrastructure (GSI), so the first step was to move RBS to GSI – hence the programme name RBS2GSI.

Dave Smailes was delighted, and told me I had carte blanche to go ahead and do everything I wanted to do to turn my vision into reality. He brought in a contractor (Clive Yandall) as Applications Programme Manager, and defined my role as Test and Implementation Manager. Clive was quite happy to attend the governance forum and let me get on with doing the work. My counterpart in the infrastructure world was Paul Gibson. He reported to the overall Programme Manager, but had a similar remit to mine – he had been brought in by IBM to ensure the job got done. He had the specifications for all the kit that was needed, and the majority of it had been delivered, but no-one could say how we would get it all operational – to have the applications running with customers’ data.

This all came to a head in the summer of 2001, at a large workshop in one of the former RBS offices at the south-west corner of St Andrew Square. I had reviewed with the mainframe Storage team the use of the “swing” DASD that had been brought in for Y2K as a means of copying all the mainframe data from one environment to another for testing, and had extensive discussions with the ISMs, and through them, the Partition Managers about preparing for testing. With this, I came in with an embryonic approach to getting data from old systems to GSI systems for testing, but it required a full-scale test environment, as I needed referential integrity across all the data (with a few problems still to be sorted about the 24x7 systems). That’s when we made the crucial break – Paul offered me the production kit, to use as my test environment, and with that, all the pieces of the puzzle fell into place.

We would use the “swing” DASD to get a full snapshot over to the new environment, which would have all the scaled-up applications installed, and pre-production versions of other systems that connected to the IBM mainframe. We would do the checking of the applications in the same way as we intended to do after the production migration. This in turn became the template for the production migration – the same process of swinging over, connecting (this time to the live network) and checking would be the best way to implement into live use.

Although I wasn’t aware of it at the time, there was another aspect of leadership coming into play – having set out the vision, engaged the people and got their support, I had established a working environment where people felt able to contribute ideas. At the time, there were no “right” or “wrong” ideas – every contribution took us closer to the goal, either because it made the process slicker, or because it made us think through the reasons why something could go wrong, and work out how to avoid it. This meant the details of how to accomplish all this started to flow, and we quickly established that we would have 4 weekend events, plus a 5th for contingency. I can’t remember the exact details (anyone reading this who can remember, please supply them) but the general idea was to go progressively further each weekend, with a week to review logs, to find and fix any problems. It was along the lines of:

1. Swing over, start up, run application checks (capturing logs), then stop and swing back
2. As for weekend 1, but run in live for an hour or two before stopping and swinging back
3. As for weekend 2, but running overnight on Saturday, before stopping on Sunday and swinging back
4. As for weekend 3, but without stopping – instead leave it all running in live

As can happen in such massive and complex implementations, there was a problem on the 4th event, so we backed out, and went live on the contingency weekend. Since the committed date had taken account of the contingency, the outcome was general elation. This was the first major milestone of NatWest Integration, and we’d made it on time, without impacting customers.

At the celebration afterwards. I noticed that Mark Fisher was now able to pronounce the S in RBS, whereas previously he had referred to Royal Bank, RB2GSI, and so on. It was a small shift, but for me it was an important detail that indicated a shift in Mark’s perception of the teams he had acquired – a perception that became crucially significant later in the Programme.