Adaptation of the consumer loans system as part of a bank merger
Project description
A large-scale program that included dozens of projects and over 1,000 internal and external employees was set-up, to fully integrate a long-standing subsidiary while dissolving the brand.
The project described here was part of this program. Its purpose was to make adjustments to the systems for recording and managing consumer loans. Those needed to be adapted to the new branding. A more prominent change was the conversion of 8 digit account numbers to 10 digit account numbers. Due to the central position of the account number in the banking system, this meant changes in virually every part of the mainframe system. Furthermore, several interfaces were affected, including the the extremly critical interface to the payment-transactions mainframe.
At the same time, another project was running to implement a new commissioning system for new consumer loans. Consequently a new interface to this system had to be defined and built.
Last but not least, because our project was the biggest project in this area since many years, we used the window of opportunity to make some fundamental system enhancements.
My role
Management of the ongoing troubled project with a team of around 40 people was assigned to me with the goal to get it back on track. This included overall responsibility for budget (7-figure Euro amount), time and content.
Results
Successful conversion of the consumer loans mainframe system from 8 to 10-digit account numbers.
Rebranding to the new brand name of this mainframe system including a linked document management system that was used for creating all customer correspondence.
Rebranding of the separate car financing system to the new brand name (by management of an external supplier).
Successful implementation of the interface to the new commissioning system.
Key figures & facts
The project team consisted of 42 people.
The project duration was 1.5 years, meaning it only took 2 months longer than originally planned.
50 milestones were planned and achieved.
The total budget was exceeded by only 13%.
A CMMI level 2 appraisal was successfully passed with a score of 96%.
Extensive system documentation was created, which included the following:
7 architecture concepts
351 Functional Design Documents
5 releases were successfully introduced into production with the following adjustments:
158 new programs
609 customized programs
95 programs were removed
The quality was high; There were relatively few production disruptions - 17 in total - which were all resolved within hours or days, so that there were no consequences for customers.
System environment:
IBM Mainframe z/OS
AIX
CICS
Windows
Cobol
assembler
JCL
MS Access
Word Macros
Tools used:
Concerto (CCPM Tool)
MS Project
Clarity
MS Office
Projectorganisation
Approach, methods & tools
Circumstances and conditions
Typically similarly sized organizations (banks) pose substantial organizational complexity requiring substantial efforts on stakeholder management and coordinating activities across departments. Politics and coordinative issues need to be dealt with. However in this case those were exceptionally challenging in their nature, which had a major influence on the approach used.
A defining circumstance was that the department was in the process of introducing a new - quite exotic - project management method that had to be used.
Due to cost-cutting measures, the responsible department had shrunk to just a handful of employees. As a result, there hadn't been a single production release here for over a year.
Strict application of implementation-standards
The majority of the project members consisted of external employees who had little or no knowledge of the system environment when they joined the project and all brought their own working methods and habits with them.
To avoid issues with consistency and predictable quality in implementation, we therefore introduced rigoros implementation guidelines and standards . To this end, the few internal employees were largely kept out of the implementation itself and were given the following overarching tasks:
Briefing the new project employees in the areas of implementation procedures, methods and tools (regarding Business analysis, Development, Deployment, Testing and Documentation)
Creation of the overarching concepts, which were the basis for the technical design and its implementation
Continuous implementation of code reviews and coaching
In addition, an existing review process called Q-STAR regarding design documents was carried out very conscientiously and stringently, with colleagues from all disciplines (analysis, development and testing) being involved in a review.
Stakeholder Management
The project had various dependencies on other departments and parallel projects, all of which primarily pursued their own interests. There were also reorganizations immediately before and during the course of the project. Project teams always had to fight for resources and priorities. Furthermore, there was an extremely extensive approval process for production-releases, which spanned several departments and could take 4-6 weeks.
To address the situation, I carried out intensive stakeholder management, which included the following:
Establishing a steering committee for the project in which all areas of the organization relevant to the project were represented at the C-level. Interestingly, despite a very extensive methodological approach in the organization, a steering committee was not a given. However, once introduced, it promoted commitment throughout the affected organization. It also offered an escalation mechanism,
Extensive lobbying towards other relevant projects and departments.
Assignment of one employee to solely take care of the approval processes for production-releases.
Bringing back from early retirement a former head of the IT Infrastructure department that was responsible for bringing releases production. His task was to liase between the project and this department.
Prince2
Essentially the projectmanagement approach within the company which we also had to follow was Prince2 based:
My predecessor had created a detailed Project Initialization Document (PID), which defined the scope, budget, timelines and responsibilities in great detail.
I created a Project Status Report (PSR) every 2 weeks with status reports on all individual project milestones, project finances as well as issues and risks.
There were guidelines for risk, issue and action management including processes and templates.
In addition, I created a detailed end-of-project report summarizing all the main results, the approach used and “lessons learned”.
CCPM / ToC
Critical Chain Project Management (CCPM) - Theory of Constraints (ToC)
In deviation from the company standard, the division-head decided to introduce the project management method Critical Chain Project Management (CCPM), based on the “Theory of Constraints (ToC)” across all departments and projects, including our project.
As it also turned out that using the method got in the way of coordinating milestones - and we had a significant amount of them - with other departments and projects I requested to be released from using this method.
Fortunately after a few months my requests were granted.
Planning
In MS-Project I created detailed project plans based on estimates from the project team members. We had regular planning meetings during the course of the project. Employees were scheduled at task level and the workload of individual employees was balanced, taking vacation and other absences into account. This resulted in a coherent and reliable plan.
Task Management / Manager
While the experiment with CCPM presented additional challenges to the project, it also had one very positive spinoff - namely that it provided us the role of “task manager”
In CCPM, this person monitors all tasks - especially the critical ones - in order to remove blockages preventing their completion. We kept this role even after the end of the method-experiment because it turned out to be particularly helpful given the enormous number of open tasks at any given point in time.
The task manager continuously and relentlessly “chased” those responsible for every task and every to-do. On top of that we went through the entire list twice a week with all project teamleads. All in all this proved to be very effective.
Issue and Risk Management
Issues were continuously tracked, as well as resulting tasks and to-dos. On a regular basis we held “Risk Brainstorm Meetings”. The identified risks were assigned measures or tasks. Risk status was actively monitored. This meant that many problems could be prevented and the team was able to respond to issues more quickly and adequately because the team had anticipated their possible occurrence.
Status Reporting
According to Prince2 specifications, status was reported using a Project Status Report (PSR). This was created every two weeks and discussed in the steering committee. This reported in detail about:
Significant results since last report
Next steps/expected results in the coming reporting period
Status of the individual milestones
Issues
Key risks
Project finances
Projekt Controlling
The project management tool “Clarity” was introduced to establish company-wide, uniform project controlling. The MS Project plans were imported here for resource management. The milestones have also been adopted here. In addition to the PSR, I had to report bi-weekly milestones in Clarity.
In order to always be able to provide information about financial planning, I created a detailed spreadsheet-based system, which was maintained by the project’sPMO employee:
There were Excel timesheets for each employee in which their tasks with start and end dates were copied from the MS Project Plan.
In addition to the hours worked, employees also entered comments on their tasks and plans each week.
The reported hours were imported/adopted by the PMO in the Project Controlling Spreadsheet.
Based on this, budget planning was monitored and financial reports were created in Clarity.
Programm Management
Additional status reporting
The customer used Clarity for its program management as well.
As part of this, weekly project reporting consisting of a Powerpoint slide was introduced, which was uploaded to Clarity. From this, the program office then semi-automatically compiled an overall report on all 100 or so projects for the program management called the IT Decision Committee (ITDC). The highest management level (CIO of the bank) was represented here.
The effectiveness of this reporting proved itself as on multiple occasion questions from the ITDC where immediately and directly addressed to the project based on this reporting while herewith skipping two or three hierarchy levels.
Test
The test team worked according to the T-MAP methodology. The essence of this was that a risk analysis was carried out for each release, involving subject matter experts from the business departments, and that, based on this, focal points in the test scenarios and test cases were determined. This worked really well.