One of our senior directors got a call a few weeks ago from the CEO of a bank core provider. Mr. CEO complained that one of our consultants mentioned to a client that his core system was no longer being supported. The CEO passionately argued that our consultant used the term “sunset” with the client related to his core system.
Now I can see why a software executive would be upset if a consultant told clients that his core was no longer viable, but software can stay in the market a long time in “maintenance” mode. So perhaps we should spend a few minutes on how software decisions are made at the core banking system providers.
Let me explain.
Over my career, I spent several years managing software development teams through the Project Management Office (or PMO), including quite a bit of time at a large core provider. One important thing I learned: not all software gets the same amount of attention from the development team and senior management.
Think of it this way: software companies have only so many resources to allocate to software development each year. Software development is an expense for a core banking systems provider. Based on sales from the previous year, depending on how much profit the management team wants to take and how much they want to spend on developers, they budget how much ends up in that specific software development bucket. If you are a CEO or CFO managing the budget at your community financial institution, you fully understand the resource allocation issue at hand. You have choices to make.
So, let’s use an example of how budget allocation works at a software provider. Let’s say a software provider has two main products in its software budget, and each of those products has three projects where they can allocate their software developers:
Product A
Maintenance on Product A
New functionality (roadmap item) 1
New functionality (roadmap item) 2
Product B
Maintenance on Product B
New functionality (roadmap item) 1
New functionality (roadmap item) 2
First, it is important to understand that maintenance is required. You have no option but to make sure things like bug fixes, software outages, regulatory updates, and third-party interface updates are covered. The software needs to work as the financial institutions pay monthly fees. So, after you have enough developers to cover maintenance, the remainder of the budget can be allocated to new functionality.
The previous example is extremely simplified because I have never seen a software product team with under 10-12 items on their development road map. But for simplicity’s sake, let’s say that 70% of the development budget of this theoretical provider goes to maintenance. That leaves Product 1 and Product 2 fighting over the remaining 30% of development time across the four new functionality roadmap items. Now, change the four roadmap items to 24 roadmap functions that clients clamor for, and you see the dilemma all software providers face. Which of those 24 projects will be funded this year, and which will have to wait another year?
Old software, once developed, is something of a cash cow. Customers pay for it either on a monthly or annual basis.
So, why do you, as a customer, care about this? Why do you need to know about development roadmaps and software developer allocation when deciding whether to keep or change your current provider?
Here is why:
Old software, once developed, is something of a cash cow. Customers pay for it either on a monthly or annual basis. If the software provider can convince its current customers to remain on the product and cover basic maintenance, everything else is profit — all the revenue — very low expense. It is only after enough customers leave that software platform and the revenues do not cover maintenance that the software provider needs to either sunset the product or migrate customers to a newer version.
Oddly, it is in the software provider’s best interest to keep some products in “maintenance-only” mode. Older products are often their most profitable. You, the customer of a product gone into maintenance mode, have probably seen some of the signs of one of these cash cows:
- Roadmap items never get finished.
- You are paying for the provider to develop new functionality, which the provider can offer their other customers.
- Quotes for customization or professional services seem exorbitant (they may not have the development team available to customize).
- The only items in their development release notes appear to be maintenance or bug fixes.
At Remedy Consulting, our business includes helping customers through Request for Proposals (RFP’s) and demonstrating new software products through our System Selections. Generally, a bank will start an RFP when they suspect their product is just not keeping up with the times, but they often do not recognize these signs of an under-maintained product until we discuss changing the software.
Think about it: the software provider would be insane to tell their customers that the product they currently pay for is no longer at the top of their development priority list. They hope customers renew their contracts and that new functionality is less important to the current customers than the base model you have had for many years. Maybe what the customer pays for the software currently is cheaper than replacing it with another product.
So, let’s go back to Mr. CEO at the top of this article. If you were the CEO of a small core provider where profit margins are already tight, and then you lose some customers, now you hit the tipping point where you need to start laying off developers. Or, at a minimum, struggle to maintain the software without having the resources (or the interest?) to update new functionality.
If this was a larger core, Mr. CEO could migrate his customers to a new product and officially sunset the older product. But smaller cores cannot do that, as they never had the resources to build a newer product. Mr. CEO is in a bad place, and although he didn’t declare a sunset of his product, he also has not built new functionality into the product. From our perspective, it would be hard to recommend the CEO’s core to one of Remedy’s clients in RFP mode.
So, how can you use what we discussed? If you are responsible for making vendor decisions at your bank, keep an eye on the indicators above. If you realize that some software providers are not delivering on their roadmap items, decide what is important to you. If the product is not customer-facing, the price is low, and your team does not require cutting-edge functionality, that might be okay. Consider finding a consultant who knows market pricing during your next renewal and see if you can get a better deal.
However, if a laggard product is client-facing or drives revenue for the bank, it may be time to look at other vendors to see what else is there. If you are already in the process of an RFP, have a product you like, but haven’t spent a lot of time on the product roadmap, consider talking to the vendor’s client references before buying and ask about that product’s history in developing new functionality. How many items have been delivered from the roadmap in the past 18 months?
Please reach out if you are looking for help to determine if you need to complete a system selection.
Charlie Kelly is a Partner at Remedy Consulting and host of BankTalk Podcast. Remedy Consulting helps financial institutions (FI) thrive through specialized consulting services in System Selections, Core Contract Negotiations, Outsourcing/In-House Advisory, Bank Mergers & Acquisitions, and FI Strategic Planning. To learn more about Remedy Consulting, visit www.remedyconsult.net.
