Blog

System Assessment, Selection & Implementation – Part 2

Series Overview

 

In this blog series we will explore the full process that financial institutions face deciding on the best course of action for modernizing their current information technology. As with any complex situation it makes sense to it break down. By doing so we can readily understand the process and with this understanding we are better prepared to properly manage these individually.

In our last blog, Part 1, we explored the primary driver of a system selection. In this section we will dive deeper into further defining what will be needed. We’ll continue to use same three examples from Part 1 so we can see the progression of each. You’ll also find some helpful examples!

 

 

 

 

 

Part 2: Assessment

System/Application Needs

The term “system” typically implies that there are multiple IT components working together to achieve a goal. Conversely, the term “application” implies that there is one piece of software that is working to achieve its individual goal and it is not dependent upon another piece of software. With that said, a financial institution still must take the steps necessary to determine if the system needs to be replaced, should it be upgraded, does only an individual piece of software need to be replaced or upgraded, or perhaps is there a piece of software that is missing. The net result here is you must determine the actual need.

Example 1: Convert vs. Upgrade

In our first example the bank had made the strategic goal of increasing their customer base through enhanced products and services. They have also determined that they have an aged/aging system with an ever-increasing technology debt which in turn increases their technological risk. With these facts it’s now time to determine if their current core processing system will support the products and service they currently offer (aka current state) as well as those products and services they are targeting in the future (aka future state).

 

The bank should perform a full inventory analysis of all current products and services. These should be broken down further into two separate categories of sustaining and retiring. While the sustained products and services will certainly have an impact on the what direction they ultimately select, upgrade vs. replacement, those that are targeted for retirement may also have an impact. For example, if a product is to no longer be made available the bank may choose or be required to continue the servicing of those products which have already been sold.

As the bank continues to build upon this inventory analysis, they will also need to focus their attention on any products and services which they may be targeting for development. The analysis should be just as rigorous as with current products and services since their impact can be just as significant. While ability of a core processing system being able to support products and services that are not currently being offered speaks to the scalability of the system it should be noted that typically the more scalable a core processing system the higher the cost.

For an example of an inventory analysis document click here.

Example 2: Which Product to Choose

As you’ll recall in our second example, we have a credit union with a highly outdated internet banking solution which is impacting the retention of the current members as well as negatively impacting the acquisition of new credit union members. The credit union has determined that there is certainly a need for updating this application to increase member satisfaction as well as aiding the marketing department efforts in acquiring new members.

In my experience I have seen many financial institutions view this simply as a “low hanging fruit” opportunity, engage their current vendor, and implement what can become a substandard solution. This is a waste of time, money and will certainly underwhelms their members. In short, not enough time is spent in making sure that they are selecting the best possible solution for their specific needs. The organization either implements a solution which has way more functionality then they need which equates to a higher price. Or, worse, they implement an application that doesn’t provide all the functionality that they currently need or will need in the future.

Just as in our first example the credit union needs to perform a full analysis of those products and services which they intend to deliver through their online banking platform. The key difference here is that they will need to focus most of their attention only on those products and services which are delivered to the members through their online banking platform.

The credit union will also need to pay close attention to the services which are now provided from many vendors that now align with “internet banking”. For example, internet banking typically refers to a member accessing their share, draft and other account types via a home computer. Functionality can vary even in this space and close care should be taken when selecting the right product. An example would be “bill pay” which gives the member the ability to pay their bills (both internal and external to the credit union) electronically.

Also, within the family of internet banking is mobile banking. This is the ability for a member to access their accounts via a mobile device such as a cell phone or tablet. While those that are less technically savvy will think that it is the same application it is important to understand that it is not. Vendors spend countless hours testing their mobile banking specific applications to ensure the best possible functionality across a plethora of cell phones and their respective operation systems (typically iOS and Android).

While a project such as this can seem simple on the surface, we’ve only scratched the surface of the complexity that a financial institution can face when upgrading or replacing a mobile banking application. There are many other factors that need to be investigating such as with the bill pay module. Will the credit union offer the service of cutting paper checks for members to those organizations that do not accept electronic payment (yes, these types of place still exist)? Or, how will the credit union communicate and manage member expectations when they must change their login credentials for the new system?

Along with the right technology vendor having an internal advocate that is experienced in these types of efforts is essential.

Example 3: New Implementation

In our third example we have a relatively large bank that is standing up a new commercial division. With the bank having already set their strategic direction and having defined and documented their “wants and needs” for their IT toolset provides us with the necessary building blocks to construct a solid foundation. Since this type of project is not single threaded but rather a woven tapestry it will be necessary to take a planned and deliberate approach to decomposing the IT toolset selection process.

There will be a tremendous amount of data that will be collected and used in this process. To ensure none of that data is lost, misplaced or forgotten it is best to document each data point as thoroughly as possible. For this purpose, I recommend that a Project Handbook is created. This handbook is extraordinarily useful not only when selecting your IT toolset but will pay dividends when implementing that toolset and measuring the success of the IT effort. This workbook can also serve as the genesis for other documentation that will be needed in standing up a new division within your organization. For example, if constructed properly, the workbook can help to generate full business process flows and SOPs.

I’ve used this handbook in many projects, and it is a self-contained document that contains many sections ranging from communications and risk management to business requirements. In the selection process the formalized and documented business requirements are invaluable. They allow the team to develop the wants and needs of the project into defined and measurable business requirements. These requirements can then be leveraged to develop RFIs and RFPs (Request For Information and Request For Proposal). Once a vendor is selected the handbook continues to deliver in being able to share this information with vendors to ensure their deliverables are well defined. The handbook also provides the team with a springboard for test cases and success criteria.

Here is an extract from the table of contents of a handbook. The information contained within is invaluable to the success of any project but especially a project such as the one in this example.

Conclusion:

As with our last section you are probably seeing a theme in all the examples. If you only do one thing you must define and document what your organization needs to achieve success in your objectives. What differs slightly with each example is the level of complexity at which it must be accomplished. In our last example we discussed the use of a Project Handbook. What’s important to note here is that the handbook could certainly be used in each example it’s the art of tailoring the handbook complexity to match that of your project.

Watch for Part 3 of this series when we will discuss assessing strengths and weaknesses and the important roles that they play in the entire process.