Ahead of the curve: A banker’s podcast episode 1 – Software implementation

Thomas Curley 0:00

This is Ahead of the Curve: A Banker’s Podcast

~beginning music interlude~

Thomas Curley 0:19

Welcome to our first episode I’m your host Thomas Curley and I’m here with Andy Snow, Senior Vice President of Customer Success at Abrigo, and David O’Connell, Senior Strategic Advisor on Aite Novarica’s Commercial Banking Team.  Andy aligns the implementation and customer success teams at Abrigo to ensure clients enjoy a seamless experience during their software implementation process. Prior to his role he served as the Vice President of Implementation where he led consultants, project managers, and trainers to help financial institutions use and roll out lending, credit, and portfolio risk solutions.

David on the other hand is a former commercial lender of 14 years. He brings a wealth of experience on financial institution’s challenges and building businesses that lend safely, cost effectively, and at scale. His coverage of lending encompasses the entirety of the loan lifecycle. So, we’re excited to have both of them on today!

We’re going to be talking about customization versus configuration of software along with some other implementation best practices. It’s been a topic of interest and a source of a lot of questions that I’ve been hearing from banking circles recently and I know that everyone is tired of talking about the pandemic, but one of the things that I wanted to talk about because it’s so important to set the stage is the fast-changing market expectations of digitalization and automation. Many financial institutions are ramping up their technology usage and purchases whether they had nothing before the pandemic or maybe they’re adding and upgrading based on some feedback over the last twenty-four months or so. It’s a lot to take in and so that’s why I’ve asked both these experts to join us. To start things off I’m going to have David jump in and really define what customization versus configuration means when we were talking about it and thinking of it and how that can play a huge factor in some on time, budget, and scope projects.

David O’Connell 2:11

Okay, thanks, very much and it’s actually a little bit difficult to define and determine the difference between configuration and customization. I think we all know these two things when we see it, but let’s think about a bit of a definition. So, I think of configuration as changing the characteristics of a software capability within the scope of variability for which it was designed and ideally with such changes made by folks without an extensive technological background. Okay, let’s put it another way. If you have meaningfully changed the capability relative to its out of the box configuration then you have probably configured, not customized.

Okay, now let’s think about customization, is any transformation of a capability such that it differs meaningfully from its out of the box version. How do we define that? Well first of all, it’s meaningful if the changes increase in a relevant way, the risk that it will break or become unstable when an updated patch comes down the SaaS pipeline, and certainly if you are changing or adding custom code then that is definitely customization. No pun intended. But with that Andy I know that on the topic of customization you have some thoughts about different flavors on unintentional versus intentional.

Andy Snow 3:46

That’s right, thanks David I do. You know oftentimes when one is heading down the path of implementing some enterprise software it’s easy to get lulled into thinking that. A lot of what you’re going to be doing is automating what you’ve already done today. Maybe it’s manual. Maybe it’s in another system and so one of the culprits to people ending up kind of in this customized state is them trying to really kind of replicate what already exists today, which oftentimes has a lot of inherent or bad habits and processes baked into it. So, I do know that when one has the mindset of transcending the status quo and really using the implementation of a new service, a new software, a new product, having the mindset of really using that as a catalyst to start fresh is a great way to avoid the pitfall of customization.

In terms of configuration, I think that you know we talk oftentimes about the pathway to allowing one to actually complete a project and begin using a new product or service. A great way to do that is by ensuring that you are minimizing the decisions that your staff and personnel need to make on a regular basis that you’re leveraging the experience of the provider of said solution and the best practices that have already been kind of baked into the solution. All those lend themselves to really putting you down the pathway of making a few decisions to slightly tweak what exists for everybody.

David O’Connell 5:41

And you know I think that there are some interesting ways that this plays out in the market or plays out in how end users and also, you know, the deployment champions, how they feel about their deployments. I happen to be in kind of a lucky situation as I find this business fascinating, I love doing research upon it, and I’m often in the neat situation of asking folks, how is your CLO deployment going? Often I hear the response, you know, I ask folks, how was your how did the deployment go? Did it meet your expectations? Were you on budget and on time? Things like that and oftentimes one might be surprised at how often I get the response that goes something like this, no and it’s kind of our fault don’t necessarily blame the vendor because sometimes you know I’m an industry analyst I’m off often asking questions in the market with regard to vendors and so folks sometimes take ownership of things not going well and the reason they take ownership of things not going well is after the go live date and some surprises. Folks realized that they maybe shouldn’t have done things as they did during the deployment and whenever they tell me no, it’s kind of our fault, it almost always has to do with customization.

Customization means that you are going to grab a whole bunch of resources in order to kind of I don’t know over replicate or over memorialize part of the pre-deployment state and anytime you do that the grabbing of those resources put you at puts you at risk of going over budget because you spent more money. Going beyond the sought deployment go live date because you had to do all these things and you tend to descope. Okay, so let’s say you have business requirements that you want to fulfill in seven or eight areas. Okay, well if you over customize in one of those seven or eight areas, one of the other seven or eight areas is going to get descoped. In terms of features functionality on business requirements met um and so that’s where I kind of feel like it’s a problem is folks telling me, yeah, didn’t go all that well but it was kind of our fault and we live in a world of scarce resources. To the degree to which we over customize it consumes resources and it has to come from something else and it will come from that something else in the form of going over budget over time or descoping something else. Andy you and I have chatted about this in the past I think on your mind are some best practices.

Andy Snow 8:30

And yeah, you’re spot on. You know when you really think about the effect and how this plays out in the real world, I think that again to kind of tie this off right? Oftentimes a lot of this is just done unintentionally and it’s just human nature. I’ve seen in many situations where people are really going to the depths of one end to really make sure that they address any and every scenario or exception which to your point then at times will just draw more attention to maybe the squeaky wheel or something that only happens every other lunar eclipse, during a leap year, and people end up kind of losing sight of the forest because they’re just kind of locked down and confused within the tree line.

So, I do know in terms of a best practice the number one is to make sure that your project your initiative has some clearly defined goals and objectives that can help remind everybody what it is you’re trying to accomplish and then also be used as really kind of a reference point, a beacon in the midst of people potentially heading down a pathway that’s really going to lead to a lot of work and attention potentially taken away from some other items. Beyond that once you do have those goals and objectives really defined, I think that having a solution when you think about customization as you eloquently put it in the beginning definition you want to have a starting point and if a provider, a vendor is able to at least share with you here is how a majority of like users are experiencing this product. Let’s start with this and then let’s just slightly tweak it based on some configurations and settings and templates. Then ultimately make it your own but rather than reinventing the wheel we start with one and then we just work to shine it and perfect it.

Thomas Curley 10:42

So yeah, that’s a great point Andy and I think we’re going to talk about a lot more of kind of the best practices and specifics moving on. But maybe we’ll flip it a little bit. We’ve been talking a lot about why does this happen from maybe a project scope standpoint but I know we wanted to talk a little bit more from the people side. What are some of the common slip ups that set folks down this customization/configuration path or maybe it doesn’t work out the way they want it to?

Andy Snow 11:15

Right? When I think about that topic, I will just say this, that most challenges that get presented during the course of a technical project implementation what have you is typically fueled by humans that have varying motivations or different motivations. And as I mentioned before in most cases, it’s not intentional and intentional hijacking of a project just because that’s in their DNA and they like to see things fail. Typically, what’s happening is they’re uncertain as to why, why are we doing this? As a result of that they don’t know what role they play and so then they start to you know, really retreat a little bit resist because they are uncertain, so I can tell you that just playing off of kind of the best practices, there’s a progression that a human needs to go through to accept some change.

Let’s just assume for this conversation, right? We’re talking about implementing something that is going to change how one does their job so that that can be that can be very intimidating and oftentimes the fear is associated with the unknown. When we talk about executive sponsorship, executive management you know, really making sure that you know we have endorsement at the highest levels for an initiative. You can’t downplay that. It’s really leadership more than anything and it starts with clearly defining to everybody. What are we doing? Why are we doing this? Who are we doing it with and how are we going to organize around it and make it make it happen? That’s the kind of progression that that one needs to be led through in order for them to ultimately buy in and accept something and be a willing participant. That is ultimately when you will be able to overcome resistance and you’ll be able to get out proactively and do it just by heading it off at the past and making sure that you are working to create awareness for everybody, generate desire because people are excited about what it means for the organization and also them individually, and then you work down the pathway then of getting them comfortable with how to use a product proficient with being able to replicate it over time and then reinforcement which we’ll talk about later. The main takeaway I’d like you know everybody to leave with here on this topic is that it’s the job of a leader within an organization and they can be and at various points within the organization to create awareness and generate desire.

David O’Connell 14:04

I think kind of pervading so to speak what Andy was saying a moment ago was the topic of change. I think change arises in two ways. First of all, folks tend to resist changes because they want to keep the steady state and they also underestimate the upside available to them that can come with change. What’s on my mind here is I’m often surprised how common it is for folks to use CLO deployment to merely automate, kind of replicate or almost memorialize the existing state and that’s really pretty interesting when you think about it because do any of us like the existing state of our commercial loan origination forms, processes, everything? Do we like it so much everything about it that we want to memorialize it in a in a new deployment? Or to put it in kind of a double negative that describes the missed opportunity, I’m surprised how often it’s overlooked that a CLO deployment is an opportunity to go blank slate on things like forms, processes, and rebuild these things from scratch. Rebuild what rebuild the CPS in general. In particular all the spaghetti on the front page that is so incredibly labor intensive, every gadget in the process and oh by the way what about speaking of change in process? Many folks use a CLO deployment to change and govern who does what, in other words to kind of institute and govern role-based sla’s. Okay so I really think that one issue that comes up is that the more we’re customizing to replicate the current steady state the more we are the more we’re missing opportunities to undertake changes that we all really want. I mean nobody really loves the way CLO is done right now and the more we customize, the less we can act like our own consultants and advocates for change in the environment that we want to have and Andy, I know you feel kind of strongly about the topic of executive management and mandate and things like goals. Thoughts on that?

Andy Snow 16:31

Yeah, I think one of the one of the biggest ways to really generate desire and people getting excited about working on affecting change and you know creating a new system with new processes and outputs is by giving them an opportunity to actually participate in it and influence the outcome. So, you know when you when you think about a best practice for organizing around this you know every group that’s going to be a potential user and new customer of a new system give them the opportunity to have their interest represented as a part of the onboarding process so that it ultimately becomes a system that was that was configured and designed by them and for them rather than done in a vacuum by people who think they know how they that group does their job today or worse yet has strong opinions on how they think they should do it tomorrow. Give people that are going to ultimately be using this thing an opportunity to get in and affect the outcome, that right there is how you create the desire is that not only have you told people why we’re heading down this pathway and the destination we’re attempting to reach. But we’re also giving them a chance to actually drive the car a little bit on the way.

David O’Connell 17:54

And speaking of driving the car, sometimes I think folks don’t realize how much a good deployment, kind of with minimal customization can actually put them in the driver’s seat. There is a persistent fear, less so as a result of the pandemic and all the digitalization that’s been required to get through it. There’s been this persistent fear in commercial lending in particular that the more automation there is, the less indispensable I am this is what lenders often think. They’re missing the fact that with the more automation they have the more they can move upwards and what I kind of jokingly call Maslow’s Hierarchy of Activities. None of us want to be doing sort of the rote stuff of our job. We all want to be indispensable. Frankly as trusted advisors rather than process handlers. I think that overlooked is the fact that with more automation, unquoted by customization the more value-added activities both underwriters and lenders can do for the client.

And then there’s also on the topic of change and engagement I think one thing folks need to be careful about is although it’s important to have sort of lots of community meetings, town hall gatherings, grassroots efforts to learn from all the various user groups what they want out of a deployment. I think that those should definitely happen, but there can be this this bad habit that happens because people are in the room. There’s a compulsion to have lots of doing, lots of thinking, and lots of seeking out of say finely grained preferences just because they’re in the room and they feel like that’s what they ought to be doing. But that can get in the way of leveraging from your vendor with a v that is by the lender, leveraging the hundreds of deployments that your vendor has already done. And kind of reside in that vendor’s institutional knowledge. ABL is ABL, well let me back up and kind of kind of not use jargon. Asset-based lending is asset-based lending I know everybody listening to us right now might be thinking David our ABL is actually pretty special, but it’s not. You know your vendor, you know when they work with you they’ve already done dozens maybe hundreds of deployments including in specialized areas such as ABL. So be opportunistic. Let the hundreds of ABL lenders that went before you with your vendor make your deployment more effective, on scope, and on time. In other words, don’t reinvent that tire. Maybe decide exactly what treads you’re going to have on it and what rim you’ll have on it. What the sheen will look like on the rubber, all those things instead of building the wheel from the ground up and Thomas back to you.

Thomas Curley 21:09

Yeah, I hear exactly what you’re saying David. There’s a lot of different ways that people can start to sidetrack implementations but it’s also important as to Andy’s point to get that feedback. So, it’s definitely a fine balance for sure. But let’s say for you know, just argument’s sake that we avoid all of those ideas that maybe kind of affect an implementation. What is the business case when we really talk about configuration and customization, why you know, separating people from it, and why is it such an important decision for an institution to think about?

David O’Connell 21:46

So, the first thought I have is that when folks customize any deployment really, it can feel like a one-time decision and it’s actually not at all a one-time decision. It’s actually the opposite of one-time decision. It’s a cascading decision with kind of profound and implications. In my opinion, and again I’ve interviewed lots of people on this topic. To the degree that you customize, you have entered the software business. That is not an exaggeration. This is a very tricky and risky decision to make either on purpose or by accident because you’re not in a software business. You don’t even want to be in the software business part-time or kind of part-time because no, you’re in the business of gathering deposits and capital. redeploying those resources as loans and monitoring the resulting risk. When you customize and most customization is over customization, you wind up with a whole lot of responsibilities down the line after the go live date that are underestimated, costly, make you less nimble when it comes time to adapt your deployment for say a new portal or some new technology or maybe a new way to interact with millennials over a channel of their preference. You know primary among my concerns is that well to get a little granular here, we’re all getting our capabilities over the over the SaaS pipe so to speak and when we have kind of entered the software business and customized our deployment because of our own supposed granular specialness; new upgrades, products, enhancements, and other things can cause deployments to become unstable. You know it’s almost like when you deploy with customization you see only the chunk of the iceberg that is above the water. Thoughts on that Andy?

Andy Snow 24:04

Yeah, spot on right? The iceberg principle, iceberg theory, basically you can’t see or detect most of the situations you know data. So, you’re spot on with the fact that what seems like maybe a benign decision to hey, let’s customize the following thing seems straightforward. What happens though is the effect of it is compounded in some degree, so you don’t think about every time a new broader release comes out, the fact that regression testing, backwards compatibility checks, all that has to be done to ensure that previous kind of workarounds and customizations are preserved and so then oftentimes what happens is that delays the acceptance of say a new release of which you could use 95% of it, but you’re unable to because some kind of issue relating to some innocuous seemingly minor customization that was done months or years ago. So, I couldn’t agree more, I think that on the surface it always looks like a no brainer something straightforward, something that’s harmless, oftentimes though, what’s beneath the sea is if you could see it then you’d never make that decision to go straight at it again.

David O’Connell 25:32

Yeah, and this trade-off really invokes a bunch of challenges with training, project timelines, dealing with one another in sort of the town hall meetings and grassroots gathering of deployments. And what can be tricky is holding the line and seeking not to accommodate every desired deployment complexity sought by sought by certain individuals or groups who are kind of favored or who have clout in the organization. I think it’s important to hold the line with these folks because as I said a few minutes ago, every customization before you do the deployment consumes resources in the form of cost or time or both. And they always materialize in taking something away from something else.

And here’s another thing, people’s perceptions before and after the go live date of a deployment are profoundly different. Before the deployment when we’re in those town hall meetings and brown bag lunches and meetings in which we’re gathering business requirements. They think they know what they want in a finely grained way from the deployment. But I’ve seen many times that they’re often wrong. It often term turns out that they don’t need the customization they think they need. They can actually get that from a configuration that’s also available or they might not even that can need that configuration or highly specialized and granular business requirement as much as they want. My suggestion is to kind of narrow the scope of customization absolutely as much as possible down to zero and maybe even minimize the scope of configuration to get live. It’s okay to be a little bit scrummy in a deployment like this. It’s okay to get live and then see if you, I’m going to use kind of fun language here, to get live and then see if you really really need those granular customizations or those god forbid actual customizations. In other words, get very careful about what’s theoretically needed before the go live date and what turns out to be a real ah real need after the go live date. Andy, you know in talking about this I think last week or something like that I know you had some strong feelings about optimization reviews. I’d love it if you could talk about that a little bit.

Andy Snow 28:15

Right – I do think in general one of the happiest days in someone’s professional life is the day they make a decision right on moving forward with a certain project or buying a product that they feel is going to you know cure a bunch of ills. Then the longer amount of time that you get away from that day things start to wane. So, I am a big believer in getting in and deriving value from your purchase sooner rather than later. And a great way to do that is as you mentioned, is having the mindset of a minimum viable product kind of out of the gate and one way you ensure you have that is by partnering with somebody that is able to share with you how many other like sized organizations with similar concentrations, what they’re doing and how they’re leveraging that product today. And it’s like the age old 80/20 rule, right? 80% of what you need you could probably start using closer to day zero than say day three-hundred and sixty-five, so a big believer in that. Getting up and live and exercising and then once you’re actually in the system and leveraging it a lot of the things to your point that you might have thought you needed at the beginning you might find are irrelevant because they’re addressed elsewhere within the system, or they weren’t as big of a deal as you thought they were going to be. But then that’s where a cadence of optimization reviews are a really important practice to really build reinforcement with the rest of your staff and team the fact of the matter is that you know how you’re using the product today might need to evolve right? As things internal or externally change right? New variables get introduced. So, it is a very good practice to constantly reassess how you’re using the tool and you might find that there are things that used to be important that aren’t anymore that you can eliminate. And there’s the need to introduce things that hadn’t been contemplated before, but the fact of the matter is that all of that is an output from you actually getting in and using the system not theorizing on the outside.

David O’Connell 30:38

And speaking of before and after go live to before and after states of the deployment. I think that the ultimate state of a deployment and its simplicity, its stability, has kind of a meta impact. On my mind here is sort of the intellectual bench at a bank in general and the fact that there’s a real war for talent on out there. Lots of commercial lenders tell me that among the biggest barriers they have to growth is the acquisition of talent that can underwrite risk. They can underwrite risk. They have a hard time finding, recruiting, hiring, and retaining both lenders and underwriters. The better your automation is, the more you’re going to attract those younger workers that you need to replace, frankly, the many baby boomers and gen xers who are retiring or are close to retiring. I just want to add here the differences between boomers. On the one hand and I’m sorry the difference between boomers and gen xers on the one hand and millennials isn’t just sort of trivia for poking fun at one another at a dinner party. We do a lot of psychographics here at Aite-Novarica Group and we’ve been doing them for a long time and there’s something really interesting going on right now when we do psychographic analyses in which we compare millennials to boomers and gen xers. We consistently see differences, differences that are not only statistically significant. You know that makes our quant people happy, but they’re actually large differences including attitudes about technologies all right?

So, it is important here are two things. First of all, it will enable you to kind of compete better. You know for you to have deployments that are easier, not over complicated, more stable. It’ll make it easier for you for one thing attract millennials. But we’ve known for a long time that loan officers and underwriters of any generation, they absolutely will change banks for technology that not only has good UI but is stable and straightforward and enables them to again be at the top of Maslow’s Hierarchy of Activities. In other words, spending more time in the role of trusted advisor with a capital T and capital A, rather than the person toiling in front of a deployment that has too much complexity. In the end, I think that and you know the best automated environments with the most straightforward deployments with the best up-time, these are going to be the deployments that are best at attracting folks. In other words, those most able to get around this growth barrier will be the ones most desirable to work at. That means good straightforward technology that makes non-core tasks easy without undue complexity. without undue complexity or use of task will be the best at attracting new talent.

So, I guess at this point it’s kind of time to summarize and I think I’ll start here. When you do deploy CLO, your primary goals should be to minimize cost and maximize adoption to deploy on scope and by on scope meaning hitting all of your business requirement. Over customization and most customization is over customization introduces friction for all of these things and it keeps you from getting all of the value from your vendor that is available. They’ve done dozens maybe hundreds of deployments like the one you’re undertaking and there’s a great deal of value in that vendor’s institutional knowledge. It’s up to you to extract the value in that knowledge by deploying based on it. Truly there are only so many ways you can configure the terms of an ABL loan. So, leverage all of their capabilities for configuration of ABL loan because configuration rather than customization will probably get you pretty much all of what you want. And memorialization or replication in automation of how exactly you do something, such as an ABL loan, how it’s done and a new deployment has far less value than you think compared to doing it based on the entire institutional knowledge of your vendor and all of the clients that that have preceded you. That’s actually an understatement I said it as less value than you might think, what I think is actually true is it has far more costs than you would than you would guess. In fact, I think a great deal of cascading disruptive costs.

Thomas Curley 35:59

I think that’s a great way to kind of end it and wrap it up. A great summary, but I think there’s a lot of discussion around customization/configuration. We’ve talked about the pandemic and some of the underlying effects as you mentioned with millennials, gen xers and so I think it’s an important conversation and one that we’ll be hearing maybe progressively more and more about moving forward over the coming months. So, I want to thank Andy and David. Thank you all so much for joining us. And for those of you that are new listeners and listened just for the first time, you can find this and future episodes of the podcast on abrigo.com or on your favorite podcast app or platform. Just search Ahead of the Curve: A Banker’s Podcast and hit subscribe. Thanks so much for listening and we will be back again with you soon.

~ending music interlude~