Episode 15 Transcript

Brent: Welcome to the Professional Services Pursuit, a podcast featuring expert advice and insights on the professional services industry. I'm one of your hosts, Brent Trimble and my guest today is the president and CEO of BTM Global, Tom Schoen. Tom, it's great to have you on the show. I'm excited about this episode because we're gonna split it and talk about two important topics that I think are relevant to our listeners.

First, we're gonna touch a bit on the ups, the downs and the pitfalls of the RFI process and the role of procurement, particularly in the context of strategic enterprise, platform in strategy services acquisition. And then we're gonna dive into one of the important, but sometimes overlooked topics in the process of enterprise software acquisition, which is change management and adoption. And as the heaven organization that delivers both system integration, development and strategic services, we think you've got a unique perspective on both of these topics that I think our listeners will really benefit from; some practical, real-world experience. But before we dive into those, tell us a bit about your background and a little bit about the firm BTM Global.

Tom: Thanks Brent, it's great to talk to you today. A little bit about my background. I've been an electrical engineer by training, but have been doing software for 30 plus years, longer than that and I don't know if there's an age requirement here, but the first part of my career was focused on product development. I did product development in a lot of different industries, military, government-type things, as well as retail pharmaceutical-type applications. But for the last 15 years, I've been working primarily only with services. And BTM Global is a service provider that works in the Oracle retail space, the manufacturing space and various services industries. We implement products around Oracle retail products, we implement products with NetSuite as well as Mavenlink, which is a professional services tool.

Brent: That's great. And give us maybe just dimensions of size and geography and the array of talent that you deploy.

Tom: We're BTM Global because we have a presence in Asia as well. So we execute projects that are headquartered in North America, that may have stores and operations all over the globe in Europe and South America. The company is organized with our headquarters in Minneapolis, Minnesota as well as a headquarters in Asia, in Ho Chi Minh City, Vietnam. The Vietnam folks handle our Asia implementations as well as support some of our North America ones as well.

Brent: No, that's great. And so you’re based in Minnesota, it’s entering the phase of fall, spring right now as we're recording in mid-March.

Tom: Exactly, so we're seeing some of the snow melt, but we still have quite a bit.

Brent: That's great. So with the array of platforms that your firm BTM develops, integrates and ultimately deploys for clients, you are oftentimes the recipient in that partner ecosystem of firms who are transacting with the platforms that you described, Oracle, NetSuite, Mavenlink. And undoubtedly you then start that transition or transaction many times in the procurement ecosystem. So most of our listeners, whether they're selling strategic services, maybe brand consulting transformation, others are in your space, which are strategic platform, implementation, partners and developers. Everyone has at least some peripheral experience with that, right? With the RFI, the RFP procurement ecosystem comes, of course, lots of ups and downs. I think every firm kind of adapts to that and maybe has some practices. Some might have a policy where they don't respond to blind RFIs for instance and those types of things. But we'll start with your overall view and pre-qualifiers and strategic imperatives when you begin and embark on that procurement RFI, RFP chain.

Tom: Yeah, it's a great question. With RFIs, it can vary in so many different things and it's a request for information. So you kind of respond to those with the information to be able to provide a customer with some industry knowledge and that type of thing. Those vary in a lot of different ways and they ask a lot of different things. I think the process that I'd like to really focus on is the RFP process, which is actually submitting a proposal. The RFP process is a good one for clients to gather information about the industry and the solutions that they're talking about. They could be either products or services, but it's a good way for them to do that and there is a process. The general process is you have an RFP developed, you invite people to attend, to respond and usually you set it up and say hey, if you have any questions, do this by this time, then give us a proposal. There's an evaluation, there's criteria and then there's selection, so it's a good process for people to use. I think what we've discovered as a service provider, a lot of the services we provide are complex. They're not real simple cookie-cutter type things. And when you get into that space, there are a lot of questions that have to happen.

So usually the person issuing the RFP as a specific process they wanna follow, maybe funnel out questions through a particular group or person. Although that is fine, I think where the value of what a person will get out an RFP response depends on how they run the process. One of the things that we've run up against, that's always been difficult for us, is when they say “Hey, if you have any questions, submit the questions and we'll answer them.” And one of the very first questions I always ask them is “Are you gonna share these questions with everyone?” So if we're at half a dozen people that maybe are invited, you may or may not know that, but some group of people as a responder ask you, “Hey, are you gonna share these questions with everyone?” 9 times outta 10, almost all the time, they say yes, we're going to. And I've really struggled with that, I'm not sure where that was defined as best practice because I don't think it's best practice. Because in a complex situation where there are a lot of questions that need to be asked, those questions will give away a little bit of what your secret sauce is on your solution.

So you don't wanna share those with other competitors, you really wanna keep that to yourself. And because they share them with everyone, what happens is I don't ask the questions, I make assumptions, which is a disservice to the person issuing an RFP because they're not getting a lot of good information back, not only about the solution they're talking about, but also about the vendor themselves. When you evaluate a vendor, you're evaluating them a lot on what questions they ask that tell you something about them. It tells you hey, these guys really know this stuff because they're asking some pretty good detailed questions. Or if the other ones are asking light questions or something that's not very deep, that tells you a little bit about them. So it prevents you one, from getting good information back and two, it prevents you from really, truly evaluating whether that's a good service provider or not.

Brent: What's interesting, in a lot of cases, particularly if you're dealing with a large enterprise and potentially a public company, there are certainly ethical guidelines around sourcing and not playing favoritism. And the procurement process helps check some compliance boxes. So in their mind, they've gotta run folks through this, but it's always been interesting whether we have clients who are in again purely strategic, maybe creative consulting services, or in your case, you're doing strategic consulting as well as implementation that a large strategic decision for an enterprise, in essence, gets reduced to some checkboxes and form field inputs and then it's uploaded into Ariba and then presumably scored. How often do you think, I'm curious, that a potential decision for a provider has been made or there's bias or there's maybe a pre-selection and that procurement is just a compliance type of exercise?

Tom: Yeah and that's the risk you run on all of these, right, especially in large companies that may have had a relationship with a provider in a previous project or whatever. And they're just going through the RFP process to check the box, saying I have to talk to at least three, four or five people and get their things. You know, those are the things I think service providers do, is through the question process can actually ask how many people are actually participating. It's a risky run on every single one and it's a risk-reward type thing. So basically what I do, if I'm in a smaller space and I think the project is not really large enough for me to take that risk, then I won't participate. Or I'll participate for a little while, but then I'll not give away the store with it. Not give them all of the details that require it. So my level of response will change as well. It's a risk that every service provider has to take. You have to do a little bit of homework ahead of time on why they're doing the RFP and why they're doing that. So for example, if you're working for a public entity and the public entity's doing it, that's usually the process they have to follow. And you still run the risks there as well, but that's their standard procedure of doing it. If you're going to a larger company or maybe a mid-tier 2 type thing, a mid-size company, then you have to kind of weigh that and do that. And usually they're more willing to talk to you about that. The other thing too is sometimes the interaction back and forth. So if you ask a question and the response comes back and it's pretty light or not very detailed, that tells you something. If they're really saying “Hey, wait a minute, what are you trying to ask here? I'm not sure I understand, but here's what we think the answer is” and they wanna have that discussion. It tells you something there too.

Brent: So you're using discernment based on their responses to maybe gauge interest, gauge the sophistication and potentially the requirements?

Tom: Right, exactly.

Brent: Gotcha. Without giving away any of the special sauce of your firm, maybe just in the abstract, what kind of pre-qualifier or evaluation criteria do you place on an RFI, or RFP process? Maybe it's come through blind where there is no pre-existing relationship to gauge whether or not you're going to participate.

Tom: So some of the things we look at are usually the people issuing it, have done this before, or they have a history. So you can go back into the history and see what they've done. If they've worked with the same company, for example, for the last 10 years, okay fine, then I may or may not participate in that process. Again, depending on what they're asking, I look at the RFP and the depth of the information they're asking versus the size of the opportunity for us. So if they're asking for the same huge level of detail, for a hundred thousand dollars opportunity, that might be different than if it was a million or 5 million dollar opportunity. So again, the size of the opportunity will dictate how much detail we can provide and depending on what they're asking.

The other thing too is that the questions or the structure of the RFP says a lot, so if they're basically asking the right things and again, how detailed. So if they're asking for specific resumes of people at the very early part and not asking about methodology or an approach or your solution or your experience, that'll tell you things. So when you evaluate an RFP, it's how complete and how well-written it is and it's the size and to value what you're gonna do. Because you're gonna invest hours developing this RFP. If it's not really worth it, based on the level of detail and the size of the opportunity, that's some of the criteria that you measure. A lot of times certain RFP processes are run differently if they require you to commit to a response or not, if they don't, then I'll get through the question process and then based on that and the other thing, then I'll decide again, if I'm gonna continue or not. And again, it comes down to the level of investment I'm willing to make versus the opportunity, level of detail, that type of thing.

Brent: To tie this off, what kinds of data or analysis, or even maybe postmortem do you do on these types of engagements? Of course, you know, there are win/loss percentages. I think that all firms, regardless of the type of business that they're in, services business would gauge. But any type of retrospection that gives some insight and helps maybe fine-tune those qualifiers as you go through the process or an annual year, is it more instinct or do you have some data sets that you refer to?

Tom: In addition to the criteria we've already talked about, some of it is instinct and obviously we track win/loss for how much we do. We track the hours we've invested versus the wins and opportunity size. The criteria is more instinct, I would say and the reason I say that is because in our proposals and our space that we work in is different, it's not the same. So let me use an example. All retailers say that they're very different, but in reality, they're very much the same. However, there is a lot of complexity that you're dealing with. So for example, if you're a retailer and you're issuing an RFP for replacement of all their store systems, all of their merchandising systems, I mean, basically a large part of their ERP footprint. Then I'll evaluate that and we'll have to tailor that to that response. If it's something that's really targeted, I only need this specific store system or this specific payment integration or whichever, if we stay in the retail space. Then I'll measure that a little bit differently, that's less instinct and more predictability. In our case, there are a lot of factors and usually, the responses are complex. And so we do measure the obvious pieces, but we treat it more on an individual and it's a little bit more instinct depending on the situation we're dealing with.

Brent: Gotcha, that makes sense. So an RFP has been submitted, a solution has been acquired and you've been selected to go through a strategic implementation. The software is implemented correctly, requirements are met, probably exceeded. There's a strategic roadmap for rollout and the platforms go live. But in the course of that is the case in a lot of enterprise software, the end-user adoption, maybe lacks and there are some challenges with that, right? This isn't new to enterprise software, I think we've all been in our careers, maybe the recipient of a large rollout. Maybe that's been an ERP or it's been a CRM or whatever the case might be, something that helps us transact our business. But in the past couple of years, just the surge and the acceleration of more digitization of processes, as well as modernization, you know, you described a retailer that's completely ripping out a legacy system in modernizing with a new one. Adoption by end-users, ultimately in many cases dictate the ultimate success and the ROI and the gains and the transformation of the business hinges on adoption. And I read a recent survey coming out of HBJ that executives of their own firm, I think only 30% of them rated their organization as highly effective at driving user adoption for employee-facing software. What are some macro trends you see in your career, particularly with BTM around this notion of adoption and improvement or regression, I guess in some cases?

Tom: Everyone thinks of change management as either just training or something you do at the end of the project. And one of the overarching goals you want to do, especially if you're doing a large transformation of your ERP systems and the way your company's operating is everybody has done some of these before. You know, there's gonna be bumps in the road and what happens is sometimes the internal client team gets a little frustrated, especially the person, either at the store, in a retail case, or on the manufacturing floor, whichever. They're getting disgruntled and when the system doesn't work or there's a little bit of a bump, what happens is a lot of them say “This system's terrible,” and that's the last thing you want to have happen. You want them to believe in the system and believe in contributing to the success of the implementation, but that doesn't happen just organically, you have to consciously make an effort to get everybody on page. So for example, I did an implementation with a client and what we did is because it was a big change for the company and how things were going to operate, right at the beginning when we were still defining the business process or requirements and even before design, we took the show on a road and actually went out to different locations and presented them. “Here's the plan, here's what it's gonna do, here's why it's gonna be good for you. And that kind of communication to the field was just extremely valuable because now they're all buying into that. They're all saying okay, this is gonna be great. So when you came to that bump in the road, they weren't saying the system is terrible, they're just saying hey, wait a minute, this is what we have to do to fix it. So they're all kind of aligned in the same way.

So we say communication is important for everything, whether it's change management or relationships or whichever. But this is extremely important for adoption because if you wait too long and they're kind of guessing and the first time they see the system is a training exercise that happens in the last quarter of the implementation before you go live, that's too late, right? Because now if there's a bump in the road, or there's a problem, they're like wow, this thing's terrible. And everybody who implements large GRP-type systems has seen this. So the key things for adoption one are not only communication to the field upfront, but also, you gotta get the executives on page and the key leaders of the business, so they're enforcing it and then the people that are actually impacted. And like I said, I did roadshows before, right in the beginning and I did three, four of them and all through the process, not just at the beginning. And that was hugely beneficial because people had difficulties or problems, which you're gonna have, they had a far better mindset to solve them. And that was the key thing for adoption for me. Yes, you've got governance, you've got your C-level guys are all on page, but you've gotta funnel that communication all the way through the business as far down as you can so that when things do come up or they're having challenges certainly in the first month or whatever of an implementation and go live, that they're all on the same page. You don't want to have people sitting around going, oh this sucks and I'm not gonna do it. They're actually contributing and saying hey, here's the problem we have, I did a little bit of research and here's what we need to do. And so now you got everybody pointed in the right direction.

Brent: So it sounds like a prevailing theme. One of my follow-up questions was going to be at what stage do you start change management? And it sounds like success very early in that process, making them feel part of the requirements. And that persona level, how it's going to impact them and their daily work, as well as conveying the impact to the organization. It sounds very early in the process.

Tom: Absolutely. And it's not like you have to tell them every single detail of the project, just give them an overview. Here's the plan, here's the schedule, here's how we're gonna go about doing it. Here's what you guys are gonna get trained on and you can vary that level of detail as you go up and down the management chain, but to me, that’s almost right upfront. As soon as you have a plan that you're working towards and a process by which you're gonna implement, that's what I'd start communicating. So almost at the very beginning and it doesn't take much, it's a small investment upfront that can prevent a whole host of issues later on. And it will make your training easier, it's making your bumps in the road more manageable, your data management because usually data is a problem on data-driven systems and you have to figure all that out. And so all of that becomes easier if they have the context up front and they've had months to be able to absorb it and they're getting constant updates. The one thing I do wanna stress on is I do this in person. A lot of companies do this just by sending an email out or a newsletter. Well, many people don't do that. If you're on a manufacturing floor, you're certainly not checking a newsletter about a new program, you're worried about today and today's quota. If you're in a store, for example, it's the same thing, you're worried about today, not about tomorrow. But doing it in-person, spending that hour of time before a store opens or head corporate headquarters or whichever is worth it. Now they see a person they can talk to, they can ask questions and they feel connected to the project. Even though you're not giving them too much to do, you're just connecting them. And like I said, I did the roadshow where I went on the show, went around to various regions within the country to do this for a client and it was hugely beneficial.

Brent: Now that sounds great and it's interesting. In fact, I think Forester Gardner now indexes these digital adoption platforms that take training and distill it in more persona-led walkthroughs. Technologically of course, they deliver these through web interfaces and so forth, sometimes within the platform. Have you been exposed to some of these? Of course, in-person training sessions are always extremely valuable and in the new reality, we're doing a lot of things remotely, but it seems like the classroom or in-context training is coming back. But have you had any experience or seen end-clients who once you are through with the implementation and you've taken them through the journey of wherever you've been contractually or from an engagement perspective, engage in change management? You know, new employees join firms all the time. There are new tranches of users who are gonna come into your platform. Have you had any exposure to the DAPs and any good, bad or different types of feedback?

Tom: So there are a couple of things with this that are good. And whether you do this in-person or over the wire and again, if you've communicated this through the process, the people already know a lot of contexts before they come in, which is good, the training needs to be scheduled in a day in the life, right? It needs to be a day-in-the-life thing. There's too much training I see now that says okay, here's how you do it, open this screen, enter this. And it's very methodical as far as this is what screen you use, this is what button you push or whatever. And a lot of it is not putting yourself in the day in the life. So if you're a merchandiser at a retailer, you want to learn and understand what their day in the life is like. How do I get a new item? How do I deal with whatever and it covers not only merchandisers, but finance people and store management, there are all kinds of things, but you gotta do that day in the life. So I think what a lot of people do is they say here's how the system works, here's how the screens are organized, here's how you navigate and all that kinda stuff. Which is okay, but it's far more beneficial to put yourself in the day in the life. Does that require a little bit more effort for a person developing the training? Absolutely. But that's the most benefit for the client. Now I can say hey, if you're a store manager, this is the kind of thing you have to do every day, here's how you do them in the system and do that. And I think defining those upfront, getting those day-in-a-life scenarios, again are gonna fall out naturally through the change management process because you've been talking to them since the beginning.

So when you go and you do these little things, you're gonna get those things almost occurring naturally. You know, how is this really gonna impact me? How do I do X,Y, Z processes in this new system? And that gives you those scenarios, so when you come down to the training at the end, not only do they have context, they have preparation, but now they think you're one of them and you're teaching them how to do their job in the new system. So that's what I've really seen that people don't do well and the ones that are successful are the ones that do it as a day in the life. It's a little bit more involved in everything, but to be quite honest, if you don't do it that way, the issues that you have for the first six months after go-live are a hell of a lot harder. Now you've got a bunch of people, ones who are thinking the system isn't working right and it's terrible and says they don't know how to use it. How do I do my job? I can't do my job. You can imagine all of the lack of adoption you're gonna have there in the complaint. So that kind of investment, if you spread it out over time, is just worth its weight and gold.

Brent: In your experience and again, speaking broadly in the abstraction, how willing have your clients been to invest in that as part of an implementation? Again, going back to procurement, driving potentially to a price and using price as the primary attribute of weighing two solutions against each other. What's been the willingness of clients to really invest in that change management early in the process, involving end-user and everything from requirements gathering to reviewing current state versus future state? And then ultimately that rollout, is that a contributing factor you see when you're evaluating and engaging the sophistication of the end client? Those that are willing to invest or potentially are much more serious about adoption versus those who say this is just kind of commoditized. And of course there'll be some training modules and videos rolled out and that's the end of it.

Tom: That's exactly the challenge almost every service provider has. At the beginning, the client's gonna be negotiating to try to get it down from a price, from a schedule perspective. And yet when you try to tell them hey, this is gonna be beneficial for you for a longer-term and this is gonna make it better, most of the people that I service do these implementations once every 15 to 20 years, so they don't have the knowledge and understanding. So the key piece of that is that you have to have that conversation to tell them here's why it's difficult. If it was easy, a lot of service providers wouldn't be you know, I mean that's why we're here and it is difficult to do because it's counterintuitive. You're telling them here's the things you need to invest in to make this a success, at the same time it's gonna cost more money. And now I'm competing with everybody else who's short-cutting it. You also have the other players too and I've run into this a number of times, which they'll underbid just to get it. Especially if it's a larger bid and then they nickel and dime the change management process throughout this. And if it costs a lot more than if we convince the client up front, that you get what you pay for, that's always a hard thing to do. And if you're dealing with procurement people at larger firms, larger companies, they don't understand that either. They’re not responsible for the implementation, they're just responsible for getting the best value of what they're getting and they don't have a good way to measure value.

So it's hard, there’s no question about it and anybody who's responded to an RFP knows that they're competing on price and if they're only looking at price, then it's a tough sell. In my experience, it's been very good explaining to them, even in a written document or a lot of times you'll have an opportunity to present your solution during an RFP process to say here's why this is valuable. And if they understand that and you can get across to that, that's actually been very successful for us. It's not just skip to the last page, look at the price and that's it right? Because there are too many other things, whether it's change management or scope or integration or data, whatever, you gotta compare apples to apples. And not every client that issues an RFP has a good process for that, so you have to understand that and you have to understand how well they're running it and then position everything accordingly. Not just leave something out just to get you a better price and then we'll deal with it down the road.

Brent: That's a great, I think, concluding thought, that ultimately that investment in enterprise software can be jeopardized by poor adoption and you do get what you pay for in implementation. So if I had to summarize some of your insights here, it's really placing a high degree of importance on end-user adoption, including them early in the process. Conversely conveying that to an organization that only goes through these transformational changes every decade or so. But spending the time to convince them of the value is ultimately invaluable and can help drive the success of adoption. And ultimately the reason most firms invest in sophisticated enterprise software and automation is to improve productivity, user experience and ultimately value and profit.

Tom: Right and to tie it all the way back to the beginning, when we talked about questions, these are questions that I would ask in an RFP, what is your experience? What change management have you done before? What other projects have you been successful at or not? In order to try and get that understanding and that should be another value for the person that's conducting the RFP to say hey, wait a minute, this guy is asking some pretty good questions, we should think about that. We shouldn't just think about price, but think about these guys who know what they're doing and we should go down that path.

Brent: That's excellent. Well this has been a really beneficial conversation with some great practical knowledge. And again, just to close out, Tom Schoen, president and CEO of BTM Global, a sophisticated, strategic implementation and platform implementer of Oracle NetSuite and Mavenlink products with a true global presence, talking to us about the beginning of the chain, the RFI, the RFP process, all the way to end-user adoption and how the two really connect. So Tom, again, thanks so much for joining, I think this will be a great episode with lots of nuggets and lots of great value based on your experience. So we appreciate your time today.

Tom: Thanks Brent, I appreciate it, it was good talking to you.