Business Risk Assessment - In Rolling Out Newer Banking Applications And Services

As long as banks operated in a regulated environment they were risk averse. Being increasingly exposed to domestic and international competition they are now compelled to encounter various types of financial and non-financial risks. Risks and uncertainties are integral to life and more so to banking. A Bank as an institution is based on the foundation of customer confidence, which requires that it remains resilient to risks by managing them proactively and robustly.

Driven by an exponential growth in technology and increases in global financial interlinkages, apart from credit risk and market risk, banks also face operational risks. Not to forget the reputational risks which are poised to overshadow the rest!. The main reasons could be inadequate or failed internal processes, people and systems, dilution of privacy or external events. One of the key elements of managing a Bank’s Operational risks is to ensure risks around implementing and running its IT systems are managed effectively. Implementation of any new applications is typically a costly and risky proposition. Failure of core-system projects adversely impacts both finances and business opportunities. Failed projects lead other banks into delaying their expansion to newer applications as they assess the potential benefits of a new system against the risk of failure.

Implementing new banking applications and introducing newer services such as internet and mobile banking is a complex task that consumes significant time and resources. The key to success is to incorporate enough flexibilities and understandings of the way businesses are run so as to speedily adapt to unexpected requirements and surprises along the way.Driven by an exponential growth in technology and increases in global financial interlinkages, apart from credit risk and market risk, banks also face operational risks. Not to forget the reputational risks which are poised to overshadow the rest!. The main reasons could be inadequate or failed internal processes, people and systems, dilution of privacy or external events.

One of the key elements of managing a Bank’s Operational risks is to ensure risks around implementing and running its IT systems are managed effectively. Implementation of any new applications is typically a costly and risky proposition. Failure of core-system projects adversely impacts both finances and business opportunities. Failed projects lead other banks into delaying their expansion to newer applications as they assess the potential benefits of a new system against the risk of failure.

Implementing new banking applications and introducing newer services such as internet and mobile banking is a complex task that consumes significant time and resources. The key to success is to incorporate enough flexibilities and understandings of the way businesses are run so as to speedily adapt to unexpected requirements and surprises along the way.

Software project implementation could encounter various risks:

Technical risks include problems with project size, project functionality, platforms, methods, standards, or processes. These risks may result from excessive constraints, lack of experience, poorly defined parameters or dependencies on organizations outside the direct control of the project team.

- Take for example the lack of information on parameters relating to loan interest calculation or preclosure of term deposits that could cause testing bottlenecks.

Management risks include lack of planning, lack of management experience and training, communications problems, organizational issues, lack of authority, and control.

- For example inexperience in project management can result in lack of continuous monitoring of risks and re-planning appropriate mitigations in line with the project progress.

Financial risks include cash flow bottlenecks, capital/budgetary issues and return on investment constraints.

Contractual and legal risks include changing requirements, market-driven schedules, health & safety issues, government regulation, and product warranty issues.

- Not having earlier experienced a particular type of failure it could be very frustrating to find that, at a crunch, the product developer is unable to meet the up-time or mean-time to repair commitments under the contract.

Personnel risks include staffing lags, lack of focused experience, training problems, ethical dilemmas, moral conflicts, staff conflicts and productivity issues. - Large and multi country roll-out projects invariably require multi-cultural teams – both internal and external. In these cases absence of attention to cultural sensitization, team building and language translation requirements can cause significant issues around team communication and requirements management. These also lead to increased time for review and acceptance testing phases.

Other resource risks include unavailability or late delivery of equipment & supplies, inadequate tools, inadequate facilities, distributed locations, unavailability of computer resources, and slow response times.

The key considerations for a successful modernization journey are:

1. Business Requirement Management : Requirements should be captured and managed centrally, allowing banks with multi–line business units or other global bank entities to centralize their requirements and prevent duplication of development efforts.

A typical fallout of inadequate or lack of requirement management is the scope creep during the UAT phase of the project. This invariably leads to lot of rework, slippages in schedules, increased costs etc.

- At a crunch, during UAT it could be realized that as a result of casual oversight, a crucial report was overlooked during the requirement planning phase.

2. Integrated Integrated Tooling Workbench: A standard set of tools and technology will improve control over the systems development lifecycle process.

3. Design Process : To effectively manage the risk of disruption, time to market and cost to transform, banks must combine a top-down approach with the traditional bottom-up approach to legacy modernization.

4. Build versus Buy: When deciding whether to build or buy, banks should consider the fit between business requirements and the available functionality in packaged solutions. They should also consider the effort required to customize a generic package or to streamline and redeploy existing functionality.

5.Proof of concept: To validate the transformation objectives, the bank should conduct a controlled Proof of Concept (PoC) with its chosen design principles and integrated tooling. The scope of the POC should completely mirror all the elements that will be faced during the full execution.

- Without the PoC, the bank may end up implementing an application that does not meet its core requirements. The bank may be expecting a Transaction Banking System, but the application’s operational efficiency may lie in Retail Banking.

- assumptions based on the halo around the developer could be woefully off the mark, resulting in severe cost and time overruns.

6.Go live Planning: As modernization is progressed and new systems evolve, the old legacy systems have to be decommissioned for the full benefit of the cost to be realized. A decommissioning strategy should therefore be defined at the outset of the modernization journey.

7.Testing and data migration: In most transformation efforts, testing consumes significant resources, effort and budget. Investing in a testing strategy and using industrial–strength testing processes and facilities can cut costs and reduce lag times in development and deployment.

- A proper data migration strategy helps in mapping the existing legacy data with the appropriate data field & type in the new system. The ‘date of birth’ may be maintained as a data field (instead of date field) in the legacy system. An incorrect mapping of this in the new system will create issues in validation of key requirements like status (major or minor) of the client.

8.Managing change: To ensure that risk is adequately managed, banks need to invest time and resources in robust change management. Change will result not only from the effect of modernisation programs, but also from business–as–usual initiatives that have to be accommodated within the transformation journey.

Conclusion: With ever-increasing complexity and increasing demand for bigger, better and faster, the software industry is a high risk business. When teams don't manage risk, they leave projects vulnerable to factors that can cause major rework; major cost or schedule overruns, or complete project failure. Adopting a Software Risk Management Program is a step every software manager can take to more effectively manage software development initiatives. Risk management is an ongoing process that is implemented as part of the initial project planning activities and utilized throughout all of the phases of the software development lifecycle. Risk management requires a fear-free environment where risks can be identified and discussed openly. Based on a positive, proactive approach, risk management can greatly reduce or even eliminate the need for crisis management in expanding to newer banking applications and services.