Asset Based Lending
Chief Investment Officer
Commercial Loan Automation
SuperCommunity Banks don't often hold innovation high on their priority list. They relegate that activity, including the huge RD budgets associated with it, to their larger brethren. At the same time, incorporating innovation into your bank is inevitable, since the world persists in constantly changing. As a result, you find yourself every year with three times the requests for IT projects than your budget and staff can afford.
Many are struggling with the development of an effective process to prioritize and implement IT-related projects, whether for innovation or for (I know you hate this word) infrastructure.
First, let's define infrastructure. This is a code word for "must do", projects that must be implemented to keep the bank running. You might think those are marginal, since the bank is running just fine already. Please know that, in a typical bank, 85%+ of your entire IT budget is absorbed by "business as usual". In other words, the bulk of your IT budget is spent on routine projects and inevitable maintenance that are essential to the day-to-day operation of the bank. You might find this figure too fantastic to be credible, but trust me, it is true.
Second, given this first fact, you only have 15% or less of your IT budget to invest in future income streams or cost efficiencies. Yet the ideas are plentiful. How can you prioritize the ideas to ensure that they best serve your bank and its shareholders? It's a daunting task, especially since most non-IT executives can't crack the tech-code in which their CTOs speak...
Here is a roadmap to a simple but effective process to prioritize IT innovation spending:
Does it pass the laugh test? Many ideas seem appealing at first glance, and an equal or greater number appears ridiculous. Discard those first, even without a business case or an IRR analysis. Just take off the list anything that's illegal, absurd or doesn't fit your strategic direction.
Create a project prioritization committee. Assemble people (no more than 10, 8 is even better) from all major lines of business to evaluate the ideas before them. Include IT in the mix, since they can explain the issues best.
Create a SIMPLE IRR/project evaluation template. If your template has more than two pages, it has too much information. Ask yourself, "What do I really need to know about this proposed idea?" You'd include things such as target customer segment, competitive impact, investment required, timing, and expected returns. While each element might require months of research to be precise, allow a 20% margin for error to benefit from speed and avoid spending too much time on ideas that won't fly.
Let the line of business decide. Too many CTOs reluctantly become Dr. No's in our business. It's not fair, not appropriate, to put them in this position. Have the business unit initiating (or most impacted by the proposed idea) evaluate the project and endorse or discard it. They are the ones who must dig deeper, figure out whether they can truly generate the revenues mentioned in the template, and determine whether they are willing to "sign up" for it.
Once decided, avoid "scope creep". Too often we spend too little time upfront and way too much time after the project is approved. Take the time to firmly nail down the scope before any development work takes place and you'll minimize cost and schedule overruns later on.
Circle back on your IRR assumptions. One of the greatest fallacies in our business is the Pro-Forma analysis. It's often the "Anything Goes" analysis, since there is hardly ever a disciplined look-back process to verify that the assumptions (both revenue and expense) have been carried out. This is true for acquisitions, de novo branches and, not surprising, IT and innovation projects. Look-backs are ESSENTIAL to create the accountability needed to get ANY project done on time, on budget, and on revenue.
No exceptions. Be disciplined about the final budget number for innovation you came up with. New ideas and "must do" projects will emerge during the year. Your committee should evaluate those ideas against what's currently in the hopper (and the opportunity cost of discontinuing what's already on the boards) and approve only if another project gets deferred to the next fiscal year, such that the budget remains intact. Not many banks have this discipline, but it is an important tool to ensure that only the best projects get implemented.
Tighten the reigns on small projects. Most banks have an amount threshold below which no committee reviews the request. The project is too small to merit management's attention. Unfortunately, many use this loop-hole to pass projects through, and your already strained capacity ends up being spent on countless small projects. Either reduce your threshold to tighten your oversight of these small items or limit the overall dollar amount or hours spent on small projects to ensure your precious resources are wisely spent.
Reduce "one-off"s Ask your CTO how many custom projects, queries and reports they have. You'd be unpleasantly surprised. Part of effective innovation management is the creation of capacity that's currently unproductively occupied. In other words, moving people who are doing something less productive to engage in innovative thinking and projects. Putting a governor on the number of "one-off" projects, reports etc. and demanding standardization where appropriate is an important tool to optimize your resource allocation.
Whether you're an innovator or not, the above process and discipline will serve you well as you manage your already tight budgets to get the most "bang for your buck".