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. As I travel and speak to banks of all sizes, here is what I see emerging as a model to mitigate risks across implementations.
A typical implementation of a 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. Some facts that I have observed and validated with customers:
- 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.
- 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.
- 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.
- 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.
- 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.
In my next post I will further explore a possible solution where an up-front assessment of quality, stability, integrations and user experience can lead to a faster implementation for a better product with optimal ROI.
Hari Raghunathan | ‘Go-Live’ Faster !