What’s Your Bank’s Backup Plan? [Podcast]

No one ever wants to think the worst can happen, but when undertaking a project that requires valuable time and resources, you’ll make the most of your investment if you give some thought to a plan B. Dallas Wells, EVP of Banking Strategies, and Jessica Stone, Director of Client Success, talk through some of their experiences at PrecisionLender and beyond that have led them to put effort into backup plans.

Podcast Transcript

Dallas Wells: Hello and welcome to The Purposeful Banker, the podcast brought to you by PrecisionLender, where we discuss the big topics on the minds of today’s best bankers. I’m your host Dallas Wells, and I’m joined by Jessica Stone. Jess and I have both seen our fair share of project implementations here at PrecisionLender, and in previous roles. We know how well they can go, and in the worst of cases, how poorly they can go. Today we’re discussing how you can plan ahead and ward off some of those worst case scenarios.

Jess, thanks for being here today.

Jessica Stone: Sure, yeah. Thanks for having me.

Dallas Wells: We’ve worked together on quite a few implementations, most of which have gone well. What we want to talk about today is some of those that have not gone well, either at PrecisionLender or prior life. Tell me about some of the cases where things did not go as planned.

Jessica Stone: Sure. Two that come to mind, the first one is actually my previous life before working in technology and SaaS companies. I worked in the world of public relations. Public relations is really fast paced, tons of work, lots of long hours. Some of the things that really hurt projects that I worked on is no one kind of taking a look at how much work maybe one employee’s doing on a team, and then for someone getting promoted, or moving onto a a new company, or getting pulled onto a different task. Basically until that person’s gone, not really realizing how much one person does, and then something as … You want to be happy for, someone gets promoted or something like that, really can leave other folks in a lurch when they haven’t realized really how much that one person has been doing. I think that just kind of has always stuck with me about going through implementations with projects, just always keeping in the back of your mind, “Is everyone aware of what everyone else is doing, and making sure that we’re ready if something great happens?”

Then on the flip side, I know here doing some SaaS implementations, and especially here at PrecisionLender. We had one case where there was an employee that had a family emergency. Of course that was a really tough situation for them, so they weren’t available. Until that time when that person’s going through this really tough personal experience, the rest of the team not realizing how much that person was doing, or realizing as they looked around that no one else at the company knew how to do that person’s work. Those have been two kind of cases in my experience where until, again, a shift happens, no one really thought about it until that thing happened, what a tough position it put the rest of the team in.

Dallas Wells: Yeah.

Jessica Stone:  Also, what about you? Any cases you wish you’d had a backup, and especially with your banking background?

Dallas Wells: I think in general banks are actually pretty good at this, as far as having some controls in place, and some backups for most of their procedures. I think though that as the use of technology, and the number of different systems, and platforms, and tools that are being used. As that gets spread farther, wider, deeper into the bank, I think this becomes more of a struggle. I’ve got a few examples that I’ve run across, and I’m sure bankers have run into similar flavors of this. I think they kind of fall into three basic categories.

Number one is the kind of classic typical one where you’ve got somebody who wants to control a lot of the decisions. They want things to funnel through them. I worked at one bank where all the commercial loan approvals, we had the typical approval process in place, but the reality was outside of that policy was that this person who acted as our chief credit officer wanted to see and give at least a verbal yes to every deal before it moved on. That was kind of understood from entry level folks at the bank, all the way up to the board level. The board knew if a deal came before them, this person had seen it and given it their blessing, so to speak.

It worked great for consistencies sake, but obviously that is a huge bottleneck in the process. Whenever this person went on vacation, basically our commercial lending kind of would grind to a halt for a week, or two weeks. Because even the very smallest deals couldn’t go on through the process like they should be able to. The kind of over controlling things, even though the procedures and everything that was written out showed that person was not a bottleneck, the reality was that was realistically how it was working. We see that a lot in banks, where there may be someone who’s listed as a backup, but they’re not really able to do it, at least up to somebody’s expectations.

The second kind, and we see unfortunately more and more of this. Again, as there’s just more tools out there, more technology in place, is really some kind of turf protection. Hoarding some of the knowledge, some of the understanding of how systems work. We see this especially where things have been homemade. We’ve talked a little bit on this podcast about build versus buy, and this is really one of the big downsides of the building your own things in house, is whoever built that, or whoever designed it, tends to … Sometimes will use that as almost a source of power, or a source of comfort, basically job security. We see this directly a lot as we’re coming in and replacing an old homemade pricing system of some kind, which is generally an Excel spreadsheet.

Whoever made that thing has used that as their base of power. They’re the only one who knows all the inner workings, they’re the only one who knows where the bodies are buried, the weaknesses of it. They’re the only ones maybe who know how to update it. They use that as, “Well basically you gotta keep me around,” or, “I’m very important going forward in this process because I’m the one that knows all this stuff.” That’s almost a cultural issue, but it’s one that we just see over, and over, and over again. Again, this is not just putting on paper, or in your policies or in your procedures that there’s a backup. But making sure it’s a part of your reality as well. That somebody else really can step in and fill that thing, and that there is a backup to run every system.

Even if it’s not that, even if it’s nothing nefarious like that. If it’s just the classic, “Well what if Dave, who built this thing, gets hit by a bus?” Heaven forbid that actually happens, who’s going to do these things? That’s a very bad position to put everyone involved in.

Then finally I have one that’s related to that, and I think some similar motivations is less about technology and more about relationships. We see this one all the time in commercial lending. “Okay, that’s my customer, so I’m the one who knows all the backstory, and I’m the one who knows the wife and kids names, and knows what they’re planning to do next year.” Same thing, kind of knows the potential potholes with this business, or with this project. That just gets really dangerous, and that’s why we see so many banks pushing towards CRM systems, or at least some way of capturing all that knowledge and sharing it, so that not only if something happens to that person, or they leave, to keep that from becoming a power issue. But also just so we can all be on the same page.

If an analyst has to call for a question about financials, they know the story, right? They know the backstory, they know all the context, or at least as much as we can get into those kinds of systems. Those three kind of broad ones I think cover a whole lot of things that I’ve seen in banks, and that we see over and over again in the clients and prospects that we work with.

As we think about these things, Jess, what are some things that you’ve … I know that you lead a lot of these projects, and helping our clients think through those. What are some good practices that you’ve come across to help folks ensure that things like this don’t happen? How can we have a big project be successful? We talk a lot about making someone the owner of that project, but also somebody that can step into those really critical pieces.

Jessica Stone: Yeah, so I think there’s always room to grow here, but we’ve been making a lot of strides, and we’re continuing to improve so we’ll just pass along some of the things we’ve learned thus far. The first one I’ll say is documentation. We at PrecisionLender as a company, and as it relates to our client relationships, we do our very best to document everything. We record calls if we feel that other people might need to kind of hear from the horses mouth what a client is going through, or refer back to something for a really technical detailed explanation. Every time we have calls with folks, we’re making sure that others are in the loop about when those happened, making sure we know when folks have emailed, and then also just the internal processes.

We as a company are growing really fast, and we learn from every client experience, and client onboarding, and implementation project we work on. We try to document how we went about every onboarding, ad then look back after we went through it and say, “Okay, what went well? What slowed us down? What did the clients say, hey that wasn’t as smooth as I’d like to be, and help improve it.” We do a really, try to be a very, very purposeful about documenting our processes. Here at PrecisionLender we have what we call our, “Internal Wiki.” Everyone has access to it, we can add to it. I know other folks have other platforms. I know a former company I worked at, they use Google Docs for their kind of internal documentation. But making sure there’s a place that everyone has access to, everyone knows that’s kind of where to go to for the record on how you go about things at the company or at the bank.

Another one that we’ve learned, and we’ve learned kind of the hard way, but is doubling up on resources when the task at hand is kind of really large. We had two team members recently who sat in on each other’s calls, because there was kind of enough going on, and enough complexity that if one person … I know you said the hit by a bus example, I’ve heard the more positive one is, “If someone wins the lottery and moves off to The Bahamas,” making sure that information is not just in one person’s head. Of course again, things are going to be documented, but someone else listening in on really key and important calls to offer that little bit of context. Or if someone, it’s called, “Season,” if someone goes out when they’re sick. Things like that, that we’re doing everything we can to stay really streamlined, so that the clients aren’t impacted at all. That’s been a good lesson learned for us, and we also encourage that of our clients as well.

Then one thing that our development team does that’s really interesting is they have team rotations. If you’re familiar with PrecisionLender, there’s different groups of developers that work on different parts of our platform. Some folks work on pricing, some folks work on the relationship awareness module, some folks work on the connectors, connecting to a CRM, things like that. What they do, though people have definitely a focus in an area, every once in awhile the team leads will start to switch around team members and say, “Okay, the person that was on the connectors group is now going to go work on pricing. The person that worked on pricing is now going to work on relationship awareness.”

That’s because they want their developers to really build up their knowledge and expertise in all different types of coding and development as it relates to our solution. It really, I think, makes the developers better for it because everything is so integrated, that they understand kind of what each group is going through cause they literally walked a mile in those folks shoes, they’ve done it before. Those are three things that we do here that I think has really helped us, and kind of prepare for worst case scenarios. Any I missed that you can think of?

Dallas Wells: Well, I think specific to banks there’s probably maybe some additions to that, or some slight variations of it. Again for the most part, the daily procedures, I think banks have a pretty good handle on most of those. Those really critical ones, you may want to do a double check on them. Those processes are generally in place. I think where we see more issues coming up is not in the day to day stuff, but more in the projects. Again, more technology is the … The pace of change in the industries really picked up over the last few years. With that has come a lot of projects. They’re very cross functional, and we’re pulling together different, members of different teams in different skillsets. So you’re not working within just the same department with the same four people all the time, where you know who backs up what. It gets a lot fuzzier, and a lot harder to follow.

What we’ve found helpful in at least some of the big projects that we work on, is to really kind of work backwards from that end result, and find out what really the critical path is. If you start looking into Googling critical path, and project management, it can get really complex, and there’s, of course there’s all kinds of software, and experts, and consultants, and folks that will help you with that. That’s not really what I’m talking about. I’m talking about much simpler and more of a common sense level. What’s the potential bottleneck in this project, is there anywhere where we’re relying too much on one person, and knowledge that only they have? In those cases let’s double up, right? Let’s have somebody help them with that, let’s have somebody else at least know faintly what’s going on. We try to do that on our side, and we try to point out those places for the banks as well.

Then, where we come up with cases like the one you mentioned where there’s a family emergency. If that’s in that critical path, the thing that could be potentially the bottleneck for everything behind it in the project. Let’s make sure that we have those things covered. It’s really planning ahead of time on all those projects. We actually spend a fair amount of time on that. Of rather than just jumping in, let’s spend the first couple times that we talked, the first few conversations that we had, laying out this groundwork. What’s the project look like, what are those critical points, who’s doing those, and are we comfortable with how all that’s setup?

I think another one that we see that again, is fairly common and makes this difficult sometimes, is all the jargon in banking. Again, all technical businesses are like this. They all have their special language that we use. Banking is one of the worst one’s, just because there’s all the … In addition to just the usual, there’s the technology and the finance part of it, which gets deep enough on it’s own. Then you add all the regulations. I was at the bank directors acquire or be acquired conference a couple weeks ago in Phoenix. There with some co-workers, and they kept rattling off the BSA, AML, Bank Secrecy Act, Anti Money Laundering. They’re rattling off all these acronyms, and they’re turning and looking at me like, “What does that mean?” That’s a fairly easy one for somebody in banking.

Where it really gets tricky is when banks take that a level further, and then they have their own internal language. Everybody’s grading systems, their risk grades, their facilities grades, those really have to be untangled because they have their own special names, and you have to have this decoder ring to figure out what they’re talking about. Again, as you get into a project you’re maybe pulling in one expert from that area, and they speak a different language than everybody else on the team. Then if we’re not prepared for if that person leaves, wins the lottery, whatever you want to look at it, or just is on vacation for two weeks during this three month project, does it derail everything because nobody else has the decoder ring?

We just have to be careful about those kinds of things. Again, knowing that up front I think helps. Then finally, last thing, and we used to do this a lot. Really the first in depth one I saw was around disaster planning, but I think that’s a good framework to use. Where we would take systems offline to kind of test what the impact was. Sometimes there was things that you just couldn’t take down, so we would at least sit around a table and say, “Well, what would happen if we did this?” Don’t just think about systems. “What happens if are … How we send and receive wires goes down?” Also, “What if Susie in operations is gone? Let’s think about all the things that touches.”

That’s part of the reason that a lot of banks still have that mandatory vacation time policy in place, is it’s not just for security reasons around who has access to accounts, and money, and that kind of stuff. It’s also sort of like a test we do sometimes with procedures. When things start to feel complicated for us we take them away, and see who yells. This is kind of a similar thing of pull somebody out of a process, pull a system offline, and see who starts yelling, right? You’ll find out pretty quickly what breaks.

Take things out of place, take people out of place, move them around, some of that cross functional rotations like you mentioned. Those kinds of things help. Where you just can’t do those, at least think through them so that you can find the potential really big roadblocks. These things are going to come up, we just have to make sure that they’re not the really big things that can derail a project, or have too many zeroes attached to the potential cost of them. I think that’s the basic idea.

Jessica Stone: Exactly.

Dallas Wells: Jess, anything we’ve missed, anything else you want to add?

Jessica Stone: No, I think that’s it. You covered a lot of what we’ve talked through. I think one thing we’ve learned is if internally there’s things that have terms like, “Secret sauce,” just make sure that more than one person knows the recipe, then you should be good to go.

Dallas Wells: Yeah, and it is really simple things like that. We come across those all the time, where we’re like, “Hey, who in your organization can help us figure this out?” They’re like, “Oh, well that’s this person, but they’re on vacation.” Now our whole timeline is pushed by a week while we wait for them to come back and be able to wade through all their email and actually get back to us. Surprising how many of these things there can be. Again, work backwards. If there’s a place where being behind by a week is a problem, that’s where you really need to dig in.

I think that’ll do it for us today. We’ll wrap it up there. Thanks again for listening. You can always find more information about today’s episode, as well as all the others at PrecisionLender.com/podcast. If you like what you’ve been hearing make sure to subscribe to the feed on iTunes, SoundCloud, or Stitcher. We’d love to get ratings and feedback on any of those platforms. Thanks for listening, until next time this has been Dallas Wells and Jessica Stone, and this is The Purposeful Banker.

The post What’s Your Bank’s Backup Plan? [Podcast] appeared first on PrecisionLender.