IBS Journal Supplement 2015


client may end up being the guinea pig for the release. If possible, avoid dependency on major functional change introduced in a current release.’ Indeed, he gives AA as an example, with this introduced by Temenos in Release 8 of T24 and it being two to three years before the module was stabilised. Fanzott also advises against ‘trying something new’. There are tried and tested tools and methodologies, he says. However, ‘don’t copy and paste the legacy solution’. A new system is meant to industrialise your operations at the back end and improve competitiveness at the front, he says, so banks need to make best use of the processes and parameterisation of the new platform. Paterson agrees. ‘Despite the best


intentions of executive management to build the bank around the new system, the opposite often occurs. This can stem from vendor-led gap analysis where their focus can be understanding what the bank does now, rather than investing time in helping bank staff to understand their standard system capabilities and explor- ing how legacy processes and products can be reengineered.’ He also recommends that configuration and development is done onsite, despite the cost saving potential of offshore, because it tends to be more efficient, particularly where it turns out to be a reiterative process, with refinements over time. It is also important to consider the en-


‘Choose your partners carefully based on relationship, alignment of objectives and trust – not price, as the lowest


price is often a sprat to catch a mackerel.’ Andrew Ruffell, The Core Banking Group


tire IT landscape, not just the core banking piece. Ruffell explains, ‘all in-house and third party applications which will talk to your new core system need to be clearly defined, so too the migration plans for these systems and for any historical data that is being brought across. Report on this in a simple and transparent manner so that all participants and stakeholders un- derstand when anything falls behind and continually develop (Agile) contingency plans for any delays or failures.’


Conclusion


It is interesting the fact that people- related issues far outweigh technical- related ones when talking about projects.


It is clearly important to select the right system and vendor at the start, but the project can go off the rails from almost that point onwards unless the building blocks, including the right project team, communications and governance, are firmly in place at the outset. As plenty of banks have found, set off on the wrong footing and it can be extremely difficult to put things right. The hole just becomes ever deeper, with too much vested interest to revisit the fundamentals of the project or, in the worst case scenario, give up and start again. At the end of the day, there is nothing like having people who have been there, done it, and have the scars to show for avoiding the pitfalls of the past.


Which areas are most often underestimated?


For HP’s Fanzott, it is testing, with banks and vendors tending to fall into this trap. The definition and alignment of a document- ed and signed test strategy needs to come at the start of the project, he says. It then needs to run through all stages of deliv- ery, across technical, functional, integration, and performance, to end-user testing and final operational readiness. The readi- ness is not only system related but also to do with the readiness of the bank’s organisation, including processes, documentation, user training, networks, and branch performance. Tusmor’s Brownsell also picks out testing, with a need to


engage a testing manager as soon as the design work begins. They should be involved in every workshop and should be party to all documentation, ensuring a clear understanding of the deliverables and goals. ‘Defining test cases and data can then be started in parallel with the build phase, keeping an eye out for changes as they happen.’ Then when the actual accept-


ance testing phase is initiated, it is led by someone with a clear and accurate vision of the expected outcomes.’ Too often, the business believes that testing can be left to late in the project. Fanzott believes it is also common to assume that the


migration strategy and reporting can be left to the end. Both need to be defined at the start and need to run through the entire project. For reporting, ‘no project will go live if the statutory reporting, group reporting and at least some basics of the bank’s MIS are not in place. So start to think about this at the beginning and don’t see reporting as something that comes at the end.’ Sofgen’s Paterson feels the gap analysis and design stages


are also often underestimated because there can be unrealistic expectations following the sales process. And Brownsell points out the need to refresh procedures and train staff as other areas that are typically more onerous than predicted.


8


© IBS Intelligence 2015


www.ibsintelligence.com


analysis: running a core banking project


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18