Re-platforming, and particularly the cost of re-platforming, is a hot topic and rightly so. As this recent research shows, nearly half of all the advised assets under administration are in the process of transitioning from one platform to another. This equates to £226bn of people's pensions, ISAs and investments so getting it right is crucial.
These projects will often overrun, and when they do the inevitable headlines are around cost and delay. Ascentric were the latest in the headlights yesterday, with this this interview with CEO Jon Taylor a typical example. The comments below the line are also fairly typical with user "John Wrap" basically saying "how hard can it be" to move £12B from one system to another.
Unfortunately, these sort of articles rarely give the full picture. The vendor’s side of the story is rarely told. In most cases the project will be in flight and they will be contractually restricted from commenting. The project is usually framed as a migration exercise and the reality is almost always much more complicated than this.
"To be fair, it's pretty simple. If anyone says anything other than "replatforming is really hard" assume they are lying and/or an idiot."
...the tweet from @langcatmike succinctly puts it.
Here are my top 3 reasons that might drive up complexity, cost or timescales.
1. Adopt or adapt
A platform upgrade is a rare event, it's also an expensive event. This combination means that to justify the investment the client will often use the opportunity to re-evaluate the business and look for strategic, transformational change. This is a good thing in the main, often the underlying platform they are moving to will give them the foundations and capability for this change.
However, it can also open the requirements floodgates. Areas of the business that have not been able to get changes through (perhaps because the existing platform won't support them or maybe change has been embargoed prior to the upgrade) suddenly see an opportunity. Having effective control over change is key. Organisations that can manage this, prioritise effectively and manage the delivery of these upgrades incrementally will reduce the risk of time and cost overruns. Also vital is fully understand the capabilities of the platform and wherever possible align solutions around that.
Having to flex a platform to suit your existing processes rather than re-designing the processes to work with the platform can be very expensive. What can, and does happen, is that a project costed on adoption suddenly increases in cost as the vendors are asked to adapt/extend the product to support new requirements.
2. Assembling the jigsaw
There are usually lots of moving parts. Most of these projects are focused around a prime vendor (Bravura, FNZ, GBST etc) but in most cases the wealth platform is just one component in a wider IT infrastructure upgrade. It is not uncommon to also have 3rd party website developers, Document management, reconciliation engine, CRM providers, Trading platform providers and internal IT teams all working together to deliver the programme.
Managing the dependencies between all these work-streams is hard. Slippage in one area can have a big knock on effect on the overall plan. Incremental delivery, strong change control, automated testing and frequent releases into test will mitigate risk here.
3. Organisational capability
While this project is underway, the day to day business still has to run. Taking people out of the business to support the programme will impact operations, but if you don't have strong business engagement from the start, and a strong view of what the "to be" operating model looks like you can't effectively drive the programme and manage the vendors.
Often the client needs to get to grips with the capability of the system before the future state can be defined, and so the process needs to be responsive to change. Some of the larger operators will be used to large change programmes, and have fairly mature change processes. For smaller operators this will be a once in a generation event, and some are not prepared for the level of engagement and resource these programmes require.
Getting the right advice where you have gaps here is really important, be that in managing change, migration, defining the business model or delivering and testing the code. There are also lots of people with experience out there and it might not be the Big 4 consultancies that give the best value.
I'm sure the re-platforming debate will continue, and I hope we start to see a bit more balance and understanding in the reporting of the complexity of these projects.
It's not rocket science, but it's pretty close!
Talk to our Head of Finance Chris Neal to find out how Answer can help reduce the complexity of re-platforming.