Prior to my role at SSP, I spent 17 years “client side” working for a FTSE 50 insurance company. I was lucky to start my career, back in the early ‘90s as a fresh faced and eager junior analyst, coincidentally at the same time, the business was embarking on its [previous] IT transformation. The programme I was fortunate to be placed on was swapping out the creaking and very costly mainframe, with some new IBM mid-range infrastructure as well as updating the back office software, giving me the rare opportunity to gain such insight so early on.
After moving roles between group IT and business change teams, at various levels within the organisation, I ended up full circle years later as the programme director. Now tasked with the role of replacing the system I had once helped implement (now the legacy system), it was already time to change it with the next generation platform. If you blink, you miss it when it comes to technology it seems.
This second round of transformational modernisation was initiated following the drafting of a new 5 year plan, a ‘brand new’ strategy. BUT… it came with some brutal realisation. As I am sure is the case for most (if not all UK insurance companies), we were highly dependent upon our core system to support the running of the business – issuing and servicing policies, processing claims, underwriting, billing etc. the list goes on. The legacy infrastructure had proven itself to be relatively stable, reliable and with all those years of be-spoking, had become fully tailored, with many staff reaching the high esteemed position of ‘super users’. On one level we had a working solution, capable of handling the requirements of this highly regulated and document intensive industry, however the next wave of technology advancement was now upon us, customer expectations were changing quickly, and without investment we would struggle to keep pace.
Responsiveness to market conditions was the challenge. The legacy system was slow to publish rating changes, months rather than hours, and significantly longer for product changes. There were the known bottlenecks in data sharing and even dependencies on the manual re-keying of data between systems. These problems were previously accepted, almost considered the norm, but with an increasing focus on operational costs and customer expectations changing (and the competition improving), if our systems could not provide the services, price agility and advancements in communications needed, there was new breed of more agile insurers that could – we needed to keep up and fast!
‘Speed to market’, ‘digital capability’ and ‘service enablement’ were all key, and we were seemingly lacking… strategically this change was not about being disruptive, but mitigating the risk of losing market share in an ever changing environment. A legacy platform architected and developed in the ‘80s just wasn’t going to cut it anymore, in fact was increasingly becoming the blocker.
The need for change was clear, as was the scale of the challenge. It is notoriously difficult to write a compelling business case to replace a policy admin system, especially when following a claims [and supply chain] transformation programme, as the benefits are not so tangible or already counted. There was also reluctance from central IT, to tamper with these systems, after all they still worked (most of the time) and change brings around the unknown, but we had simply outgrown our existing IT capability… it was a case of change or “wither on the vine”.
Modernising and/or replacing the legacy system became the top priority. Consolidating the existing systems was also part of the brief, not a trivial task, especially when taking into account how many systems were involved and the level of customisation we had undertaken throughout the years. So we needed to carefully consider the level of disruption, risk and benefits before starting. Our options were:
- Modernise the existing platform
- Build a proprietary system
- Buy the software
After weighing up the business problems vs cost of ownership, functional coverage and capability, the time to implement and the speed of change (over many meetings and countless cups of coffee) we chose to buy. We did have a large IT department capable of building our own, or even modernising the existing platform, but we challenged ourselves to be honest (there was a lot at stake) and concluded the organisation is an insurance company not a software provider so couldn’t compete with the “best of breed” buying could offer.
- Next decision? How to do this: Big Bang – replace everything in one go
- Simplification – remove some of the complexity from the architecture and replace the core
- Preservation – leave the core systems and wrap with a modern layer of technology to introduce new functionality
- Phased - implementing new core technology in phases that will gradually grow to handle all applications
There are pros and cons to them all, and we chose a mix (of 3 and 4), as this was the most risk-averse option, not too surprising as the SteerCo was made up of insurance company directors! In fairness the approach did bridge the technology gap relatively quickly, and the phasing/stages enabled some early benefits to be realised – which were key to gaining group funding early on.
The programme itself took a few years to complete, and longer than planned, however was and still is a success today. The business case was mainly based around pricing and data benefits i.e. using the technology for improved risk selection and enrich data to simplify the buying process (plus the improved digital and speed to market benefits) and in the end these were easily achieved. The solution itself actually won an innovation award along the way, but most importantly loss ratios were down and GWP significantly increased year-on-year following delivery, but the journey wasn’t easy (it never is), as this is an intrusive process and there are always lessons to be learnt.
There were a lot of late nights, and as programme director, a lot of reading (emails and technical papers) and so many planning sessions (again all fuelled by many cups of coffee!) It was incredibly fast paced and I needed to keep abreast of all the moving parts, constantly obsessing with ways to enable informed decision making; quality; performance and productivity – “how could I inspire more”? Though my years in the trade had taught me how to deal with the peaks and troughs of project life, this transformation was seemingly all peaks, likely due to scale and urgency (there were £m’s were at stake, and I had an anxious board to report to). My personal life had almost disappeared, taken over by my compulsive desire to finish, the difference this time was how infectious it was for the team. We all shared the same goal and had bought into the vision. Down time was replaced with taking the team to the local pub to celebrate a win (however small), or offer support/sympathise over a tough week (nick-named “therapy”). Looking back, although challenging, these were also some of the most rewarding times I have experienced at work.
There are many papers written on what makes a good project, or why projects fail, and having worked on both sides of the fence, specialising in platform modernisations and replacements for many years, I have a relatively unique and balanced view on where the traps are:
- Have a strategy – one that’s right for your organisation depending on exactly what you are trying to solve (one that aligns to your technology vision)
- Balance both the benefits and the level of disruption you are prepared to accept
- Be honest about your organisational capability
- Minimise the use of unproven or immature software
- Do not fall for the trap of cheaper solutions to avoid costs, this will likely cost you more longer term
- Do not try to replicate what you already have – or there is no transformation, just a newer version
Don’t underestimate the complexity:
- Plan, plan and plan even more – have a plan that covers everything (not just the software change) and track the work and dependencies religiously
- Allow the correct time to implement – this is likely a 1 in 10/15 year investment, if you get it right
- It’s important that the project’s complexity is defined and adequate measures are taken to manage the risks
Use an experienced team (inc. management to oversee):
- Especially to manage the programme
- An experienced team will set clear goals, they will communicate regularly, and they will follow the project management method you set
- It’s key that the team know what the work is, and how to undertake it (at all levels)
- There will be challenges, and it will take a lot of effort, so a strong team with the ability to foresee and resolve issues quickly will be the difference between success and failure
Spend the time upfront:
- Define the required business capabilities, preferably detailed requirements
- Any requirements should be laid down properly, unambiguously, and systematically
- Remember when writing them that whilst delivering the business case is the noble aim, in terms of measuring project implementation success, delivering the detailed business requirements is the yardstick the project will be judged by
- If you are adopting an agile approach then know what the minimal viable product is, and stick to it
- Cut out scope creep from the start
- Get this right and you will spend less time overall
Focus on quality:
- Have a defined governance model and use it
- Quality control is key (both functionally and non-functionally)
- There will be defects, so find them as early as possible i.e. test left (don’t forget defects cost more the later they are found
- Build out your overall test strategy and test plan early, and include your test cases and the expected result for each one. The effort will be paid back later (in multiples) and you will deliver high quality final products.
Undertaking a legacy transformation project can be daunting, I know, I’ve been through it twice, but we have the right team on hand here at SSP to help you along every step of the way. To discuss further please contact a member of the team on email@example.com.
So… in summary: strategise; plan; don’t underestimate (complexity or effort); focus on quality and controls; and use skilled resources – it sounds so obvious and simple, but it’s easy to make compromises under the commercial pressure!
About the AuthorMore from Andrew Walters