IBS Journal February 2015
programme management team deliv- ers strict scope control, which in some cases means that critical issues are put out of the current phase scope or post- poned until later phases, creating a large list of workaround/manual solutions. This defeats the business objective to imple- ment the programme. On the other hand, the bank sees the programme implement- ed within a reasonable timeframe, it is bet- ter communicated across the organisa- tion, there is timely escalation, better risk identification and mitigation. The observations in this article are
based on real-life experience gained by the author’s participation in numerous core transformations at almost every lev- el, starting as developer, tester, interface and data migration lead, to project/pro- gramme manager. There are various pub- lished sources to validate these observa- tions, it is important to note that whilst many of them mention end results, due to political reasons they often stop short of pointing the root cause. There is a dire need to establish a model or methodology that can pro- duce consistent results. While this is com-
mon sense, we still find almost every core transformation falling into one or more of these pitfalls. This is due to the fact that most of the banks tend to follow the same governance structure throughout the programme, which primarily leaves one functional area to drive the entire project. But if the bank’s board and management want to effectively use the function teams’ strengths and avoid weakness, then it is vital to come out of the existing political environment and shift control among the three function teams based on the phase of the programme.
Below is a proposed leadership model, which capitalises on strengths and helps to avoid common pitfalls:
o Initiation phase: In this phase,
the vendor is selected, the roadmap is defined, and budget and resources are allocated. This phase should be led and controlled by the IT unit as the bank needs to select a product with robust architecture, is scalable, easy to cus- tomise and efficient to operate. As the technology team supports the existing solution, it is knowledgeable about its issues, and it is also likely to have a bet- ter knowledge of the vendors and their systems. Of course, the project management
office (PMO) should be involved, so that the PMO team can focus on the imple- mentation schedule, budget etc, and synchronise with the vendor for the final roll-out. A team consisting of business and application support should have an input too and provide their expertise in analysing RFP responses and in the deci- sion-making process. This leads to easi- er buy-in and acceptance with business and operations. o Solution design phase: In
this phase, business requirements are defined, ‘super users’ are trained, speci- fications for interface development are defined as well as those for data migra- tion and reporting. There are so many moving parts requiring a lot of coordina- tion, communication and tracking. This phase should be led and controlled by the PMO otherwise it goes very slow and ‘squeezes’ all activities at later stages.
PMO should be given enough authority to define and enforce processes, escalate major issues and bring them to a close without affecting the programme sched- ule or quality. It is observed that if the bank’s top executives are not involved in this phase, it causes delay in deci- sion-making and problem resolution, thus affecting the schedule. PMO should be given enough control in steering meetings so that they can steer the pro- gramme in the right direction and avoid roadblocks. Actual tasks should be done by business and technology resourc- es, and they should provide input into decision-making within their respective areas. o Solution verification phase: In
this phase, the system is tested, opera- tion manuals are created and all users are trained. This phase should be led and controlled by the business organisation, because if this phase does not go well, they are the most affected party. This will also help in gaining a wider acceptance of the new solution and changes, and provide a stable system that justifies the costs, efforts and risks undertaken by the entire bank. The PMO and technology departments play a critical role in defect management, facilitating and track- ing training and operation readiness. There is a lot of pressure from the board that can be best managed by an execu- tive from the business operation. Also, there are many changes in the solution
(or workarounds) that can be best ana- lysed, managed and planned while the programme is driven under the business leadership. o Solution roll-out phase: In this
phase, the system is rolled out, which requires tremendous coordination, plan- ning and communication. Irrespective of whether it’s a big-bang or phased con- version, it should be led and controlled by the PMO organisation. Programmes suffer in this phase due to the large num- ber of activities and people involved. Stakeholders’ expectation management is very important, and this can be best done by the same PMO that led the solu- tion design phase. A lot of programmes fail to kick off the next-phase activities due to multiple post-go-live issues. The proposed leadership model is
aimed to help break silos in the organ- isation, and once all executives are on board, the next step is to form an opti- mal team by pulling resources from the business, technology and PMO teams. Many core transformation programmes suffer as they fail to obtain the required resources commitment, as the success (or failure) of the transformation is driv- en by quality, skill-set and number of resources assigned and available at the right time. Due to the nature of the pro- gramme, it is not easy to assess the quali- ty of each activity immediately and often it is very late in the programme to take remedial actions.
© IBS Intelligence 2015
www.ibsintelligence.com
39
analysis: core system transformation
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 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56
