Loading...

The Remedy Blog

How to figure out if your Core Software has been Sunset (without you knowing it)

| by Charlie Kelly | 0

One of our Sr. 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 as it related to his core system.

Now I can see why a software executive would be upset if a consultant was telling 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 Sr. management.

Think of it this way, each year software companies have only so many resources to allocate to software development. Software development is an expense for a core banking systems provider, so, based on the sales from the previous year, 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 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 that a software provider has two main products in their software budget, and each of those products has three projects where they can allocate their software developers:

Example:

Product A

Maintenance on Product A
Product A – new functionality (roadmap item) 1
Product A – new functionality (roadmap item) 2

Product B

Maintenance on Product B
Product B – new functionality (roadmap item) 1
Product B – new functionality (roadmap item) 2

First, it is important to understand that maintenance is required. You have no option but to make sure that things like bug fixes, software outages, regulatory updates, and third-party interface updates are covered. The software needs to work as the financial institutions are paying for monthly fees. So, after you make sure you have enough developers to cover maintenance, the remainder of the budget can be allocated to new functionality.

The above 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 the product managers of Product 1 and Product 2 to fight over the remaining 30% of development time across the 4 new functionality roadmap items. Now, change the four roadmap items to 24 roadmap functions that clients are clamoring for, and you see the dilemma that all software providers face. Which of those 24 projects will be funded this year, and which will have to wait another year?

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 their current customers to remain on the product, and cover very basic maintenance, everything else is profit - all the revenue - very low expense. It is only after enough customers have left 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, as the customer of a product that has 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 then 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.

Generally, a bank will start an RFP when they suspect that their product is just not keeping up with the times, but often they do not recognize these signs of an under-maintained product until we have the discussion about changing out 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 that CEO's core to one of our clients who are 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 of your software providers are not delivering on their roadmap items, decide if that 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 OK. Consider finding a consultant that 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 out 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 or so?

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. As a trusted advisor to banks and credit unions, Remedy Consulting has executed over 700 system selection and vendor negotiations since 2016. Clients receive cost reduction on their vendor contracts and increased efficiency with Remedy's Price Repository.

Do It Yourself Core Vendor Selections

Gain insider tips from the professionals in the field when you REGISTER NOW for this quick WEBINAR.

May 24th | 12:00pm CST


Trusted Advisor to Banks and Credit Unions

Remedy Consulting helps financial institutions (FI) thrive through best-in-class fintech consulting services specializing in System Selections, Contract Negotiations, Outsourcing/In-House Advisory, Bank Mergers & Acquisitions, and FI Strategic Planning. As a trusted advisor to banks and credit unions located in Wisconsin, the Remedy Team has executed over 700 system selection and vendor negotiations since 2016. Our clients receive a cost reduction on their core vendor contracts and increased efficiency with Remedy's Price Repository. To learn more about Remedy Consulting, contact us today!

Let's Talk!

Schedule a quick 30-minute call with a Remedy subject matter expert.
Sign Up Today