IBS Journal February 2015


Leadership transformation: a must before core transformation


Within a core transformation, what leadership structure ensures the right balance among business, technology and programme management functions? Who should hold the reins and what are the pros and cons of different functions being in control?


About the author


Core transformation programmes are con- sidered to be the biggest risk and oppor- tunity by a bank’s board and executives. Although many of these programmes are executed with due focus and commit- ment, statistically very few finish on time, within budget and successfully deliver all business objectives. The levels of success vary from one transformation to another and it often requires ‘an insider’ to analyse the pattern. Success primarily depends on the effectiveness of the leadership struc- ture put forth for the transformation pro- gramme. The leader (or a group of leaders) drives the process definition, governs exe- cution, sets criteria for each activity and takes a final call in a conflicting situation. Three key functions usually form the


Anup Agrawal is an independent core banking software transfor- mation specialist, having worked over the years across a number of such projects, with the latest being at Discover Financial, assisting the US bank in its pioneering efforts to implement Infosys’ Finacle. Agrawal’s previous employers also include Oracle FSS, Infosys and HP.


programme team: business, technology and programme management. The func- tion managers play a leadership role in process definition that governs the exe- cution of the programme step by step. These defined processes are a ‘nervous system’ of the venture and control the quality of outcome of each activity, which later translate into success or failure of the entire undertaking. Each bank has a unique political environment: some have a strong IT unit that calls the shots, while in some the majority of decisions are tak- en by business departments, and in some cases the programme management unit has most influence. Control and capability to influence the decision are integral parts of the leadership structure. Traditional- ly, programmes follow a rigid leadership structure where one dominant function manager drives all phases/stages, from ini- tiation to roll-out. Every function manager has a differ- ent thought-process, based on prior expe-


38 © IBS Intelligence 2015 www.ibsintelligence.com


rience, vision and the focus of that par- ticular functional area. To strike the right balance, let us first analyse the three key functions: o Business: It is observed that dom-


inant business control across the entire programme usually results in scope creep, due to the inclusion of many ‘nice to have’ items that lead to many customisa- tions and enhancements. This is likely to cause schedule slippage and cost overrun. There is also likely to be lack of commu- nication and tracking, which cause docu- ment re-work and also affect the solution design. On the plus side, the programme gains detailed requirements and rigorous testing, resulting in a more stable product. o Technology: It is a safe assumption


that the IT team knows the current system so the team members are a natural fit for a leadership position, but the predominant control of the IT might result in a bank having a technologically advanced solu- tion that does not provide much business value or return on investment. Usually, aspects such as testing, training and user readiness take a back seat, and the solu- tion is pushed on, rather than accepted by, the business. Furthermore, there might not be enough emphasis on risk monitor- ing and risk mitigation plans. On the plus side, the bank gains a sound architecture and a technologically advanced solution that is scalable and is better supported. Also, the IT team tends to maintain a bet- ter relationship with the vendor, which is particularly useful during go-live and sub- sequent support. o Programme management: They


know how to run projects and get things moving with better communication and escalation processes. A domineering


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