Episode 85 Transcript

Brent Trimble: Welcome to the Professional Services Pursuit, a podcast featuring expert advice and insights on the professional services industry. I'm Brent, one of your co-hosts, and today we have an episode that's part of a series designed to shed light and provide insights on how to go about purchasing technology or a software solution for your enterprise. It's a complex process with many moving parts and executive stakeholders. We'll be breaking it down for you and covering the process from end to end.

In today's episode, we're talking to our colleague Kurt Kilgore, the Global VP of Professional Services here at Kantata.Kurt is an expert on the topic of implementation, which is arguably the most important part of selecting and buying a technology product.Kurt, welcome, and it's great to have you on the podcast today.

Kurt Kilgore: Thanks, Brent.Great to be here.

Brent Trimble: So before we get into the nuts and bolts and the different process steps around evaluation and ultimately implementation, give us a little bit of your background and your journey into professional services.

Kurt Kilgore: Sure, I'm happy to share. My journey into professional services began early in my career when I started working on SAP implementations at Ernst & Young. It was there that I discovered my passion for consulting. From Ernst & Young, I transitioned to various software companies, where I took on roles as a consultant, project manager, delivery manager, and eventually moved into services operations.

Over the years, I've accumulated extensive experience in almost every facet of professional services. My roles have included managing global delivery organizations, leading services sales teams, overseeing customer success initiatives, and handling technology services. Each of these experiences has contributed to my well-rounded understanding of the professional services domain.

In essence, my career has been dedicated to ensuring that technology implementations deliver real business value, and I'm excited to share some of that knowledge with you today.

Brent Trimble: Outstanding. So, before we delve into the journey concerning our potential listeners going through their evaluation process, it is intriguing that you mentioned your background at Ernst & Young working on SAP, and now, you're running professional services within enterprise software platforms. What are the differences and commonalities between these experiences? Ernst & Young being more of a management consultancy, or certainly that part, and then ultimately being part of an enterprise software platform?

Kurt Kilgore: Sure.Being part of a large systems integrator or any consulting services organization that's not tied to a product is materially different. The goals of those organizations are to drive value through services that are typically product independent. These companies are focused on becoming experts in particular business processes or technologies, but they usually don't have the same level of commitment to a specific product that a vendor does.When working for a software vendor, the goal is to drive more adoption and value through your own product.These differences lead to key considerations when evaluating technology and who you want to implement it.We'll discuss some key differences to consider on this podcast.

Brent Trimble: Oh, that's great. Great contrast and wealth of experience, having done both. The topic at hand is this notion, and this is part of the series of that evaluation process—selection, criteria, and understanding from a brand or product or services firm's perspective, what's unique about their business use case and how they should go about shopping, selecting, and evaluating a platform. In that journey, most folks in our listenership and our client user base have been through this process a couple of times in their careers. For some, it might be the first time, but we've all been downstream recipients of a software selection that we didn't have a stake in selecting. Maybe we were asked for some input. For others, we've driven it and said, this platform is going to be transformative and drive our business. In that journey, regardless of role, what's your advice for a firm evaluating software for that inflection point where they should start thinking about implementation?

Kurt Kilgore: I always recommend that you think about it from the very beginning.Remember, what you're implementing is a solution that's going to deliver business results.That solution is made up of a product and a service.You should not be evaluating one without the other.If you select the best product in the world but can't get it implemented on time or correctly, you won't achieve any business results from it.For this reason, you need to assess the services component of your solution from the start.Understand how much it costs to implement.Determine if it is a simple or complex implementation.Assess the duration.Identify who can implement it: can you do it yourself, or do you need to pay someone else? Find out if the vendor provides those services, or if they are only available through a services integrator.All these factors should be clear because they influence the overall decision about what solution to select and how it will impact your business results and ROI.

Brent Trimble: Do you recommend the inclusion of this dimension? Because I hear you speak about that and understand the importance. Certainly, I work with your team and understand the detail and rigor that goes into implementing an enterprise piece of software. Do you find anecdotally that implementation is something that doesn't receive the emphasis it should and therefore should be included in the RFP part of the process for evaluation?

Kurt Kilgore: Yeah, I think most customers who are going to RFP are mature enough to include it in the RFP.Most customers have an RFP template that they're using, either from prior purchases or they've gotten it from a consultant or somewhere where they're told, "Hey, you need to evaluate this as well, " which is good. So that's a good starting point.

What I find then, though, is there's typically a big gap. They're using the RFP to drive the initial vendor selection.They may have narrowed it down to three vendors.Then they get really focused on the product for a long period of time.As they get to the point where they've already selected the vendor of choice and they're getting closer to contracts, that's typically when they want to dive deeper into the services. I think that puts the customer at a disadvantage because you should want to have a pretty good idea of what the implementation is going to look like and how much it’s going to cost before you even choose your vendor of choice.

At every step of the process, you're going to want to spend time narrowing your focus on whether this is the best product fit for you and if it’s a good services fit. What you don't want to do is pick the vendor of choice and, when you start drilling down into the services, realize you don't trust them, they don't have good references, or they're telling you that you have to use a partner when you don't want to.Those are all things you should figure out much earlier in the process because they will potentially determine who you select as your vendor of choice.

Brent Trimble: It sounds like avoiding unpleasant surprises once you've gone through the evaluation process of the platform itself is crucial. When it comes to implementation, firms in the SaaS ecosystem typically have a few options on how to tackle implementation, from design all the way through completion and configuration. For our listeners, many of whom might be new to the process or haven't done it as frequently, could you outline some of the options and what the decision criteria look like?

Kurt Kilgore: Sure.I mean, it really depends on the type of software that you're implementing and the complexity of it. Some solutions are very simple, and it's more of just a setup.You might just be paying the vendor a setup fee, and it's going to take a couple of days, and you're off and running.So there's not a whole lot to do in that case.

For more complex pieces of software, you're going to want to understand how to get it implemented. There are a few different options. In some cases, you may want to self-implement. If it's not too complicated, there's good documentation, and you have expertise in that area, you may choose to self-implement. Let's say it's a Salesforce-based product on the Salesforce platform, and you have a lot of Salesforce expertise. It might help plug into an existing solution or augment an existing solution; you may be able to implement that on your own or with a little help from the vendor.

In other cases, it may be a quite complex implementation.It may take 6 to 12 months or longer to implement the solution.In those cases, you're going to want to understand if your vendor provides those implementation services. Do they have a set of partners that they work with that also provide those implementation services? What are you looking for in each scenario?

For instance, some customers say, "I want one throat to choke." Meaning, I want to have a single contract with the vendor for the product and for the services.If anything goes wrong, I only have to talk to one person.I'm going to talk to my customer service manager, whoever that is, but there's not going to be any finger- pointing; there's only one person to do that with. So that's one approach.

Other customers may say, "No, I'd actually like to diversify. My understanding is that this is a great product, but the implementation team for this company is not actually that strong, and that real expertise actually sits with their partners." Or maybe that vendor doesn't provide a lot of implementation services. They really provide just support to their implementation partners and they really are pushing partners. So in some cases, it may make more sense to work with a certified partner to implement than working with the vendor themselves.

Another scenario would be implementing a transformation program where this product is one of multiple products.You may have a systems integrator responsible for all of them.For example, if you're implementing a CRM, ERP, and PSA simultaneously as part of a large project, you might want your systems integrator to manage all these projects. The systems integrator can then pull in expertise from each vendor as needed to deliver the overall program.

So there are several different options that you can go for.You need to figure out what is most important to you as the customer and what the vendor is able to provide.Additionally, consider what they recommend as experts in their own technology.

The other thing you would want to consider is what the contract will look like.Is it a time and materials contract or fixed price ? Some vendors push back hard on fixed pricing.Others agree but build in some risk to account for unknowns.There are pros and cons to each model, so consider all factors when evaluating your approach.

Brent Trimble: So let's assume we've made the decision to move forward with the enterprise platform and implementation, which might involve a partner or an internal team. What's a checklist of things to ask, ensure, and discuss before getting started? These might be items that, a month into the project, the client might think, "I wish we had discussed X, Y, Z more." Provide a list of essential but repetitive items that should always be on your prerequisite checklist before diving into an implementation.

Kurt Kilgore: Sure.A lot of these things are probably covered in the RFP, so I think most customers will know to ask some of these things.But from my perspective, some of the basics include: how much is it going to cost ? How are they going to ensure that they stay within the budget, meaning what's the governance that they have over the budget and the scope? How long is it going to take? Those are all key elements from a project management perspective - the scope, the time, the budget. How are they going to make sure that all those stay aligned? What's their change control process ?

Also, where is the team located ? Is the team onshore, offshore, or a combination of both ? If it's offshore, how do they stay in touch with one another? Are you going to be expected to change your meeting times to align with when the teams are available, or are they going to meet you when you're available ? All those things will impact how you work together as a team.

Do they have a proven implementation methodology ? I would hope so, and most do, but you should definitely be asking, what is the implementation methodology ? You should ask them about the difference between a successful customer or a successful implementation and a failed implementation, because I'm sure they've had both.Ask your services provider, what is it going to take for us to be successful ? They know, and you should ask.There are things they need to do, but there are also things you need to do as a customer.

It's important to remember that ultimately, you're responsible for the success of your project.They're going to help you as much as they can, but in many cases, they can't do it for you.To the extent that there are certain things you need to do to be successful, ask upfront and ensure you can provide or do those things.If you can't, pause and consider if this is the right time to implement the solution. Maybe you need to pause because you can't make those changes or dedicate those resources.Or, you might need to ask for more budget for additional help or set expectations internally that a resource you thought would be on another project needs to be dedicated to this project.Being clear on internal and external success criteria is really important.

Lastly, I would suggest always asking for references.Most of the time, customers will ask for product references, and the customer will get on and talk about why they love the product.However, not as many customers ask for implementation references and say, "Hey, what went well in the implementation ? What should we do?" Ask them the same questions I recommend you ask the service provider: "What do we need to do to ensure we are successful?" These references are really important, and your service provider should be able to provide them, or I would be wary of going with them.

Brent Trimble: Before we get into some evaluation criteria, you brought up a really good point, and I think it's important to emphasize this notion that client, brand, company, platform, you have made a platform selection. Let's jump ahead to the selected implementation. The responsibility for the successful implementation ultimately resides with them, whether that's the internal team or an SI partner. It's really important to note that sometimes clients' expectations are that a great implementation means someone takes some requirements, goes away, configures the platform, and then just hands it over.

Kurt Kilgore: Yeah, absolutely.There are probably some software solutions that are simpler where they can't do that. Others require a significant amount of business process change and engagement from the customer. The customer needs to decide what they are doing now, what they want to do moving forward, and what they are willing to do. Testing the solution is hard. It's really hard because customers have day jobs.They need to keep their business running, and they're being pulled away from that to help implement this new solution.

In many cases, they think or hope that the vendor or service provider will make these decisions or do this work for them, but that's not the case. This is where many projects get derailed. The customer does not have the bandwidth to do all the things needed to make the project successful. On one hand, they feel the urgency to move off the old platform and get the advantages of the new solution. At the same time, they are stretched thin and don't have the resources to dedicate to make the new project successful.It's a catch-22, and it's really hard.

Generally, when projects fail, it usually comes down to that. It's tricky because the customer might say, "Hey, we hired you because you're the experts." Yes, we are experts, but we're not experts in your business. You are the experts in your business, and you need to be able to do that as well.

That’s not to say that there are never failures or challenges on the service provider's side; that happens too. But most customers, when purchasing a new solution, are less likely to think about the risks from their side that could potentially derail the project. They focus more on the risks on the service provider's side.You really need to be focused on both.

Brent Trimble: That's great insight. So we've arrived at a selection and we've gone through criteria, the RFP, demonstrations, workshops, and we've selected a software platform tool that's going to help transform the business. There's excitement, there's enthusiasm, and the next step is, okay, let's evaluate or hopefully it was part of the, as you noted earlier, selection process. We're going in wed to an implementation methodology partner and approach. What are some of your tried and true tips and criteria for evaluating a vendor for implementation?

Kurt Kilgore: Yeah, I think we've probably covered a lot of this already, but let me touch on one more thing we haven't discussed much: the price.Most software evaluations I've been part of on the vendor side often come down to cost. The customer comes in with a budget for the solution, and the vendor has positioned something that exceeds that budget. So, now you're trying to figure out how to make this work.The vendor might have to lower their price a bit, and the customer may have to go back for more budget.There's always this pressure and constraint around cost.

When it comes to services, there may be a desire to shop around for the cheapest possible option.Certainly, you should look around and understand your different options.Just make sure you don't select purely based on price. This is probably a lesson you've learned outside of buying services, but sometimes you get what you pay for.Be careful and ask a lot of questions like, "How did you get to this price?" If the price is 40 % less than another quote you received, ask them to walk you through their thinking.They could be achieving that in many different ways.

One way is by delivering apples - to - apples scope with what your option A was.They might be significantly cheaper because they cut out a significant piece of scope that you wanted included, due to a lack of clarity about what should be included and what shouldn't. Maybe they said, "We can do that in a subsequent phase; we didn't include this in the quote." They could be using a different resource structure, like more junior resources or offshore resources. For you, that may be fine, but you should understand that to ensure you're comparing apples to apples.

They might have a different rate structure because of the way their company organization is structured.Sometimes, a small consultancy has very low overhead because they might have one manager and a bunch of consultants with no layers in between.They're not investing in their customers outside of the implementation work they do, leading to high utilization rates and lower charges. There are many different ways to get to a cost.

As a customer, you need to make sure you understand it.If you have three different bids, understand how they got to the price they came to and evaluate which one is right for you.You may end up going with the cheapest one, and maybe that's fine. Also, make sure you check references for all of them and make a decision based on what's most important to you.If you're optimizing on price, you may go with the least expensive. If you're optimizing on risk, you may go with one that's more expensive. There's no right answer necessarily, just be informed.

Brent Trimble: That's great insight. That's excellent. Going into it with eyes wide open and understanding how each vendor constructed and the assumptions they made, and diving into the fine print. You brought up great points about team dimensions, cost, geography, offshore versus onshore, all those things. Ultimately, making sure that they are all apples-to-apples comparisons because one vendor might be leaving off a critical component or part of the implementation that you assumed they included but haven't. That's really good. That's a great checklist.

As we get to the conclusion of this episode, part of our buyer's guide sequence and series, if you had to crystallize your professional experience, which is very rich, as you joked at the top of the hour, you’re a professional services lifer and you've got that experience on both the management consultancy side and the platform side.What are your go - to, top five critical things to consider when it comes to implementation ? Maybe restating something we covered with a bit more emphasis or something we haven't covered in the conversation to date in the actual implementation to orient to success?

Kurt Kilgore: Sure.I think I'll cover a few, like you said, that we've touched on previously and a couple of new ones as well.From my perspective, the first one to focus on, and we did talk about this a little bit earlier, is making sure that you understand and are clear on the business outcomes or results you want to achieve.

Why are you buying this solution ? It's an investment of time and resources that could be spent elsewhere. You want to get a return on that investment, so be very clear about the business outcomes you're looking to achieve and how you will measure them.This shouldn't be just in the sales cycle. Many vendors will provide an ROI calculator as part of the sales cycle, saying that if you implement this solution, you will achieve improvements in specific areas. This is how we measure it, we've made some assumptions, and therefore your ROI payback period is 18 months or something like that.Customers sign the contract, discard that, embark on implementation, start using the software.If your CFO asks a year later, "Did we achieve ROI on this in 18 months?" you will all be looking at each other with no idea.

One of the things we do at Kantata is we have something called our customer results strategy.We take that ROI calculator upfront and the reasons that you want to implement the solution.We focus throughout the implementation on those items.We make sure that you're able to measure those key results. You have a way to measure them. Then we meet with you every quarter in a QBR to assess how you are tracking against those key results. Are you improving or declining? What's going on ? If it's tied to our solution, we figure out how we can better configure or enhance the solution to help you meet those business objectives or key results.

Taking that mindset, you can apply it to anything you implement.There's a reason you are implementing it that's going to impact your bottom line.I encourage you to keep that focus from beginning to end because that's what's going to drive true value out of your investments.

Brent Trimble: That's outstanding. You touched on an interesting topic, which might be for a subsequent episode: Are we suffering from ROI calculator fatigue? That might be interesting to explore. The notion of pulling that through to the business outcomes, referring to those, referencing them, and ensuring the client realizes those gains in quarterly meetings is really key.

We talked about how you're the author of your own success with implementation. Are there any other tips that we haven't touched on ?

Kurt Kilgore: Yeah, I've got a few more I'm happy to share.That was just the first one.The second one would be always to start with an MVP or, as our product team calls it, the MLP, the most loved product.But start small, implement small, because just like time kills all sales, time kills all implementations as well.

What you don't want is to have this thing stretched out to the point where your sponsor either leaves your company or the organization and now you have a new sponsor coming in who's saying, "What is this and why are you implementing it?" If that does happen, go back to point one, which is then you pull out and say, "This is our results strategy. This is why we're implementing it. This is the progress we've had."

So that helps you in that scenario.But really, start small.It's going to reduce your implementation costs and speed your time to value. Once you're up and running, most of the battle is won there.Once you get live, there'll be things people don't like, and then you can add to that.But once they're up and running and you can retire an old system, it's a huge milestone.You can then focus on adoption and driving incremental improvements.

But a lot of customers make the mistake of thinking they need to replace every single thing in their old system with the new system, which is not a good idea.You're implementing a new system for a reason. Two, it just may take forever. It might take you two or three times as long as it should, because you're focused on recreating the past instead of working with the new solution and then building onto it.That's my second recommendation.

The third one is around executive sponsorship.This goes back to the concept of being ultimately responsible for the success of your implementation.Those things go hand in hand.Ultimately, the person who approved the purchase of this solution should be engaged throughout the implementation and beyond.

What happens a lot of times is that person gets involved because it’s a big expenditure.They get involved during the sales process briefly.They get briefed on the new product and why it’s being implemented.They look at the ROI calculator, agree with the ROI, and give a handshake to approve it.Then they disappear, handing it off to the delivery or IT team to build it.The expectation is that everything will be fine from that point forward, and they’ll have a new system to use.The only time they get pulled back in is when there’s a problem.

If that’s how it goes down, there will be a lot of problems, and they won’t have any context for them.The way to be successful is to ensure that the executive sponsor is engaged throughout the implementation.They need to be informed throughout.

There should be steer co meetings where the executive is engaged with their counterpart from the product vendor or the services provider.They should stay engaged and know what’s going on.The vendor or service provider should be able to tell the executive sponsor if they’re struggling because they need something from the team that isn’t being provided.The executive sponsor should then move the barriers that are impeding the project.

It goes the other way around too.If there’s an issue that the customer has that isn’t getting resolved, the executive sponsor should reach out to their counterparts with the product team or the services provider and say, “Hey, you’re not meeting expectations.We need you to fix this quickly.” Having that level of executive sponsorship is critical to the success of any implementation.

Brent Trimble: You know, that's a critical piece and probably one that is maybe undervalued and not thought through enough when clients are embarking on this because executives or sponsors are pulled in different directions and think, hey, maybe our role is completed once we've weighed in on the selection and validated and sponsored the selection, and now it's time to step away. But your notion is to stay engaged, make those decisions, and own it. It's a critical part of the success. That's a great point. But yeah, if you've got another as you think through this checklist of great criteria points and things to consider.

Kurt Kilgore: Yeah.The last one I would mention is just don't forget to invest in change management. So as the buyer of the technology and the solution, you fundamentally understand why it's needed and all the great things it's going to provide for you, but remember that the rest of your team may not understand that or agree with it.

Change is hard for everyone.Even if you have a suboptimal solution in place, a lot of people on your team may prefer to stick with that suboptimal solution rather than changing, because changing is hard.It's going to require training. It's going to require new processes.It's going to require you to do things in different ways and different things. So it's really important throughout the process to make sure that your team understands why we are making this change and to invest in the training so that they feel empowered to use the solution once you go live.

Make sure you're getting your subject matter experts involved in providing requirements, reviewing the design, and participating in the testing so they feel bought in. Understand who on your team are going to be promoters versus detractors and really identify those promoters and engage them to be your point of contact for the rest of the organization to help drive excitement about this new solution.

It's really important to focus on the people side of any technology implementation you're doing.You can implement the greatest solution in the world, but if no one's going to use it, then it's a failure and you've wasted a lot of time and money. Don't skimp on the change management.Some vendors will provide a level of change management themselves.There are tons of service providers out there who either provide just change management because they are experts in that, or it's part of the arsenal of services that they provide. Some customers, if they're large enough, may have a change management organization internally.

Any of those will work.Just choose one.Don't neglect it altogether because it's a really important piece of being successful.

Brent Trimble: It's outstanding. And thanks for that recap. Just to tick these off: clarity on business results and outcomes, always starting with an MVP, the importance of executive sponsorship and engagement throughout the process being critical to success, being the author and owner ultimately of your own successful implementation, and not to forego or forget investing in change management. So those are really great key points.

Kurt, this has been great.Thank you for those closing thoughts around those five key elements for considering and really owning in the journey of implementation.For listeners, this is one of an episodic series of our podcast where we're going to go through and complete a buyer's journey as users embark on software evaluation criteria and ultimately selection.This is a critical part focusing on implementation.

And for everybody, thanks for listening.If you have any follow - up questions for myself or Kurt, we love to hear from you.Send us an email at podcast @kantata.com.We'd be happy to get back to you. Kurt, again, thanks so much for the practical wisdom here, as well as some great strategic inputs on the software implementation process. We appreciate having you.

Kurt Kilgore: Yeah.It's great to be here. Thanks very much, Brent.

Brent Trimble: If you enjoyed this podcast, let us know by giving the show a five-star review on your favorite podcast platform and leaving a comment. If you haven't already subscribed to the show, you could do so anywhere you get podcasts on any podcast app. To learn more about the power of Kantata’s purpose-built technology, go to kantata.com. Thanks again for listening.