This is a sequel to my previous entry, titled “Challenges to the Core Banking Solutions Implementation Projects – 1.”
Continuing on the problems faced in core banking solution implementation projects, let us look at some other problems.
Lack of IT Resources with Banks
Usually, the core banking solution vendors claim to offer lower overheads, advanced technology, lower maintenance costs etc. After all, such claims win the clients and especially their finance people, as they see IT as a big cost center instead of a strategic asset. Vendors are also aware of the fact that the banks will calculate a minimum of five years total cost of ownership (TCO) before they make any decision about a vendor and its solution. If the system requires a large number of IT resources, it will reflect negatively in the TCO spreadsheet. They thus would not recommend the banks to hire the adequate sized IT team. Even if they are forthright about it, the banks may not take the suggestion that seriously, and try to bargain this number. Also, banks are not that big on IT and the trends in software, such as Agile Methodology and other object oriented frameworks. They thus cannot, or find it hard to appreciate the roles of user experience, documentation, quality control and quality assurance engineers. Ironic, isn’t it? During negotiations with the application vendors, the same bank managers vouch to create their own IT team to manage the solution during and after implementation. They ask the vendors to train their teams on the technology and features so that the bank could reduce dependence on the external vendor. Yet they do not hire enough people.
In my experience, I haven’t even heard about a single bank going for ISO 9001:2000 compliance. But don’t be misaken here: a number of banks are very active on IT security and service delivery. While this is a good trend that shows that the IT managers of the banks are waking up to the security threats and service delivery, they are not aware of the software development advancements.
Lack of Experienced Project Managers
A bank changes its core banking system once in decades. Same goe s for any other IT solution that a bank purchses, such as credits, risk management, middleware and the likes. Also, such projects are so large that it is difficult to find project managers from the market with experience of similar sized projects. The project manager is expected to provide insight, skill, communication and foresight to steer the project in the right direction. While a project manager can bring skill and communication, if he/she is not from the banking arena, the foresight, risk management and insight will be missing. A newly inducted project manager will also face issues in taking control of the things because he/she is a new entrant.
Missing Comprehensive Training Programs
This problem hits the implementers and the banks, both, and equally hard. The way banks and implementers lose their IT manpower, there is almost always a dire need of hiring people “yesterday.” New bugs are being pointed out, un-used or un-tested features are brought to operations, requirements are evolving, and new faces are being introduced in the team as older ones are leaving or have left already. Continuous trainings of fresh employees must take high priority in such cases. We have seen that this doesn’t happen. Batches are trained, no doubt, but not in the way they should be. Application vendors and implementers are too stretched to move their consultants from clients to training labs. With banks pressing hard upon delivery and expanding their feature-set at the same time, and the implementing engineers/consultants taking other opportunities, the implementation managers do not do what they must: training, training and more training.
I haven’t seen many banks with QA people, honestly. And even those who have QA personnel, have up to two people. How can two people possibly do a quality check of the whole banking system? Furthermore, it is highly likely that QC people are picked up from the general IT industry, which means that they may not have the experience of the banking environment and applications. They may not know or understand fully the requirements of a user. Also, it is possible that the QC personnel are hired after the requirements analysis is complete. By that time, it is too late. I am not contending the human ability to learn and act; the QC engineers can still pick things up, but that is only a subset of what they should, and in a very short time span. Ultimately, you would see QC people checking the application for crashes and interface related errors, mostly.
No Stress or Automated Testing
A banking application is supposed to take a large number of users. Add to it the users of Internet Banking, and you see a dramatic number within the usual eight business hours. Since the applications are built with older or proprietary technologies, the choice of tools to stress and load test the applications is very slim. If the application has a web interface, or if it is developed using Oracle Developer, then you have a few options. But because of the tough timeline, and no time for testing, load testing also stays under the radar. Realizing late in the process, banks find it convenient to purchase more hardware horsepower. There is hardly any calculation behind the assessment of the required hardware resources. Thus the limits of the available hardware are never assessed. Also, not using an automated tool makes the users and QC personnel test each newly developed or fixed feature. And when an update/fix/patch is received from the application vendor, people have to test everything again. This is a huge investment of time and resources, which is avoidable by using an automated testing tool.
For web application, we have used IBM Rational Performance Tester, Rational Functional Tester and WebLoad. Creating scripts requires some programming as well.
To be concluded…
This blog is also available at http://www.sapphireconsultingservices.com/scsblog/blogs and at http://imranadeel.wordpress.com