SPEAKER_00 0:02

Welcome! You are listening to the CRM Success Show, where you will hear from CRM executives who have overseen some of the most interesting and complex CRM implementations. Your hosts, David Mostri and Kiro Whitey, will be bringing you real stories, real insight. Follow along on social media for updates on new episode releases, exclusive content, and much more. Enjoy the show and thanks for listening.

SPEAKER_03 0:29

Welcome to the CRM Success Show where we deep dive into CRM success and failure. We're delivering real stories with real impact. I'm Dave Mastery.

SPEAKER_02 0:37

And I'm Kirowitzi.

SPEAKER_03 0:38

And today we're talking with John Boller, Senior VP of Enterprise Data and Salesforce. So welcome, John.

SPEAKER_02 0:46

Glad to be here. It's good to have you here, John. Thanks for taking the time. We appreciate it. So we like to start nice and easy with our podcast. Tell our listeners a little bit about yourself, uh, your career kind of uh a high level and how you got into Salesforce and some of the stuff that's been uh keeping you busy over the recent years.

SPEAKER_01 1:08

Uh for sure. Uh first uh grateful to be here. Uh really enjoy um the podcast and just a uh just really a kudo. I think uh, you know, as I've listened to the podcast episodes, there's some really valuable information. So this is kind of an encouragement to anyone listening to this that you should look back through episodes because some people have made some some great things. Um great things, sometimes some great mistakes that you can learn from. Uh so really appreciate, I really appreciate that. Appreciate the effort to put this together.

SPEAKER_04 1:45

Um thank you.

SPEAKER_01 1:47

So I really describe myself as someone who has has lived a quite a while uh in on the technology side, but the same amount of time on the process side. And what I mean by process is you know the ability to understand how business operates, how they make money, uh, you know, what are the basic components of workflow. Um, and then from a technology side, uh, you know, I started building databases uh early in my career and uh moved into user interfaces and and other things. So um my skill set matches nicely with with what I was asked to do uh for the Salesforce program. Uh I led uh for uh upwards of six years. And um, you know, my challenge in that really was to try and and have both of those conversations with uh business users, and still to this day it's a struggle uh because you know sometimes the process side of the house just gets lost, and uh sometimes people see platform as the answer when it's actually how you implement the platform is more of the answer. Um and I I think we'll have some good conversation today uh you know about that.

SPEAKER_02 3:11

Fantastic. So where did you get your first taste of Salesforce? Was it back at Gempact or prior to that at McCesson?

SPEAKER_01 3:20

Or it was prior to that at McCusson. McCusson was an early adopter of Salesforce, um, and I didn't work uh you know too close uh with the platform, but I I knew the uh the woman who's in charge of it, and uh you know, we would have some conversations. Um prior to McCessin, I actually led a Siebel uh implementation, okay, which was painful. Um and that was a very long time ago. Uh that was pre-2008. Um but yeah, that was my first first exposure to it.

SPEAKER_02 3:59

Good. And I still think McKesson have one of the largest uh Salesforce instances in the healthcare space, from what I've heard, um, and obviously have a big presence local to both of us in in Dallas as well. Um so so from from McKesson, you find yourself uh at Gempact um working on a lot of uh RPA type stuff, continuing this kind of Lean6 Sigma um you know experience, which we're gonna cover a little bit more detail uh later on in the show. Um but do you want to just give us a quick highlight reel of of Gempact before we uh talk about where you really kind of got got the taste of sales for us?

SPEAKER_01 4:37

Yeah, yeah, Gempact was definitely a process-focused uh role. I uh was in the role of a master black belt, so I had black belts that that reported me, and and then we had a pretty robust uh greenbelt program where we would train our generally our mid-level managers and senior managers on the basics of process. So it might be something as simple as you know, how do you build a process map or how do you identify waste in a process, lean it out, if you will. Um during that work, um one of the frequent challenges was data that was trapped in a vendor platform or a vendor system. Uh and because Genpack does a lot of BPO work, uh that was not something that we had great access to. But if you look at the mortgage process itself, there's a ton of time spent in processing. And generally, processors capture all the information about you know the the cycle time and the issues, they capture that in notes, free form. Um, and so the the challenge that really rose up at Genpact was how do we leverage that data? And that just naturally led to an RPA solution. Um and based on the success we had with RPA uh on the mortgage side of the house, I moved into the digital side of the house uh with Genpact, which was ML, NLP, NLG. You know, we didn't we didn't even talk about AI at that AI at that time, it just it just didn't make sense. Um and then from Genpact uh moved to uh to first united, um where I uh lead the Salesforce program.

SPEAKER_02 6:34

Great. And um First United, uh obviously we know them as the bank, but again, just to clarify for listeners, uh high-level, I believe 100th largest bank in the US, uh around there, you know, about 15-16 billion in assets. Um a large Oklahoma, Texas community bank, fair fair to say, one of the go-to's.

SPEAKER_01 6:59

Yeah, absolutely. Kind of functioning like a network of community banks um at this point, uh, with uh you know, kind of six central uh communities that that uh that the bank serves. So yeah.

SPEAKER_02 7:17

Awesome. Good. So we want to talk a little bit about um partner selection. Before we do, I guess in that nine year period of time at First United and going back to your experiences with with partners, but let's focus a little bit on First United. What was the landscape like in terms of is this is this a business that have always done it this way and and leveraged partners? Is this a more recent thing as as they've expanded and they just haven't had the internal resources? Tell us set the scene a little bit in terms of the the the partner atmosphere and and kind of what that looked like.

SPEAKER_01 8:01

Yeah. So um I would say that uh prior to us getting on this journey of of implementing Salesforce, which started uh at the end of 2019, um the only partners that were brought in prior to that were really around the banking core. Um we we outsourced a lot of you know like the digital banking experience that was really you know managed and and hosted even by uh by a partner. Um and and there wasn't a ton of um technical demand from the business. Um the you know the real growth engine of uh First United is the lending uh arm of the bank. Um that is very much locally managed. Uh you know, the kind of the mantra is uh uh fast decisions, fast local decisions. And so technology sometimes just doesn't mesh with that. And so there really wasn't a need uh to go seek out that expertise because the expertise lived within the lender themselves. They they had the relationships, the knowledge of of the of the guidelines and and credit uh decisions that were going to be made. When we got to that point of of uh saying we're going to do Salesforces in our organization, um partner selection really hadn't been done. And so uh, you know, when we first talked about this topic for the podcast, uh I kind of looked back and thought, wow, we've we've made some good mistakes and we've made we've had some good success. Um so I think I think there's a lot of things to consider uh in a vendor uh partner selection uh process. And I almost I almost slipped and said vendor instead of partner. You know, that the definition of those two is also some it's critical to to define it and really establish what you want out of the relationship.

SPEAKER_02 10:18

Um how do you how do you define that then? How do you define that, John?

SPEAKER_01 10:22

Yeah, you know, a partner has um skin of the game. Uh a partner is going to be willing to uh take some risk with you. Uh a vendor is something is someone you pay something for, it's transactional. Um you know, uh a vendor uh isn't going to be as flexible. Um and of the 10 or so total vendors slash partners that we've worked with, we've seen vendors come in the door, we've seen partners come in the door. Uh, and they they both they act differently. So, you know, if I were starting this process again, you know, in in 2019, knowing what I know, I would want to be very careful with those early intro conversations. You know, how do you show up as a partner? How do you show up as a vendor, or maybe just not even use those words and ask them to describe how they show up? Uh, because a partner is in it for the long run. A vendor is, you know, we got the six-month SOW, and at six months in a day, you know, we're done, or we're gonna or we're gonna present a change order to you.

SPEAKER_03 11:44

So in terms of like an actual contract, though, it do you see a different contract between a partner and a vendor, or are they generally the same? I I to be completely honest, like I've always just thought of it as marketing. Partner sounds better than vendor. Um, but at the end of the day, right.

SPEAKER_01 12:06

I I think that's a great point, Maz. Um that you know, if if people want to present themselves as a partner, then uh they could market it that way. Um, but to your to your point, um you know, contracts uh can be very um explicit. Uh they could be very detailed, there could be seven or twelve or twenty pages of deliverables and outcomes that are going to be um that everybody's get signing up for. Um you know, when we when we wrote our first SOW uh with the partner that we uh eventually selected, um it was it was open-ended. And uh it was intentional to be open-ended and really focus on an overall outcome as opposed to you know 35 deliverables. Because honestly, the bank and the leadership and the decision makers and the technology side of the house, we didn't know how to answer all of those questions at the beginning of this process. Uh, we were learning, we we wanted a partner and we wanted a trusted advisor. And so some of the really honest conversations as we were going through this vendor selection process, partner selection process, uh, and we had three in the mix that we went through the entire process with. Um, it it talked about you know, how do we ensure that we're getting what we want and you're getting what you want, and we make lives better for our employees and ultimately our customers. And because we didn't have the answers at the beginning, uh, we didn't know everything we needed to know, that first contract or SOW needed to be written in a way that gave us some flexibility to say, you know, we think this is what we want, and we think this is how we're gonna go about getting it and delivering it. Um but we may need to adjust course, you know, in six months or nine months. And um and so the contract is written in that way. Other contracts that have been presented, you know, um are much more explicit, and um, you know, sometimes those lead to an inordinate amount of change orders, which is just additional expense, additional overhead, um, and um it doesn't necessarily allow you know your the the holistic program to move forward in the way that you want it to. Uh you want to be able to broadcast to your users, hey, this is coming, you should be excited, you know, start that change management process. Um and and sometimes that gets in the way.

SPEAKER_03 15:05

Yeah, so that makes sense. Um so it it's it's it's a it's uh this the the consulting world, the entire consulting world is a funny place because they generally will always push time and material contracts, like always. There'll often be some kind of scope in there, um, which is why we need to change order and an estimate. Um and then there's some language in terms of um, you know, this is only an estimate. If you're gonna go over, we have to tell you, and we'll discuss it. Um and it's estimated based on the scope in here. So here essentially what you did was it sounds like you kind of the so normally the the way I would approach this kind of thing, like we don't really know what we want, is we'll say, okay, let's just start with a pure discovery project, um, tighten that up, and then follow up with a second SOW. Is that what you guys did, or or you did something different? Now, I I will say that when I work with when I've worked for SIs, um not as a not as uh an external entity, I I would get pushback and then uh and I would get a comment like something along the lines of like I'm trying to close a bigger deal here, like why are you why are you making this a small project, right? Um but that's because I'm thinking in terms of delivery more, right? Than right, I'm not a salesperson who's looking to make commission. So I I but I get that response. What it was that so like how did you how did you position that the scope? Whether just in terms of we're gonna do discovery, then have basically your building saying we know whether it's gonna be a change order or a second cell after we work through, get a better definition of what we want, what it's gonna look like.

SPEAKER_01 16:51

Yeah, that's a that's a really interesting um situation, and I I'll try to make this brief. Um so we did begin a discovery uh with a discovery uh SOW, and the firm that uh that performed it, um I want to say it was an eight-week engagement. It it potentially was a 12-week, but that's that's been a long time. Um they they came in, uh, did uh you know a discovery and and really put together you know some some good recommendations on uh where they thought we should start, what we should focus on, what does a phase one, two, three look like. Um and I think generally we were pretty happy with that. Um the odd thing is when we got into the vendor selection process, um this vendor just didn't show up well. And I'm not sure if they had some changes within leadership or or whatnot. Um, again, at the time, uh this is this is six or seven years ago. Um ultimately they ended up not winning the bid for the phase one so w.

SPEAKER_03 18:13

The same vendor who who did the discovery didn't win the implementation.

SPEAKER_01 18:18

They did not win the implementation.

SPEAKER_03 18:20

Um and I think sales guy was right, don't cut this SOW back.

SPEAKER_01 18:26

Yeah, I think I think you can kind of infer how how poorly um it must have gone for them to not win the phase one SOW after already winning discovery. Um but that is that is essentially what happened. Um we ended up doing a a smaller discovery with with the uh with the partner that that won the SOW for phase one and and two. Um and I will tell you, um you know, there's there's a piece of of ownership of the partner that was at play here. Um because our lines of business um didn't have good and I hope I I hope that this doesn't you know uh rub anybody the wrong way if if uh one of these leaders happens to to listen to this, but um we didn't have something that could be communicated to the partner in a clear and concise manner around our process. We didn't have great process documentation, we rarely had process maps, and even if we did, um, you know, what was on paper um largely wasn't reality. Uh it could even be aspirational, you know, our process should work like this, because I can't really put down how ugly the process is on paper. That would I would be I would be ashamed by that or something. So um I I feel like uh you know one of the one of the learnings is our discovery should have been longer, um and our partner uh could have done more due diligence with us. Now, not to say that they weren't successful in our first few phases. Um we had huge transformational success. Uh but we burned a lot of hours and we changed, we as a leadership team, we changed our mind uh a number of times with regard to how we needed to do something. Um because our process muscle just just was not there. Um and it wasn't ready for a platform um like Salesforce, which is it's it's absolutely a you know a forcing factor uh in in corporate in corporate America because things have to be codified. Things uh you you need to know how your process works before you build it into a system. And if you haven't done that work, it it makes life you know really difficult at times.

SPEAKER_03 21:17

Um I wanna take I got so many questions on this it it's a shame. Um but I really wanna I really want to go back to the partner selection process. Um so yeah, so let's just take a step back. So you so I you you picked a partner for discovery. Um then they didn't do any of that build, but they did discovery well. I mean that's an interesting thing. So so how how did how did you go about let's say picking the partner for discovery? Where did you where did how did you find them, let's say, and what was the selection process? And then And this is now not even two months later, you're going through another partner selection process. Um and then how did you do that, let's say? And how and how did you how did you change? And like since we're talking about it, what do you guys do wrong?

SPEAKER_01 22:17

Sure, sure. Um so the two selection processes were vastly different and they should have been the same. Um we did not um I'm gonna say it this way. Um the discovery SOW was uh measured in the tens of thousands. Um obviously the phase one, phase two, those types of SOWs that last months those were not measured in tens of thousands. So the the bar that was set for the discovery SOW was maybe a little low. The selection process might have been a little casual. Um and I don't think really anyone understood that that should all be one process, one decision, because there was a lot riding on that initial discovery. We were going to make decisions around the structure of the program, the funding, the timeline, the change management aspects, all of these things were going to be coming out of this discovery, but yet the decision was made to just, oh, well, you know, we've been talking to to these, you know, to this this group, so I mean that they can do that, right? And they're gonna do it for X. And that's fine, let's just do that. Um so it was casual. It was it was a decision that was made very quickly. Um as we then stared at what we anticipated to be, you know, a much larger number for a phase one or phase two or both combined implementation. Everybody's radar came up and said, Oh my god, we have to do now, we have to do this, you know, with with a quite a heavy, quite a high level of due diligence. The bar was was raised. Um, so it wasn't casual, it was it was formal. Um, now we didn't RFP. Um, I think the thing that led to that was again we we had some relationships. We had other other banks, non-competitive, uh, but peer peer-ranked banks. Um, and we had you know input from uh from Salesforce as to who we should shortlist our our vendors, our partners. Um and that process really was um it was a combination of interview, quantitative kind of measurement in terms of um scorecarding, if you will. Um it included you know references and and researching uh the style of work, um, talking about industry rep. Um we used a committee uh for that process. So it wasn't one person, it was a decision maker. Um, I believe you had three people on that committee. Um it was talking about areas of expertise for any of these uh partners, any of these SIs, um, which we saw some of them had you know deep experience in change management and some had very little, you know, how how quantitatively can they measure success, you know, for our organization? Uh what were they you know saying would would define whether or not we were successful? Could we look at a at a metric or a combination of metrics? Um what was their style of working? Um that probably played a a heavy um that was a heavy factor in in our decision process. And and here's the here's the simple reason. Um we felt very strongly that this program needed to be managed in an agile uh manner, and it needed to leverage um you know um everything you think about with with agile. So um sprint cadences, um you know, refinement, how does that all play into our SDLC? And we had very little experience in agile. Um we needed a partner that would come in and take on the and partner with us, I should say, to upskill everyone in terms of agile. What does that mean? How do we work together? Extremely important. How quickly do we make decisions, and who's empowered to make those decisions? Um all of those things were uh no joke captured in a spreadsheet, um, scored, and and then we handed that out, you know, after the partner interviews and presentations, um, which we you know required, um everyone scored, and and really it was it was a pretty eye-opening process. Um I'm very glad we did it because the partner that we selected for the first uh three phases, three, four phases, um really did a great job, had a great culture match, and that was very important. And I think that came out in you know partnering with us uh to upscale on agile, um change management, and then um and the structure that was written into the SOW, you know, being being somewhat open-ended, uh really focusing on um some kind of intangibles, like we we want to improve the employee experience in these manners, in these ways. Um but we don't today have any metrics on that. We we we just didn't, we just knew it needed to be improved, um, and we could see the path, but you know, proving that in a quantitative uh measure was was it we were gonna get in over our skis at that point if if that's what was going to be required. You know, so it was it was two very different approaches, and I think that's a big learning lesson that you know who you who you choose to start this process and how you choose them is is an important decision, and it it should have carried over, and and we should have done everything the same way, but you know, that's a learning.

SPEAKER_02 29:31

It sounded like it's still a positive outcome though, despite going with a different partner versus discovery versus to implementation. So in your scenario, it it was for the best. Um it sounds like.

SPEAKER_01 29:46

Yeah, to to to borrow that agile terminology, we failed, we failed fast. Yeah. On partner selection.

SPEAKER_02 29:56

Sometimes it's what it's about. Um I I guess one thing I'm curious about, obviously keeping that statement of work um fairly flexible, etc. What is your reaction then, therefore, when it comes to change orders, which you did say change orders mean additional expense. How do you mitigate that? How do you find the balance between, you know, because I get it from like an SI perspective, you want it to be black and white as much as possible. Um, if it's not on a time and material basis, obviously, um, you know, you've got a price project, PL, profit and loss, you know, loss of what are we going to be profitable on this project? How many resources? So I get it from that perspective, but I see the benefit from the customer side as well. So when I'm curious, was the scope create as a result of keeping it open-ended without maybe the guardrails you would typically expect to see? And how was yours and the business's reaction when it was like, well, you know, this wasn't in our scope, and we should pay them more if we need it. Yeah.

SPEAKER_01 30:58

So I mentioned um, you know, really ownership of the partner relationship a little while ago. Um that we've had very mixed success with. Um that absolutely can complicate and and maybe obfuscate the change order process. Um and here's just an example. Um partners that had good transparency, um a solid relationship built on mutual success, not just you know, success of closing the project, um allowed us the opportunity to have conversations early. And in a few of the engagements that we've had over the over the past few years, um what I see when the transparency isn't there and when the relationship isn't there, when the partner isn't well managed, is you get to the 11th hour, and the partner says, Well, you know, we've we've already burned all these hours doing X or Y, and what you're asking for is going to require, you know, 20% more hours, or and these types of skills and resources. And in that that's been unfortunate for us, um, because we there was uh there's an element of oversight that was missing from the relationship. Um, there was an element of uh of who's the clear decision maker. Um, I've seen specific engagements here where um you know the SA on the vendor side or the partner side was making the majority of decisions, and the business um this is going to be harsh, but because the business had never managed a partner of that scale or a contract of that size before, that that specific leader was not equipped to understand the importance of being the decision maker and and asking to be informed or being skilled up or you know, just um asking for that trusted advisor to to speak to about the importance of X decision or Y decision. Um that I can't underscore the the importance of the of the relationship and the transparency. Yeah. Um now and this is this is probably fairly transparent, maybe too transparent. That first large SOW. Um we sat down with a partner and we said, look, these are the things that we want to do. Um we're not exactly clear on on how each of these is going to be stood up, but this is the outcome that we want, this is the experience that we want to deliver. And there were integrations and pursuing single pain, and um there were some data considerations. And they came to the table and said, We feel we feel fairly confident that if we if we size this at this many hours, you're going to have you know 60 to 70 percent of those hours fully accounted for, and then you're gonna have some portion that are in the SOW that will be budgeted, but we're not exactly sure you know how we're gonna use them, but we know there's gonna be overage, and everybody was fairly comfortable with that, and you know that's that I I'm sure there, you know, some people will look at a contract like that and say, Oh my god, there's so much risk, and you and you don't know what you're signing up for. Um, but the relationship was what made that uh made that plausible and and something that and palatable uh to the organization because at my level I had a counterpart, I had a counterpart at the SI. At you know, one layer above me, which was the COO, there was a counterpart at the partner that they could talk to. And those lines of conversation remained consistent and they and they were regular. Um and that goes back to that ownership of the relationship piece, who within your organization owns that relationship, who is your point of contact at the at the partner. If things don't, you know, if things aren't going as smoothly as you want them to be, um, and that's unfortunately that's been a that's been a breakdown on our side, um, is is not being clear or not putting someone who's who's had any experience at that uh with that role in that seat and expecting you know everything to go hunky-dory, and it's it just won't.

SPEAKER_03 36:37

Okay, so you're saying they budgeted it, budgeted essentially 20% buffer, at least explicitly, which means it was probably a lot more, honestly. Um so and they still went over, you're saying you still went over budget.

SPEAKER_01 36:54

Now in phase one it was oh boy, let me see if I can remember these numbers.

SPEAKER_03 37:04

Well, the the the the the question I have is that I I this was also um the company's first agile project. And agile, needless to say, or obviously, is more prone to overages because it's you know because it's agile, the scope is agile, right? You add your move, and for whatever reason, yeah, it's tend to be a lot more than the removes, right? So uh though would you not view that like I would think that that's where you would point the finger as like, yeah, you know, we renewed agile. Um was that not more of a driving factor than just kind of a relationship thing?

SPEAKER_01 37:49

It it was. Um and to be very specific with regard to Agile, what we did not understand and and and really embrace was the speed of decision making that needed to happen. Um I will say an early mistake that we made was having two people own the partner relationship, and we quickly understood that that needed to be one. Um so you know how how we delayed our own decisions led to some of that that lag and inefficiency. And absolutely, you're spot on. Um it has to do with how agile works and and how it's structured, um, and how you iterate. Um so yeah, I I I hope I answered your your question, Maz.

SPEAKER_03 38:51

Yeah, yeah, you did. Um, just one last follow-up on that. Um it's kind of a two-part question. Did your partner tell you, look, your indecisiveness is killing our budget? Were they that explicit? But they should have been. Um, any good partner would have been. Um, yeah, and if so, even if you have a good relationship and you have a good relationship manager, they're not the decision maker, right? So they need to push back on on those who are, right?

SPEAKER_01 39:26

Yeah, and and the first question, yeah, they absolutely did. They just they had a pull up and said, guys, we we have to talk about this. This is um we're we're not getting decisions fast enough. We're going to be slowing down the process. Um and you know, that was that was great feedback. It wasn't positive, but it was something that we could action on, and it was timely. So we we made that correction, I would say, three months, two to three months into the into that phase one.

SPEAKER_02 40:02

Okay. So a couple of quick quick quick questions uh on the topic before we um wrap up the partner selection piece. In general, given it's a bank, and given there are nuances with banking, right? Uh regulated environments, you're using Salesforce, you're using Encino, there are partners that specialise in Encino but don't specialise in financial services as an industry. Uh sorry, uh specialise in Salesforce as an industry, their expertise is in financial services. There are partners that do financial service cloud that have no interest in getting involved in Encino, um, for example. Um so how do you go about identifying a partner in the first place? I know you've got your your matrix, etc., you've got the AE recommendations, but in your mind, is there that peace of mind knowing that okay, well, no CEO ever got fired for hiring a big five consulting partner, let's just play it safe, go there? Do we go into the nitty-gritty? Okay, who are the specialist entino partners? Who are the specialist community bank partners, right? Did you favor more enterprise partners? Did you favor more boutique partners? Did you just favor geographic? Because I know sometimes being in Texas, we like to work with local people and go for like you know, regional partners as well. Was it a combination of all three? Um, just some thoughts there.

SPEAKER_03 41:29

Yeah, just how much of it is just pure gut or the it factor, let's say.

SPEAKER_01 41:36

Yeah. Um, I would say over the course of the program and the course of the years that this has been going on, we have gone from small boutique, you know, less than 100 all the way to big four. In fact, two big fours uh that we've had in-house. Um those those all show up differently, and it is almost always the style of the engagement manager, the relationship manager that's with those firms that that really drives uh how does this look and feel. Um, the first one was to your point, Maz, it there was some gut in that. And and we did not we did not bring in big enterprise and we didn't bring in small boutique. Uh we brought in three partners that were all about the same size, they all had good, strong recommendations. Um and and they were all doing well within the Salesforce ecosystem at that time. Um because we didn't know what we didn't know, and and there was going to be some assumption and some risk that we just had to accept um, you know, uh when we when we first started that process.

SPEAKER_02 43:00

Okay. If um again we like to ask this question, if you had to do it all again, um would you lean one way or the other? Would you would you perhaps uh stick to the big names, or would you go for more of those kind of you know, 50 to 100 sized SIs who maybe have a bit of a track record in the industry? Would you look at those that maybe know how to integrate all the different clouds and you know have done it well, or or maybe to throw a spanner in the works aren't Salesforce specific, just a good general, you know, consulting shop who who recognize how different systems and CRMs and ERPs all all kind of interact together?

SPEAKER_01 43:40

Right. I would say I would say it's important to match the partner with the business in terms of size and maturity. Um I don't think an organization our size should be first and foremost. Going to a Big Four enterprise SI or a GSI. The people who make up those companies, right? Because you know, companies don't talk, it's people who talk. So uh those companies, the sorry, those people need to be able to sit across the table from each other and have a real conversation. So I think it's very important to match the way of working between the client and the SI. You know, so if I was at an organization that had 100,000 people, you know, and and tens of thousands of licenses, then we should be going to a big enterprise GSI. If I'm at a you know a client that has less than 300 people, then I should in no means be looking at something big, I should be looking at something that's smaller, more my size, but still has the capabilities. Um I think we've made some mistakes in that in that space. Um the other thing I would say, you know, just kind of doing a retro would be um how prepared are we for what the partner needs, having those conversations early on? You know, what is a good lost one? There we go. Um how do you be prepared to come to the table with your requirements as opposed to and I think I'm borrowing this from a prior podcast, but um you know the partner shouldn't be pulling requirements from you. You should be coming to the table with your requirements. That's huge. And then the data side. The data side, you you cannot underestimate the amount of effort and amount that hinges on your data, whether or not it is you know dirty data or missing fields or you know, lack of integration, or even a lack of integration capabilities. Um those things I I would have I would have weighted those much more heavily um in our process because those they just drive a lot.

SPEAKER_02 46:19

I think it's a fair um fair way to wrap up the the segment is it's okay evaluating are they a good partner, but maybe the question needs to be are we a good customer for them, right? Um the onus is on both sides, it takes two takes two to two two to dance or two to party, whatever the saying is. And um as a customer, you have a responsibility as well to the partner. I mean, you said it yourself, right? To to make sure that the requirements are captured and presented, and we're all in in that engagement, right? It is a priority. We're seeing them as co-workers, as employ you know, colleagues, right? Just because they under a different name doesn't mean they're no no not equal and don't deserve priority meeting and so on. So I think that's a question that you know, yes, it's a competitive partner space. Um I think there's over 3,000 partners or something in North America. But there's also 70, 80,000 customers as well, right? So um are we, whoever, a good customer for that partner is uh is another interesting question to ask. Um and maybe a topic for another podcast. But Maz, you wanna you want to chip in on that before we switch?

SPEAKER_03 47:33

Yeah, yeah, yeah. If you're an SI, you need to have a strong data team.

SPEAKER_02 47:40

That's all. There you go. So kick key is data. Um, John, we um we we touched about on it at the introduction um when you were sharing a bit more about your background, coming from the healthcare, healthcare industry, uh working with Gempact, um, getting exposure to different you know environments, different industries. But it was the healthcare, correct me if I'm wrong, but I believe it was the healthcare industry where you started to get certified in Lean Six Sigma. Um and and for those who maybe um were listening earlier, we're not talking about karate or taekwondo um when we're talking about green belt, black belt, etc. Um, so we just want a couple of questions on on the the notion of of Lean Six Sigma. Um what I was surprised about when was prepping for this podcast um is how long lean has been. There were so many, so many things I didn't know, um, like how lean and six sigma were two separate things. Uh lean started out, I think, in Japan or something in the 50s. Um and then Six Sigma came later on in America in the 80s. Uh and it was I was from my notes here, it's not from memory, but um Lean was developed lean was developed in Toyota, uh, the car company, the manufacturer, and and Six Sigma was created by an engineer at Motorola. Um and then they merged in the early 2000s to become Lean Six Sigma as we know it today. So tell us a little bit about in your words, what does Lean Six Sigma mean to a transformation leader like yourself? What does it mean to companies uh as well?

SPEAKER_01 49:22

Yeah, so you're absolutely right. So um so lean started in in Japan, in Japan, and uh Sakichi Toyota, I think, is uh I know the last name is Toyota, I think the first name is Sakichi. Um I should know this. I used to teach the material. Uh, but uh he he came upon this idea um in uh in a fabric manufacturing process where you had multiple looms. And he really analyzed the process and and wanted to figure out how do I get rid of waste in this process? Waiting time, non-productive time, um, idle time, whatever whatever you want to call it. Um, so lean is observable, it is uh sometimes dealing with uh physical movement of goods, um, but it is about removing waste. And uh and waste comes in many forms. There's an acronym, it's actually TIM Woods, so each one of those is a type of waste. Um and it is a generally thought of as a groupthink activity. So if you're going to work in a lean process or a lean workshop, you're gonna get a group of people together and you're gonna talk about things and you're gonna look at things, and you may even go out on the floor and observe things such as physical movement. That's lean. Six Sigma is was developed in Motorola. Uh, Six Sigma is a data-driven evidence-based approach to reduce defects, so things that are wrong in your process, things that are erroring out, things, transactions that don't complete. Um, it is generally thought of as um you have an expert in Six Sigma who will gather a lot of data, and then they'll go in the back room and they'll crunch a bunch of data, and then they'll come out with this you know, advice on how the process needs to be adapted in order to minimize defects. Um six sigma is a reference to how clean or defect-free the process is, and um to achieve a six sigma process, you can only have uh no more than 3.2 defects per million opportunities, so it's a highly transactional. Now, as you look back over the last 20 years of business and engaging with lean or six sigma, um there are many more opportunities for lean, and lean is much more approachable for business leaders and decision makers. It is a shorter time frame, you can get people into a room and make things happen fairly quickly, you leverage the brain power of multiple individuals, everybody feels good about it. Six Sigma sometimes doesn't work in certain industries. Uh in the financial sector, that was not something that was evident in the 80s and 90s. Um, and so when you really got into the 2000s, you had higher transactional volumes, that was where Six Sigma actually started to gain some foothold in financial services. But it takes longer, and you have to pay people you know who are certified, and there's just the barrier to entry and the use cases are more limited. Six Sigma has gone down in favor. I think that's led to really us talking about lean six sigma because you bring the two together. Um as uh as I looked at you know how to how to work with process and bringing that into Salesforce. Um my real push was let's let's get into a room, let's let's use a lean approach, let's workshop some of these things because the requirements that we provide to our SI or to our partner, they don't need to be how the process works today. In that instance, we are copy and pasting whatever process we have into a new system. And guess what? Changing that system and changing that process will require even more investment. So we should be coming to the table with a significant process knowledge, but b, where we want to take it. Um, and so that you know, a little bit of history around lean and six sigma, what's the difference, but then in the context of this, you know, this show, what do you even do with that? You know, what how do I apply that from a to a Salesforce project or or an implementation?

SPEAKER_02 54:24

So it's fair to say it's somewhat of a philosophy, it's a state of mind, it's it's its own teaching. There are different levels of Six Sigma, as we talked about earlier. Oh, right, yeah. But you know, it maybe doesn't get talked about in the same fashion as change management, user adoption, training, etc. And there is still a lot of discussion in businesses around tech debt. Even scope creep is uh arguably waste, right? So the idea is is you know, is is it is lean six in a practical sense just basically uh process improvement on steroids, right? Is it just let's just try and be one percent better, five percent, say five percent, improve speed to market by X? Is it simply just that? And you know, is it unrealistic to expect more businesses to just uh more business are businesses using Lean Six Sigma without recognizing they're using it, do you think?

SPEAKER_01 55:29

Or um let me let me differentiate for you because I I I understand the where you're going with the question. Um anybody can improve a process, and you can do simple things such as look for when things are sitting around not being used, um identify when a machine, a process, a server is not being fully utilized, mistake proofing, um keeping a neat and orderly um say assembly area. Now I know that's we're not talking really talking about physical goods here, but those things are kind of common sense. Um lean is a collection of tools and approaches and a certain methodology that are specific to lean and they're necessarily not taught anywhere except lean. Um one example where it's kind of blurring the lines would be five y. Five Y is simply asking why five times to the same person about the same problem, and you get to the root cause, or you have a good shot at getting to the root cause. You know, lean is that collection. So you you have to be intentional about lean. Um can you skirt the edges and you know do some lean work without using the full tool set? Absolutely, because a lot of it is common sense, it is things that are observable. Six Sigma, highly specialized. Um, you start talking about you know a normal distribution over a uh you know a population that is of significant size to be statistically significant. Those those things you don't just happen upon. So yes, lean as sigma is process improvement on steroids, but each of them have their own tool sets and methodologies um and and process um that you should be working through in order to make sure you get the best results. Um so hopefully that it does differentiate a little bit.

SPEAKER_02 57:51

It does. Do you think you'll apply lean or six sigma practices in in your next Salesforce specific environment? Do you think it has a place still in the Salesforce ecosystem specifically? Or would it depend on the industry, do you think, that you you end up within?

SPEAKER_01 58:10

I'm gonna give you uh I'm gonna give you a yes and um yes, politicians answer. And I hope. But a a big a big component to um to buy-in for lean, six sigma, process improvement, operational excellence, there's all kinds of words that mean you know very similar things. A big component is whether or not the business invests in people who work on the business in addition to people who work in the business. Case in point, if you have a company that has 20 people, you probably can't afford to have one of those people whose sole job responsibility is to look at process and making sure that they are working on how well the business operates. They are more than likely going to be a producer or or have something that's significant uh in keeping that business a going concern. If you look at a company that has a hundred thousand people, absolutely, you're going you're going to have a need for investment on people who work on the business, not just in the business, because if you change a process and it saves five minutes for a thousand people, that's significant. And so those economies of scale play in there. So to come back to your question, absolutely. And if the leadership team isn't convinced with this program that we need some investment in process or or lean six sigma, then hopefully I can make the case.

SPEAKER_02 59:59

Good. Where do you think it should sit within a business? Um, is it is it somebody uh executive level like yourself? Is it something that perhaps an individual contributor should drive, a champion, maybe like a solution architect, perhaps, or where do you think it should sit? Is it is it does it sit across is it the responsibility of many people?

SPEAKER_01 1:00:22

Yeah, that's a that's a great question. Um it has to have a sponsor. Um getting into these workshops and doing the work around either lean or six sigma or both, it requires time and commitment. So you have to have someone at an executive level who says this is important and we believe in this, and this is how we operate. It it cannot exist, you know, without that. Um now my view on operational excellence is it is a kind of a four-headed monster, at least a three-headed monster. Um, you have to have someone who knows process and knows process work and and you know, lean or six six sigma or both. Um if it is six sigma and lean to a certain extent, you want some good data, and you need someone who helps prepare that data so that you can measure your process. Generally, that's analytics. So you have continuous improvement staff, you have analytics staff, and then in order to make sure that these projects move forward, you need some sort of PMO. So in my book, continuous improvement operational excellence is a three-headed monster, PMO, continuous improvement and analytics, and then um if you if you convince everyone, you layer automation on top of that, and um it gives you another way to accelerate um improvement, you know, it's a bottom line and efficiency, but also end user experience.

SPEAKER_03 1:02:10

So how would you or how do you apply this to software build um or even specifically Salesforce, right? Because if you're looking at a manufacturing, you know, widgets and I'm making you know 10,000 a week, it's very easy. Sample them, see what my defect rates are, how do I improve it, how do I streamline? Because it's a very repetitive process, and you have a large sample size. Software is often, right? It's a one-time build, you're doing it once. Maybe you maybe you'll have a phase two or phase three, but that's definitely not a large uh sample size, and it's so specialized, right? Each one is different, each business unit is different, each rules are different. Yeah, um, so how do you like how do you even get to a point that you have enough data to do the kind of reflection on it?

SPEAKER_01 1:02:58

Um yeah, that's I mean, Maz, you're hitting on the kind of the the crux of the of the issue here and why to a certain extent businesses have have pulled away from Six Sigma. There's many more opportunities where you don't have the data and you have a process that needs to be refined or it needs to be improved, or you just uh you know you you have a faster time to market requirement. Um lean is much more applicable in um the process work that goes into your software development. Um, it definitely focuses a lot more on how things are happening and and why we have this process. Um my advice is you know, within user story capture, refined uh requirements gathering and refinement, uh there should be some process work that occurs in there. Generally, it's a lean approach. You know, let's let's look at waste, let's look at you know, where things are sitting idle for for longer than they should be. Um with regard to processes that move onto a platform. With regard to the SDLC itself, um, you know, a lean approach is is also a good is also a good candidate for how that uh can be improved. You know, simple things such as user stories moving through your SDLC left or right. Um, do you have timing? Do you have you know stage uh measurement, duration stage management uh measurement? Is can you see where um things are taking longer than you think they should? Are there duplicative steps you know in your SDLC? Are there areas where you can um combine? Are there areas where you need to split? Uh do you look at you know parallel work streams as you move left to right? Lots of ways to work on the processes that are coming onto the platform or work on the SDLC itself applies to DevOps as well. Um you know, and environment management and um and and you know how is how code is moved and uh and and environments are refreshed as well. There's there's definite opportunity there, just leveraging those that approach um in a in a simple manner is is is a great start.

SPEAKER_03 1:05:26

Yeah, you could capture your data in uh in Jira, right? I guess for your stories. Um last question, and then we'll hand it back to uh to Kiro the wrap. Um so you you did agile, you said, right? Uh and and they tracked everything in story points at the post as opposed to hours. So how how do you track your velocity and run Lean Sigma with story points? This this non-additive thing, t-shirt size.

SPEAKER_01 1:05:54

Yeah, um, you know, what we ended up doing um was just re-looking at how we point items, um being more specific. Um and then uh let's see, how do I how do I put this? Um being cognizant of of all the work that goes into uh a given story. Um you know, I've I've talked to some individuals who have a very narrow view of what a story point is and what and what um can count towards that point, and then others who have a much more holistic approach. Um, you know, all the all the points at which this story gets touched as it moves through that SDLC and who's responsible for those touches. Um there's a lot of negotiation with that. Um you just have to get to a healthy balance of measurement and awareness without it being you know burdensome oversight and um you know weaponized data. Um there's I think there's a gentle touch there, uh, requires some negotiation and just just being as as open as transparent as as you can be um with regard to how that's applied. I think I think that's the best answer I can give you.

SPEAKER_02 1:07:26

Nice. All right. Well, John, um very very interesting session. Um partner selection is one of the biggest topics and difficulties that we hear from from customers. So I think some of the ideas you raise will resonate, and some of the the observations and comments I think will resonate. So great, great topic covering that. And I think you know, I've always been at a soft spot for Lean Six Sigma. I think he's got a place in in today's world, and I think he's just trying to find where it sits. And I think you know, there's flavour to everything that should be taken and applied and put together. So I guess if anyone wants to hear a little bit more about um partner selection or Lean6 Sigma, that they'll re they can reach out directly to you and pick your brains.

SPEAKER_01 1:08:15

Absolutely.

SPEAKER_02 1:08:17

Awesome. All right, well, thank thanks, John, for your time. Uh, for our listeners, please do not forget to subscribe to the CRM Success Show for more episodes featuring phenomenal leaders in the Salesforce space, like John. Um, we'll speak to you soon.