If you want a more innovative bank, it starts, and largely stops, with what your approval process looks like for new technology. Take a human and force them to grow up in New York City. Around age 20, you force them to go to conferences on living in the outdoors, hunting, fishing, and survival. You also hire consultants to come in and teach outdoor skills. Take your well-outdoor trained city dweller and then put them into the middle of the Colorado Rockies, chances are they become bear-food in a week. That is basically how banks are handling innovation.

Please don’t take our word for it. Practice starting a fire without matches or propellant in your fireplace, and you can pick the skill up within an hour. It almost seems easy. Now hike, spend the night outside, wake up at 6 am and try starting that fire in the wild and it is a different story. The wind, wet tinder, and cold create a different environment that increases your odds of complete failure. Now multiply that experience by around 300 other skills, and you can begin to see the point of this tortured analogy.

In short, your process is wrong for a great number of projects that involve technology. Just like you have to be in the outdoors to learn the outdoors, your innovation process has to be agile if you want an agile bank.  

The Problem With Bank Technology Approval

Most banks spend 100+ hours approving technology. They write a requirements document, put together a business case, talk to a couple vendors, gather a large committee, choose a solution, get the vendor-approved, negotiate a contract and then go about integrating the whole project. What is worse is that many banks conduct this whole process using unanimous approval. If one group objects to any part of the process, the process stops until that group can be satisfied. Sometimes, this is the only way to do it. However, for the vast majority of technology-related projects, there is a better way.

The problem with a traditional waterfall approach to tech development and vendor selection lies in the fact that most likely you don’t know what you don’t know. Projects like a customer relationship management system, account opening, loan processing/decisioning, API engine, robotics, a machine-learning platform, or any other million initiatives that you are likely to have – you are largely guessing.

This is the largest pain point on technology. Look around your bank and ask yourself how many of your technology projects are truly utilized correctly and are performing as expected? If you are like most banks, that number is less than 50%. In other words, most banks are not only slow to develop technology, but they are not all that accurate despite all the planning, resources and unanimity in decision.

A Pilot Program as Part of Vendor Selection

If you elect to use a vendor for your chosen piece of technology, a better approach is to negotiate a pilot program and make that part of the vendor selection process. To the extent you can try the tech without a full integration, in a single market, and under limited risk, you will gain more in education than two of your previous waterfall approaches combined.

There is nothing like letting everyone touch and use a solution under real-time conditions.  While most vendors will not offer a pilot program upfront, almost all of them will agree to either negotiate a pilot program upfront or give you a cancellation period after 90 or 180 days.

If they don’t, you could have the wrong partnership. While not all tech lends itself to this approach, if it does and your solution provider won’t extend a pilot program then that is a signal that that potential partner is not interested in solving a problem for you, they are only interested in selling you a product.

The end result of this “agile” approach to vendor selection and implementation is that you get to market a whole lot faster. Instead of taking one to three years in getting a product to market, you can get to market within three months.

The faster you get to market, the faster you learn about the tweaks you need to make to the technology and the faster you can find out if the tech is going to work for you. If not, then you can move on. If you have to move on, maybe you have wasted some resources. One bank had to scrape a $30k pilot because the technology didn’t live up to the hype. While not great, that is far better than having a $700k piece of technology that is a round peg in a square hole.

How Do You Decide The Approach?

This is an easy one. The more cost and dependencies your project has, then the more you should lean to a traditional waterfall approach. Further, the slower technology changes, then the more you should lean towards a waterfall approach. However,  If you are in a fast-moving environment, or it is a high-risk project, and you absolutely have to get the project right, then getting a pilot program in the market is critical.

The Chat/Chatbot Example

Consider that the number one anxiety point for customers is solving a problem. When a customer has a problem they want to make contact right away. Having a chat and chatbot feature on your website and mobile is critical to creating that quick human connection to help remove that customer’s anxiety as fast and as cheaply as possible. The problem is, there are so many different versions of chat and chatbots that it is hard to decide which chat structure is best. Here, because of the risk of interacting with the customer, the ease of integration, the fast-changing market and the wide variety of options (video, document sharing, scheduling, different levels of artificial intelligence, etc.) test driving an application is almost required to get it right.

Putting This Into Action

It is difficult to become innovative unless you are immersed in an innovative culture. One of the least innovative processes that banks have is how they choose technology. As such, banks should consider streamlining their tech approval process and rewrite their risk/vendor approval policies to reflect the lower risk of the project. Going to a limited number of customers with limited impact on related systems and at a limited cost/legal impact means lower risk.

Banks need to reflect this lower risk profile in their process.

Look at your project approval process and figure out ways you can mitigate risk by implementing a pilot program whenever possible. While most banks that develop the technology themselves employ an agile development process, it makes sense to take that same agile process and apply it to vendor relationships and technology purchase decisions as well. In doing so, banks will not only get to market faster while reducing risk but will learn a mindset that will make the entire organization more innovative.