e-Finance Trends: Mitigate risk with software quality assurance

Last week we started this discussion with various information technology dimensions one needs to address operational risks.

Technology being central to any bank, can we afford to be slack in any dimension? We need to have proper infrastructure to ensure uninterrupted running of all business-critical systems. We need to ensure that all application systems being implemented in the bank undergo rigorous quality assurance. We need sound technology governance practices and we need effective solutions addressing operational risk management.

How do we ensure robust quality systems? A Standish group report estimates that only 24 per cent, i.e. only one in four software projects, undergoes a complete cycle. The estimated cost of failed projects in the U.S. alone is $85 billion out of some $250 billion corporate America spends on software. How do we ensure that our projects do not meet the same fate?

How will software quality assurance mitigate project failure risks? It has an ongoing role in various stages of a software project's life cycle. We have to ensure different things at different stages. Has the requirement been properly conceived? Has the specifications been comprehensively drawn out? Have we identified all affected entities and involved all of them?

Have all the entities recognized the benefits of system solutions and created their part of specification. It is extremely important to involve all the affected entities in creating the blue print. It creates some sense of ownership. The documentation is indeed important; the process of creation is also equally important. We have seen many good projects perishing midway due to this important factor, i.e. lack of ownership from one or more entities.

Next step

Once we have visualized the system solutions, we need to visualize an implementation and run through the processes. Does the implemented scenario require reengineering of processes? Does it require different organization structure? Does it require different information flow? We also need to look at opportunities provided to be more competitive and efficient. Can we reduce the number of steps to complete the processes? Can we achieve a better turn around time? Can we rationalize the number of registers or manual record keeping? Can we improve the audit ability of transactions? Can we optimize the control features while introducing new systems?

This analysis will help us prepare much better in terms of implementation as we will be fully aware of surrounding changes needed to successfully implement. Developing software solutions without studying the impact on process, structure and existing support systems will create lot of hiccup during implementation.

Another important risk-mitigating exercise is end-to-end testing. Having developed the solution, have we undergone complete testing cycle? We have to accept today that we will never get the best solutions for each department or function from a single vendor.

There are niche solutions for each area and solution providers concentrate on niche areas such as trade finance, treasury, MIS, anti-money laundering, IPO management, work flow and so on. In addition, we have a set of systems specifically developed for us. Given such a software inventory scenario, what does it mean in terms of testing? Have we analyzed the systems being affected once a change or a new system is introduced? Is it a standalone system? Is there any data movement from or to any other system? Are we doing a proper end-to-end system testing?

Tendency

There is always a tendency to ignore the peripherals and focus only solutions. Are we also getting into this trap of shortcut and avoid elaborate testing through misplaced optimism? This is the pitfall which must be avoided. It has resulted in serious hiccups or failures in many situations. Testing a system in isolation is an incomplete step. Simulated and real interfaces will be far apart and assumptions have serious risks.

We have seen many instances in many organizations where a minor change has created serious problems because of this factor. We need to understand the environment and the impact of change of one system on another. Any shortcut or assumptions will have serious risk implications.

Another important dimension of solutions implementation is managing the pilot testing. How do we manage our pilot testing phase? Have we created a structured process and monitoring document with checklist? Are we monitoring the performance of system? Are we capturing all types of transactions and testing all situations? Are we tracking the transactions through new designed processes and structures? Are we documenting the problems, bugs, improvement points and feedback from users? Are we analyzing the impact on turn around time, service standards and bench mark?

There is a tendency to rush through pilot phase and we have witnessed many situations where the organization lacked clarity on purpose of pilot testing. Pilot testing is a very effective risk management tool where we expose a portion of the organization to changes in live situation. It provides us good opportunity to develop assurance that the changes will bring positive impact.

It also provides opportunity to correct ourselves of various errors or bugs or wrong assumptions. Any organization which is not taking the pilot phase seriously is always exposing itself to adverse impact of changes.

We will continue our discussions on other dimensions in coming weeks.


- The author is the assistant generalmanager of Doha Bank