IBS Journal Supplement 2015


strategic future of the bank.’ He


adds, ‘this should start with the CEO and executive board, all the way down. Do not pretend to anyone that it will be a walk in the park, because it isn’t.’ Paterson emphasises the need to


create a single team, from bank, vendor and consulting staff. There is often a tendency, he feels, particularly on larger projects, to keep the teams separate but this can create an ‘us and them mentality’, with interaction only occurring formally, through meetings, workshops and emails. Ultimately, ownership of the project


has to reside firmly with the bank, says Brownsell. Ruffell says, ‘take control of your own destiny and do not rely on the core system vendor or even the system integra- tor to do this as it is your bank and your future.’ He also reflects on the need for flexibility. ‘A core banking transformation requires constant change and the ability to adapt and bring your people along with you. Failure to prepare them will result in confusion, fear and probable failure of the project.’ Ruffell adds: ‘Have a clearly defined set


of objectives for the programme from the top down so that internally your business and IT, and externally your partners, know what is expected of them working as one team. Then align this to the deliverables from your core system vendor and review this monthly if not weekly. This means un- derstanding all gaps between your “as-is” legacy system business process workflows and your “to-be” business process work- flows, as well the potential impact on your


IT landscape/architecture.’ Brownsell also places a lot of impor-


tance on the structure of the project team. ‘The top priority is that the implementa- tion is managed as a programme of work rather than as a project. The key difference is that a programme does not track task times and effort, as a project does, rather it tracks inter-project dependencies. Dependencies are stated in terms of tangible deliverables, where one project is dependent on another project by a given date. Examples would be the date that the required functionality has to be defined by the users, the date that hardware must be available for installation, and the date that software will be released for acceptance testing. This allows everyone to focus on doing the right thing at the right time, with clear accountability. It reduces time wasted on arguing about how a slippage happened and who is to blame, thereby enabling the programme to focus on fix- ing urgent and immediate problems with clear ownership and accountability.’ The project governance theme is


taken up by Toderici. ‘Project governance plays a key role. Right from the inception, it is important to set up a governance model which adequately addresses the requirements for the project.’ Fanzott em- phasises the need for the business to be in charge, not IT. The management commit- ment needs to be there through ‘the good, the bad and the ugly times’ and no project will benefit from a discussion about the principles behind it every time there is an obstacle, he says. That commitment


should not be only from the COO, but also from his or her peers, including CEO, CFO, CRO, CMO or whatever their titles. ‘Invest also during the project a healthy portion of time in stakeholder management, with regular face-to-face meetings. Active and regular communication can solve issues and prevent negative escalations.’ There is a question about who forms


the project team. In particular, is it staff who have strong ties to the existing sys- tem and processes? De Meyer is outspo- ken on the topic. If there is a replacement project, then this is due to ‘issues’ with the incumbent IT system and these are always in part due to IT or business people who have failed to do their job, he feels. ‘I have always been shocked at the role that some of those “failed” people get in the selection processes. If the bank tries to run the new core banking programme with the old “failures” in the lead or even involved then your programme is doomed to failure.’ They will attack the product and /or vendor, will believe that they know best, rejecting the vast experience of most vendors, and will work to retain the old system and the old people. Brownsell also supports the need for


‘The top priority is that the implementation is managed as a programme of work rather than as a project. The key difference is that a programme does not track task times and effort, as a project does, rather it tracks inter-project dependencies.’


Fiona Brownsell, Tusmor


a single team. ‘Structuring the packages of work as individual projects with the project managers reporting directly to a programme manager has clear benefits. It is common practice to have internal project managers “facing off” to supplier project managers. Indeed, every time I meet a new supplier this is how they expect to proceed. However, structuring this way opens the door to two project managers arguing about whose fault any given problem is.’ There needs to be un- derstanding on both sides, says Brownsell, ‘accepting and honouring that different organisations have different cultures and approaches to getting things done’.


Adapt to the new system and don’t be a guinea pig


Given Hypo Alpe Adria’s issues in Monte- negro with a new release of T24 and, in particular, Temenos’ emerging Arrange- ment Architecture (AA) component for defining products, it is perhaps not surprising that Paterson cites the need for stable software. ‘Vendors will always insist or encourage the client to take the most recent release of their software. The


6 © 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