“People are looking for a silver bullet,” Martin said. And while some vendors might oversell the “silver bullet” notion of software, sometimes, the challenges are on the financial institution side. “Sometimes, a financial institution will buy the solution over a first meeting … but they don’t have a business case and then they expect the software to be magical. You’ve really got be deliberate about what you’re doing.”
What to do with a project gone askew
Among his tips for coping with a project that seems to be going off course? Look first to user adoption. “Get a sense of what’s going on – what are the failure points? I’d probably look toward what are those reasons that my staff or my customers aren’t using the software, and I’d prioritize those,” said Martin
A common reason for poor user adoption of software is a lack of understanding of the technology's capabilities. That can stem from a lack of training, either because the financial institution didn’t roll out enough or effective training to employees or perhaps didn’t tap into available resources, such as those of the vendor. “There are training videos, user groups – there’s a community out there for best practices,” Martin said. “The vendor has a stake in you being successful. How are we tapping into this great resource that is a vendor?”
Sometimes, financial institutions don’t adjust incentives to encourage adoption, resulting in poor user adoption of software. “It’s the old Salesforce adoption technique,” Martin said, “Where if the details aren’t [logged] in Salesforce.com, there’s no commission [earned] on the sale.”
Poor user adoption of software can also occur when a financial institution doesn’t fully test the software in operation before rolling it out. “This category sounds really mundane, but I see it so often,” Martin said. When an institution makes changes to the workflow that require bankers to re-do work if those changes cause repeated problems because they weren’t initially tested, frustrations quickly mount and the desire to adapt to changes goes down quickly.
Once the financial institution has identified the reasons for lackluster software adoption, it’s easier to address the issues, getting the implementation back on track, Martin said.
Scarce resources require planning
Martin said software projects don’t usually slip off the rails at large banks because they typically have software implementation teams, but at community financial institutions, the staff is small enough that it’s typically a top officer in charge of overseeing a new software integration.
“Community banks are often resource-starved,” he said. “In most cases, there aren’t project teams or project officers to deploy for software integrations. It sometimes rests with the chief credit officer or the president, and they’re running a bank or they’re busy already. And they may not have the experience of running a project like this and getting it right.”
“The truth of the matter is that for many institutions, they stop thinking and working on it once they buy the software, for the most part,” Martin said. “You’re all pumped up after buying the software, but you don’t really budget in all of this extra hard work to make sure people get ready for launch.”
The scarce resources make it even more important to plan ahead and include additional people from the financial institution. “What I want to share is that you can get around these issues,” Martin said. By developing a business case, sticking to it, and making sure your users are ready by launch day, “You’re going to get your money’s worth.”
