In just 2.5 years, SBAB has done something few other banks have achieved: it’s phased out its old legacy banking system, modernized its architecture, and gained better lead times. We took the opportunity to talk to Klas Ljungkvist, CIO, about how they tackled the challenge. How SBAB addressed needs continuously, from agreement type to processes, simply because it was the right thing to do is both fascinating and refreshing. Strap yourselves in and let’s go!
(This article is also available in Swedish here)
Key recommendations
Knowing what you know now, what are the key recommendations you’d give someone who’s embarking on a project similar to the one SBAB undertook?
Well, a few things.
- Be prepared that it’ll hurt, but that it’s necessary. This kind of project isn’t easy! Don’t underestimate the lead time in getting new systems in place in terms of infrastructure and non-functional requirements.
- Strive to make big things small, so that you can finish off different parts one thing at a time.
- Find a supplier who’s a good ’cultural match’ – a supplier you like.
- Create a sound collaboration with the organization you’re building the systems for. In our case, we integrated operations experts with our teams.
- Start on time. And prioritize like mad once you’ve decided to rock’n’roll.
Success factors
A number of banks have tried to implement shifts similar to this, but with limited success. What do you think made you successful?
A number of things, but I would highlight:
- Willpower and acceptance among managers and the Board of Management
- The fact that we have learned and adopted throughout the project. There’s been a continuous will to improve across the board, including on part of the suppliers.
- We’ve had an ongoing focus on what we’re willing to deprioritize in order to achieve our goals. For us, this meant an increased focus on scoping down throughout the program – in order to be ready on time.
Key improvements – before and after
If we look briefly at architectural capabilities, without getting lost in technical stacks, which capabilities have improved since the shift?
Flexibility, lead time and reliability have made huge strides.
- The entire banking system change has meant that we’ve been able to replace a monolith with an integration layer based on microservices. As a result, we can now act startlingly fast, which is showing in our lead times.
- We’ve managed to mothball a number of systems, such as our administration system for corporate business and the core banking system.
- Alongside the aforementioned efforts, we now have much improved data management. We’re close to being able to scrap our old data lake. Full credit to our data science team for that work!
THE JOURNEY – THE NITTY GRITTY AND THE PROCESS
So let’s go back to the beginning. What made you realize that there was a need for the modernization project ‘Surtsey’?
Back in 2015/16, we realized that we were working with ancient platforms that were slowing down flexibility and progress. We also had an issue with robustness and reliability – what I like to call ‘a tricky legacy situation’.
We decided to do something about it. The first step was to create a new IT strategy in order to paint a new, clear picture of our goal. Part of that strategy was to retire our old legacy system – including core banking system, loan payable system, administration system for our corporate business, data management and credit onboarding – and introduce a smoother integration between the core system and various applications.
About goals and timeframes
Would you mind shedding a bit of light on your effect goals goals?
The overall goals were long-term survival and competitiveness. With that in mind, we set a few impact goals for the shift. One was ‘halved lead time in development (from priority to production)’. We had a benchmark from 2017 of 36 days and did temperature checks on the lead time throughout the project to make sure that it was trending in the right direction.
Today, we’re very close to our goal, with a lead time between 15 and 20 days. In fact, the progress we’ve made means that we no longer set lead time goals but follow up continuously as a KPI instead.
One of the key factors behind the halving of the time was the creation of a microservice-based integration layer, in place of the monolith we had previously.
What was the timeframe for the initiative?
We were a little optimistic when we first started, and thought that we’d be able to have the whole thing in the bag in the space of three years. Considering the extent of and ambition for the project, it became obvious pretty soon that it wasn’t something you do that quickly
Take the core banking system as an example. Our original prognosis was that it would take 1.5 years, but in reality it took 2.5 years.
How far into the project did you need to get in order to make a reliable prediction of the completion date?
Looking at the core banking system again, we divided the shift into two incremental steps – Payment and Saving – the first of which we got a grip on fairly quickly and executed with decent precision. The latter was trickier, and it wasn’t until around 1.5 years before completion that we could say we had a prognosis of reasonable certainty.
About the user experience
Shifts like these can easily get tech-heavy, resulting in a compromized user experience. What did you do to make sure that the resulting user experience was decent and not degraded?
We set a boundary condition early on: for the end customer, there should be no difference – and we’ve basically achieved this. In addition, we had an impact goal for the administrator user experience not to deteriorate, and to have the conditions in place to correct it should the experience somehow worsen.
We’ve had our victories and our struggles. Certain functionalities have improved, but we prioritised sticking to the timeframe to be able to put the solution into operation in the first place, which meant that we had to give up on some administrator features. We did, however, succeed in the overarching goal of the conditions for upgrading the user experience being in place, which means that we can now address it step by step.
One factor worth mentioning when we talk about user experience is that we’ve never seen this as a pure IT project – our focus is on operational improvement.
As such, operational functions like finance, back office and administrators have been integrated, driving parts of the project. Operations experts joined both the existing Agile teams and the system supplier. We needed a functioning, close collaboration – something that, in retrospect, has been a key factor.
Could you give examples of areas where you’ve managed to improve the user experience?
We’ve been able to implement more functionalities for our users, thanks to our integrations. The increased operational stability should also be considered a step forward in terms of user experience; the old system had a tendency to collapse every now and then.
The ability to make sensible trade-offs is a central capacity in Agile projects. Which trade-offs did you make at the top level, in terms of prioritizing budget, time and scope, and how did they change throughout the duration of the project?
From the start, we prioritized:
- time, followed by scope, then budget.
Eventually, we adjusted this to
- time first, budget second, and then scope.
This was based on the assumption that time was the most precious factor.
About the project organization
You worked both internally and with the help of external partners to implement this shift. Roughly how many teams were involved in the project at its peak?
In the program as a whole, there were four to five Agile teams with a focus on development. Alongside these, operations functions including finance, accounting and back office were also heavily involved and integrated.
Can you tell us about the roles and responsibilities you took as a client, and which roles and responsibilities the supplier took?
Focus areas and roles varied throughout the project period.
Phase 1: Introduction
We started with very thin project management above our Agile teams and a fixed-price agreement with our supplier. The net effect was that the supplier kept rushing towards the requirement spec in the agreement, even in the cases where it had become obsolete, while our internal start-up time was longer and we struggled to keep up. New external factors meant that the original requirement spec no longer matched our priorities, and the agreement we had wasn’t flexible enough to handle that.
Phase 2: Finding a common pace
We applied slightly heavier project management and worked to clarify roles and responsibilities. We also changed the agreement to ensure that we could move at the same pace towards shared goals. In short, this meant a shift from per-function payment to a shared framework for cost and time. In terms of execution, it worked much better as we now had the flexibility to act together, with a shared pace and delivery rhythm, in response to changing conditions.
Our Agile teams, however, felt spoon-fed with this set-up, so the next step was to find a more balanced project management approach in order to give them more responsibility and initiative.
Phase 3: Change in mandate and growing delivery capacity
In the third phase, we tried to find a midpoint between the project management approaches of phase 1 and phase 2. We worked hard to empower our Agile teams, which had at this point built up knowledge and ability. We made improvements that allowed us to continuously improve our joint delivery capacity, which was reflected in declining lead times and increased initiative among our Agile teams as well as with our system supplier.
That sounds easy, but for teams to develop initiative and responsibility, all while there are strict delivery expectations, is anything but simple.
That sounds easy, but for teams to develop initiative and responsibility, all while there are strict delivery expectations, is anything but simple. What were the key steps between phase 2 and phase 3?
A few things worked in conjunction. Firstly, as mentioned, we moved away from the fixed-price agreement to an Agile approach with a shared incentive to reach the goal. Secondly, we stimulated both the Agile teams and operations to boost initiative.
Another shift that I believe was crucial during this phase was reshaping the project manager role into program management. Personally, I’m trying to spend more time on the floor as a coaching leader to keep an open dialog with program managers as well as teams and operations, with the aim of passing on greater responsibility.
About the Discovery process – from idea to development
What phases did you work through before the development started?
The first step, around 2015, before we got started was a feasibility study focused on describing the capabilities of the old system. The trick is to keep it at a reasonable level of detail. The supplier then based their original quote on this.
The next step was to divide everything up into smaller chunks.
What did you focus on throughout product discovery?
When we embarked on each phase, we started by creating an overview of the end-to-end value-stream flow, before going on to map out the use cases. When this overview was perfectly clear to us, we knew that the picture of needs was too.
Against the use cases we then mapped out user stories, which the teams worked towards. We continuously measured our progress in each phase against these user stories, and more often than not the variation in the number of user stories remained within 25%.
Name one important improvement you saw in your supplier’s process or organization throughout the journey?
We realized early on that the lead time was too long, which was a result of us doing things in too big batches, such as production settings.
We managed to work out a way for user stories to be put into production without impeding others. Little by little, the supplier learned to do this smoothly, and the result was that they halved their lead time.
You’re now in operation and the systems are in use – but the world rarely stands still. Could you mention something you’ll want to focus on moving forward?
We realized early on that the lead time was too long, which was a result of us doing things in too big batches, such as production settings.
We managed to work out a way for user stories to be put into production without impeding others. Little by little, the supplier learned to do this smoothly, and the result was that they halved their lead time.
You’re now in operation and the systems are in use – but the world rarely stands still. Could you mention something you’ll want to focus on moving forward?
We’ll continue our war on legacy. We’re currently very focused working on changing the system for loan payables (an old Cobol system) and credit onboarding.
Thank you, Klas, for taking the time, and best of luck on the journey ahead!
Interested in learning more about how they did it?
Here you can watch Maya Jernström present their way of working during the project in a video from the agile contracting conference >