Over the last several years, we have rolled out the PrecisionLender pricing and profitability solution to hundreds of banks and thousands of users. And, if I’m being frank, we’ve achieved varying levels of success during implementation.
A few clients have taken to the new approach quickly, and were off and running with huge results right out of the gate. A few others haven’t been as successful, and have struggled to get the right people on board with all of the changes. Most fall somewhere in between. They see tangible results in a short time, but know they are still leaving money on the table through their inability to get everyone rowing in the same direction.
In short, we know firsthand that change is really hard, especially when you are changing something like pricing, which is so cross-functional and touches almost every part of the bank.
But, it’s not the technical aspects of a software implementation that cause the difficulties. That’s a small fraction of the work. The real difficulty comes from undoing old processes and replacing them with an entirely different approach.
To put it simply, people don’t like their habits to be upended, and we are harbingers of BIG change. The success of our tool, and therefore the folks in the bank who championed it, lies in our ability to roll out systemic changes across multiple departments.
As a banker, I struggled for years with grasping how to implement change. I saw inferior tools and cumbersome processes, and charged in like a bull to fix it. Unfortunately, my approach didn’t have a whole lot of finesse, and I often left another mess in my wake. Through some trial and error (and a lot of bumps and bruises) I eventually learned a few tricks of the trade, and managed to make forward progress on my projects with less collateral damage.
At PrecisionLender, we’ve received an accelerated version of that education through hundreds of implementations and by learning from some of the very best in the industry. In this post and the next, we want to share those lessons, and maybe even help a few bankers prevent some of their own bumps and bruises.
We’ve found there to be 6 vital components of a successful implementation – we’ll cover three today and three more next week. While we’ve earned our implementation stripes rolling out software in banks, these lessons can be applied to change (of tools, processes, people, etc.) in any type of organization.
Culture Change
In my last post, I wrote about the difficulty of implementing change in an organization and how banks in particular get a bad rap when it comes to innovation. Using the infamous (though embellished) five chimps experiment, we explained how vital it is that bankers do everything they can to create an environment where it is okay to try new things. And, just as important, where it is okay to occasionally fail.
This culture change must happen, at least at the team or division level, in order for any meaningful change to be achieved. It acts as the foundation for everything else in this list.
Sell the Future State
In order for any big project to succeed, you have to sell the future state and all its accompanying glory. We all know that the journey may be a difficult one, but if we can at least see the light at the end of the tunnel, we can get on board with it.
There are two important distinctions to make here. First, the benefit of this future state is all in the eye of the beholder. For example, we see an almost equal split in the champion of our clients between finance and lending. In the finance/treasury world, they may be excited about better risk adjusted returns, improved margins, and better allocation of capital. The lenders? Not so much. They need to know how it will affect their ability to serve their customers and grow their portfolios. If the project creates an impediment to either of those, then it is likely doomed from the outset, regardless of what it can do for margins and capital allocation.
In a similar vein, if the lenders are excited about getting a sales and negotiation tool to win more deals, the finance group may have a little heartburn: Are we letting the foxes guard the henhouse?
An effective project will take an inventory of each stakeholder, and make sure there is a future state for all of them that is worth the effort. If you don’t have that, then you might need to rethink the whole project.
Secondly, selling the future state doesn’t mean you need an unalterable master plan. You will learn as you go, and plans will most definitely change. You aren’t selling a precise road map, but rather the improvements that will be seen once you get there.
Get User Input Early and Often
In the “old days” of software and systems (like 5 to 10 years ago), all vendors knew to sell directly to the C-suite, and then the bosses would impose the tool on the end users. The tool was used because it was required, but the end users often hated it, as it was chosen by the people who would have the least amount of interaction with it.
A classic example is the early versions of CRM, where management teams wanted all of the data and insights into the sales process, but were not the ones who had to actually do all of that manual data entry. Instead, the software was just something inflicted on the staff so the bosses could get the reports they were after. Let’s just say the results weren’t what was promised, and a lot of organizations soon abandoned some very expensive projects.
We see a similar issue with pricing. If the end users – in our case the Relationship Managers – don’t use it, then nothing else matters. It doesn’t matter how robust our reporting is or how flexible the product configurations are if the RMs hate it.
Therefore, we design everything to start at the lender and work backwards. In our opinion, this extends all the way to the buying and implementation process. Before buying PrecisionLender, we’ll insist that the lenders see it and agree that it’s a tool that will be valuable to them. We also suggest putting a couple top producers on the project team. They usually resist at first, but it is the best way to make sure they get a voice in the process. We don’t want to impose a tool on them; we want to let them help design a tool that allows them to do their job better.
This same principle applies to any new tool or process. The end users, those who will be most affected, should not be the last to know. Getting their early buy-in and giving them a seat at the table will head off a ton of problems later on. After all, it’s a little harder to revolt against a tool or process when you had a vote at the very beginning. Skin in the game is a powerful motivator to make it work.
In part two next week, we’ll look at three more aspects of successful implementation – establishing a clear owner, tackling things a bit at a time, and finding the quickest path to value.
Changing systems within a bank – and the many challenges that comes with this – is also a major topic in our book, “Earn It: Building Your Bank’s Brand One Relationship at a Time.” You can click here to see the chapters we’ve written so far, as well as the ones that will be coming soon.
