IBS Journal February 2015
Core transformation: proposed leadership model Initiation
Technology should drive for: • Robust architecture • Latest technology • Scalable product • Ease in enhancement • Application support
PMO should focus on: • Number of phases, roll-out plan •
Implementation schedule • Budget
Business SMEs should support for: • Rich functionality • Less customisation • Parameter driven •
Innovative products Solution design
PMO should drive for: • Strict adherence to schedule • Issue/decisions escalation • Risk management • Better communication • Governance and best practices • Requirement prioritisation
Business SMEs should support for: • Requirements definition • Process optimisation • Solution design • •
Input for prioritisation Input for phased delivery
Technology should focus on: • Specification for interfaces, data migration and reporting
• Environment readiness • Technical design
Solution verification
Business should drive for: • Quality and usability of product • Operation manual • Training manual and training • Processes and user readiness • Traceability from requirements to test cases to defects to procedure and training material
PMO should support: • Defect management • Traceability of work around testing, training, procedures • Ensuing phases and activities
Technology should focus on: • Application support readiness • Handover of customisation • Augmenting technical development team for future technical support
Solution roll-out
PMO should drive for: • Detailed planning and execution
• Coordination across the bank • Communication • Stakeholder management • Transition into next phase
Technology should focus on: • Environment readiness • Transition of application support
• Fallback strategy • Application support
Business should support: • User coordination • Expectation setting and management
• Raising issues, prioritisation and managing interim solu- tions during defect resolution
Capability building
Capability building exercise is managed by phase leadership to:
• Define entry criteria • Define exit criteria • Define process of execution • Role and responsibility for each activity in each phase
The proposed leadership model above shows how the leadership (in red) transitions in each phase. There is a smooth leadership transition before each phase, which is logical- ly arranged to include a capability building exercise (denoted by the yellow arrow). This exercise requires a lot of preparation, including defining the entry/exit criteria for each activity, the process of execution for each activity, roles and responsibilities for each member of the team. It is expected that before the core transformation programme begins, this leader- ship model is discussed, explained and agreed among all the executives and the board, as that will help in containing organisational politics, which is a key objective of this model.
Based on the author’s involvement in
multiple projects and detailed analysis of issues experienced first-hand, below are the rules that have been defined to help management to form an optimum team: Rule #1: Create a separate business
‘super user’ team, formed from the smart- est people from business organisations who know their field inside out. There should be no bias, as the best people should be put forward for this ‘open heart surgery’ that is core software transforma- tion. The application support staff from the legacy system should augment this ‘super user’ team, and the bank/FI needs to work with the constraint of supporting the legacy systems until (and sometimes beyond) the go-live. It is important to account for all activities that this team will participate in. The number should be suffi- cient to cover the requirements gathering, solution design, test case creation, inter-
40
faces, data migration and reporting. One most critical point is not to be blindsided by the argument that the same person will be used for multiple activities in the same phase. The same resources will be needed in the downstream phase for defect resolu- tion, training material, procedure writing, support etc. If there are not enough people then external business analysts should be hired and assigned to a specific business person. This way, by the time the first phase is finished, these analysts can effective- ly participate in the following phases. It is crucial to make the entire team understand that they are working for the overall pro- gramme, not just for their department. Rule #2: Form the technical team for
the interface, data migration, reporting and statements specifically for the pro- gramme. There may be a large impact on other ongoing activities but set the expec- tation that the core transformation is given
© IBS Intelligence 2015
www.ibsintelligence.com
the first priority over any other work. Tradi- tionally, the technical team is less knowl- edgeable about business, so it is critical that the technical team starts to under- stand business processes around their code as they have to sufficiently unit test their code to avoid downstream rework. Rather than working in silos, this technical team should participate in business training and requirements review. Rule #3: Form the programme man-
agement team by selecting people who have experience in core transformation. Note that core transformation programmes are quite rare and the experience matters a lot while driving the programme specif- ically through the requirements, testing and roll-out phases. This team needs to be aware of at least some common pitfalls and they should be able to convey the message strongly by providing practical/specific examples.
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
