Banks have never been under more pressure than now to release more features faster on their transaction banking systems. Faced with competition from peers and all forms of third party processors, the pressure on fee income is being felt across banks. Build vs. buy…to customize or not to…outsource, co-source or in-source…quality vs. stability; this list can go on. The bottom-line is that these are turbulent times for the technology initiatives of most banks.
A typical implementation of complex transaction banking solution is painful. The average program lasts 18-24 months, takes up majority of the technology program resources and costs millions of dollars. Even with all of this money and time, most banks ‘Go-Live’ with quality, stability, integration and user experience issues. Just QA spends can be in excess of US $3 million+ with at least 3 iterations to the original budget. All of this is not due to a specific product, but because of the nature of the beast. It is evident across products, projects and banks. Here are some implementation risks that we have observed and validated with customers:
An average transaction banking system implementation can have anywhere between 6 to 10 vendor code drops depending on the size, complexity, quality and stability.
For each vendor code drop, internal development teams will usually match with a code drop of their own.
Customers usually plan data migration from one system to another in waves. It’s only in the first wave that you realize there are mismatches and you need to go back to the drawing board.
Most product vendors bring a set standard of quality and stability of their applications to the table. Banks tend to over engineer with too many customizations, underestimate the complexity of their programs and are not always ready for projects of this size and complexity.
A typical transaction banking system implementation will have a minimum of 3 full rounds of regression testing across the implementation. Smaller selective rounds are also run.
Single Points of Failure and managing scope in these projects are some of the primary causes for many cost and schedule overruns.
Quality and Stability of these applications are most vulnerable in customizations, integrations, environment and data variables.
A typical QA program for implementation of a transaction banking system lasts 18 months and costs approximately US $3 to US $4 Million. This is total cost of ownership that includes all activities such as user migration, data migration, test management etc.
The cost of finding ‘Go-Live’ impacting issues later in cycles not only increases the cost of fixing them but also could seriously derail your entire implementation program. The same goes for critical missed issues prior to ‘Go-Live’. One major issue could cause you to lose revenue or reputation, get pulled up by the regulator or just result in a really bad user experience.
A possible solution is an early detection, prioritization and resolution of issues that reduce your Total Cost of Implementation and subsequent release projects. This would involve establishing ‘Go-Live’ criteria upfront and using a combination of analytics, domain experience and application knowledge to carry out an objective assessment of the implementation to determine its readiness to ‘Go-Live’.
When a bank opts for a new treasury management system, managing and executing its implementation is no mean feat. It is a career defining activity for a treasury professional. The right treasury management system has to be selected. The system has to be customized to be in tune with a bank’s processes and existing technology applications. The system needs to be validated within the bank to ensure that it functions correctly. All of this while staying within time and budget limits and keeping up with day-to-day treasury activities! It is not surprising that an average implementation cycle can range from 18 to 24 months based on the complexity.
Go-Live Faster has been part of multiple implementations over the past years and has had the first-hand experience of some of the key challenges faced and risk mitigation strategies. Here are some best practices that Go-Live Faster believes should be practiced by product teams during an implementation:
Map your need for change to the product life cycle and conduct an objective analysis of existing system features with business gaps.
Spend time understanding the incumbent system. Build detailed data/ feature maps of the incumbent system.
Define your minimum viable product (MVP). In addition to this, a product road map from that MVP to the fully functional system (FFS) is important.
Spend time and money writing detailed requirements upfront. Breaking requirements down into project phases helps.
On an average, each organization banks with anywhere between 3 to 5 banks. Just because you see your competitor offer a feature on their system does not mean you need it for yours.
Front load activities linked to Wires/ACH and Information Reporting functionality.
Ensure that backend systems are available and integrated for validation. Identify accounts with Check Images, deposit items and special cases in the back end systems before validation begins.
Brutally prioritize and limit the number of customizations. Deploy the high priority, customized functionality early.
Verify high priority and high risk functional areas early. Get Product and Line of Business teams involved in daily failure point triage calls with the vendor.
Sign failure point turn around SLAs with the vendor. Get the vendor to focus on high and medium priority failure points.
Bring all integrating system vendors on the same page through weekly/ bi-weekly meetings. Create more clarity and raise flags early.
Share the list of user conversion failure points with the support team before the system goes live. Post go-live, divide the support team to champion specific functional areas of the application.
Communicate, communicate, communicate- This is critical to ensure collaboration and change management.
The success of a treasury management system depends entirely on the success of its implementation. Proper implementation is just as important as selecting the right treasury system. Majority of the times, it is only when a crisis comes up and treasury departments have to produce quick and accurate reporting on the organization’s liquidity, that the actual quality of the supporting treasury technology is actively tested. To prepare for such events, treasury professionals need confidence in the quality and dependability of their treasury technology. While the above is not a laundry list, we believe that anybody doing a treasury implementation would find it useful.
If you are looking for someone who can help you accelerate your time to market on product releases look no further. Get in touch with us today to explore our scientific and analytical reports derived from our proprietary technology!