Episode 18: Spooky Tales from Services Delivery

Introductions

00:07
Hello, everyone. Welcome to the Services Ops podcast, the best podcast digging deep into the people, process, and technologies of running a really great services business. Today, we’ve got this spooky episode, this scary episode. If you’re anything like me, you have your kid’s Halloween candy on your desk right next to you while you’re going to listen to some of the scariest stories that can happen to a services professional. And we’ve got the absolute perfect guest joining us, Anish Udayakumar. Anish, how are you? Hey, Chris. Thanks for having me. I’m doing great, you know, and thank you for, you know, having me in the special Halloween episode. Of course. My skin is crawling already. I’ve got goosebumps. Because, you know, I think you in particular.

00:56
First, let’s introduce where you’re coming from. You’re head of customer experience at Provus, but not just head of customer experience at Provus. You had a long career of services delivery and projects at companies like Cisco Systems, Apttus, Hitachi, VMware. So you’ve been through it all, right? You’ve got the war stories. You’ve got the scary stories. And so I think you’re absolutely the perfect person to tell us some scary stories today. Yeah, you know, that’s right, Chris. Right now, I’ve been around the block for quite a few years now. So throughout my career, I’ve been trying to help customers get successful in what they do. In companies like Cisco, VMware, Hitachi, Apttus, I’ve dealt with a lot of internal customers as well as external customers.

01:48
Primarily, my focus has been in the quote-to-cash space. So, you know, a lot of battle scars too, you know, prove, you know, my longevity in this space. I’m happy to contribute and help out. This is great. This is great. And before we get started, I just want to touch really quickly on customer experience, right? And that is paramount, tantamount above all, right? There are things like timelines we care about. There are phases. But really what’s at the end of the day, the measurement of success is the customer experience, the customer satisfaction. And I think, you know, especially your career and what’s happening right now, I think it’s going to be a lot better than it is right now. And in the solutions economy, the services economy, personalization is expected from every customer engagement.

02:35
And with personalization comes massive amounts of complexity. And with massive amounts of complexity comes nearly an infinite amount of risk while you’re delivering on these projects, right? An infinite amount of variables that can go wrong from start to finish. And so someone like yourself, I mean, you’ve got to be on your toes, right? So, you know, funny that you talk about risks and like, you know, the very kinder risks which different customers face, right? So just like when you’re going trick-or-treating, right? You know, what scares a seven-year-old is not what’s going to scare a 15-year-old, right? So I think you can use the same analogy to customers who are trying to implement or do enterprise transformations.

03:23
When you have a smaller customer, or the things which matter to them are different, you know, when you engage with the bigger customer, the things which matter to them are different, right? But the outcomes are the same. Everybody wants to transform their business, you know, increase their revenue, reduce error rates, things like that, because that is common. So when you go into an implementation, you have to be very clear about the context, right? As to kind of what you’re setting out to do and look at the different scary aspects of the implementation in the context of who’s you are implementing software for, so. That’s great. Great advice right off the bat. All right, let’s do it. We’re all ready to be scared, Anish.

Starting Implementation Before the Customer is Truly Ready

04:06
So we talked a little bit ahead of time, and you’re going to take us through some real-life spooky stories. So we’re ready. Absolutely. So from an overall implementation standpoint, right, you know, what is an implementation or why are we doing this, right? So in a sense, we’re going to be talking about how the executive team of a company sets out to have a specific set of business goals. You know, I want to do these three things for my company in the coming years, right? And that is when they decide, okay, let me pick a platform or let me change my process. And that’s how it all starts, right? So some executive in the company sets out the big business goal. So when you start the implementation, we always talk about people, process, and technology.

04:55
And there’s a reason why technology is the last, because many times folks neglect or do not give due importance to people and process at the upfront of this enterprise transformation, which we are setting out to do, right? So what ends up happening is personal scary stories, right? When you go into an implementation, the customer is not prepared, right? So what do you do? So when you go in, you start the implementation. You discuss things with your customer. What do you want? Ask this process to be processed, design. Things don’t move along because they’re not ready, right? So they’re not ready at a point where their processes are aligned. Scope keeps on changing, right? So we say that, okay, let us set out with this and start.

05:42
But then in a couple of weeks, some changes happen. Hey, this process is not defined. Let us redo it. So then there is an impact. And it is always challenging in such situations to get overall business aligned. Because enterprise transformation is never for one persona. It impacts the overall company, different personas. So having to have that alignment is important. And then with all these factors coming in, in the second steering committee meeting, we feel that a panic is setting up, right? Oh, you know, we are not where we thought we would be. And, you know, people start to kind of trend from yellow to red. You know, that’s not what we want. So important thing to understand here. Is that, you know, even though this is a typical fear, which we see, everything has a solution, right?

06:31
So I would say the magic potion for this specific scary problem would be that once the exec team has set out the business goals for the project, for the specific transformation, there has to be due importance given to translating these business goals into strategies, right? And then they have to be tracked down into specific outcomes. And deliverables for each team. So that would mean focusing on people and the process. So do we need to get alignment on the business process even before we start or touch technology? Answer is yes. Do we need to invest time to do that as part of the implementation? Answer is yes. You know, it will not happen all at the same time. It is a sequential process. Then there are operational aspects which you need to consider, right?

07:22
So, for example, there are three different teams doing a specific job with the advent of whatever change which we are trying to get to. Would these three teams still be doing the same thing? Is there a skew rationalization which is required? All these thought processes have to kind of really start in parallel. And finally, we just need to make sure that all personas are mapped, their outcomes are defined, and also the things which they do for each of their roles is kind of clearly defined before we start. So those would be some of the tricks and tips which we could, you know, take in just to ensure that this scary, you know, monster doesn’t attack us, right? You know, that’s what I would say. Yeah.

08:06
And it sounds like, so, you know, thinking about this implementation, I’m sure this happened to you a bunch of times before, but from the delivery side, right? You’re coming in the first steering committee meeting and they said, you’re going to transform their process. We’ve got a deal done. Now get it done initially. When does the hair in the back of your neck start to stand up when you’re, like, wait a minute, this business, our customer is just not, not in a place right now to even start thinking about technology, not starting to think about, and you thought about this process, what it really means for the organization. Like the hair starts standing up the back of your neck and you start saying, oh, because the scary thing is not that they’ re not ready.

08:50
There’s going to be impacts that ripple through your team, through your organization, through your revenue, through your marketing. All this stuff is going to happen. So what, what are those moments where you’re like, I think there’s something wrong here. And then what could have happened beforehand? So you don’t have to deal with the fallout because not everybody’s got as cool ahead as you, Anish, right? Like the first meeting and they’re like, this is a disaster. They’re going to start running and hiding behind the barn in the back. Right. So when, when, when do you first know? So a good way to assess that is right. You know, whenever anybody talks about a service implementation, the first thing which comes to their mind is when do we go live?

09:29
Right. That’s the first question which comes to your mind. So when an implementation starts, right? So we have a tentative idea of what we are trying to accomplish, right? And we scope the project based on that tentative understanding. We do detailed discovery with the customer, understand what they really need and put the project plan together. So one of the indicators would be that without really, going a little bit more deeper into analyzing, ‘hey, you know, what are the real life experiences which the end users have? What is the real kind of business transformation, which is really required? Is there a process and business operations changes which are required for this particular project?’ Timeline is analogous to the amount of effort, which is really required.

10:19
So it is easy to measure the technological effort. You know, how much time does it take to write code or how much time does it take to really configure a product? That is simpler and linear, which we can really establish and understand. But then the latter part or the former part of, you know, business process, it takes time. Right. And then if there is a tremendous focus on the go-live date without focus on, you know, do, are we investing time? That would be a red flag in my mind. Right. So, yeah. All right. When do we go live without thinking or acknowledging that there’s a business transformation happening here? Yeah. Spooky. All right. You see the theme where we’re really embracing the theme of spooky stories today. So let’s move on to another one.

Getting to UAT without including the end-user

11:09
You know, we talked once again before this and you gave an example of what can happen if you’re not checking in with the right people during an implementation. So I’ll let you kind of tell us that story that you mentioned. So this is a very, very common theme, right. Which happens across the board. Right. So the first one we discussed may not be as applicable to very small companies or mid-segment companies, you know, that is probably applicable to big customers. This problem or this scary notion is applicable to everybody. Right. So that’s why it makes it really scary. Right. So this, I’m going to call out that if you don’t have the end users, the actual users of the application, part of the core team on the implementation side, it can result in really, really scary outcomes.

12:04
Right. So as a project team member, or as an executive driving the project, this is something which can result in really disastrous outcomes, right. For us. So simple things to kind of start with. If the end user has never seen the application, right. And then they’re first seeing the application during UAT or, during the course of training, that is not a good sign. Right. So that is definitely not a good sign. Right. We are actually building this application for the end users to use. Definitely we will incorporate guidelines and functional rules, which the operational team and the executive team needs to implement, you know, governance, et cetera, but then it is the actual end user’s choice to use.

12:51
So this is like you buying a, you know, very, very safe car for your teenager. Right. So if the teenager doesn’t like your car, you know, they’ll be grumpy, you know, in the case of a teenager, they don’t have a choice, they will drive it, but that’s probably not going to be the case for an actual end user. Right. So they will probably not use a system. It will inhibit adoption, et cetera. Right. So the point here is that it is so paramount to ensure that the end users were actually using the system or would use the system are part and parcel of the core implementation team, right. So you need to have those working sessions with them. They need to feel empowered to give their feedback.

13:34
You know, we need to ensure that their feedback is solicited using, let’s say a conference room pilot in the design sessions, you know, what is the approach which you have? And one of the other themes, which we see very, very frequently is that the core team, like the IT team or the leadership team, will prioritize the end user’s choice and say this is very important for our company. And this is something which is really important. But then as much as that is important, they fail to run that through the lens of the actual end user. Right. So what happens is things which are really important to the end user gets neglected. That might be simple things. You know, I want this button to be here or I want this report to show up; that gets lost.

14:19
And that is a huge inhibitor in them adopting the system. Right. And finally, what happens when they go live? There’s an impact on them adopting the system. There’s a lot of experience feedback which increases scope after the fact. Right. So which is a very, very scary moment. Right. Or during UAT, they say, ‘ you know, I don’t like it. This is not what I signed up for.’ Let us redo it. Right. So not a place where we want to be. Yeah. Yeah. I can just imagine. I mean, the life cycle of getting to UAT. Right. There had to be executive alignment between your operations, your sales leaders and your future customers. And there were negotiations and there was scoping. And boom, all of a sudden, a deal is done.

15:05
And then you’re kicking off your implementation with your steering committees, probably some business process and changes. Everybody’s changing processes and doing lots of hard, hard work all the way across the board. And then you get to UAT and imagine everybody sits down with the end user. And the first thing they say is, ‘OK, so what’s this do?’ Right. Imagine lightning striking right there. That’s going to be a terrifying moment because exactly like you said, you know what’s going to happen next. You’re going to have an unpredictable response from the actual end users on if they think it’s going to be valuable or not. There’s going to probably be additional customizations on the back end based on the feedback you’re going to get that wasn’t scoped.

15:50
And then adoption just might not be there. And all of a sudden, one year later, you know, if adoption is not there and there’s not customer satisfaction and churn happens. And that’s the scariest thing of all. Right. You did all that work and your organization did all that work just to end up in the wrong place. Not that you couldn’t be in the right place. You just didn’t include the right users at the right time. Exactly. It’s terrifying. I think it’s everybody’s worst nightmare. It’s not just your worst nightmare. Right. It’s the C-levels.

16:19
It’s everybody’s because churn is the worst. Churn is a killer. And without good customer satisfaction, you’re going to see that all the time. All right. Anish, I’m adequately scared and I’m scared to open up this, the next door, but like any good horror movie, we’re going to open up anyway, even though it’s a bad idea because we like getting scared a little bit.

Not having the right people during implementation, skill imbalance and resource scrambling

16:40
So let’s go into our last true life ‘I know spooky services situations’ from Anish here. And let’s go into our last little little story. Yep. So, the last story for today would be like having the wrong people in the team or not having the right people and those are two different things you know. I will say not having the right people in the team right.

17:06
So typically in a project, you would want a strong executive sponsorship, right, you know a set of people or folks who are determined to kind of get this right and get this done. That’s one. Then we need business process champions right the next level of folks who are track leads or cross-functional leads who you know drive change in their own respective areas. Then we talked about end users and the key highlight representatives from there. And then also the IT team, the team who is going to be responsible for managing the application post go live. Right? So these are the four key members in the team right. In essence, there has to be very, very strong representation from all the different teams so even if you miss one there is going to be disastrous outcomes right?

18:02
So in general, I’ll just take a few examples, right? So, in a big company where there are a lot of key functional areas which are going to be impacted by quote-to-cash transformation, like whatever we are trying to do. It is important to have these representatives in the meetings, right? Which is important and there are cases where some cross-functions might not be as inclined to change as some of the others, right? So that executive sponsorship is very, very key in driving successful outcomes, right? So when we come in as a product partner or an SI partner trying to influence and make change in the organization, we absolutely need that strong force. Internal to the company, who is driving that change, so that is our exec sponsorship which is very key to project success.

18:54
Next, we talked about the business process champions, right? So, the first scary point was related to ‘Hey, are we really doing that?’ So, who is doing that? These are the people who are doing that, right? For the working sessions for the design sessions to be really meaningful for getting design alignment across the board, we need business process champions and end-users to be there, you know, as part and parcel of our project team, right. We want to make sure that in every implementation we strive to ensure that the application team or the IT team of the customer is fully enabled to manage and maintain the application and be completely self sufficient right what do we need for that we just having an IT team is not enough right having the right kind of people having the right kind of training right is really crucial to ensure that those team members are able to be involved in the process right.

19:52
So, the IT team members are fully equipped to kind of do the first level and second level of support, and they reach out to us for managed services or support when it is a third level of support which is going to require right so that trained set of resources in the IT and applications team is really key to success. So from a viewpoint we don’t want our customers to be heavily dependent on managed services, any small change we don’t want them to reach out to us; we want them to be self-enabled, see. As an ethos of our company, we make sure that our product and platform is declarative, any end-user can really manage and maintain, but then you still need to be trained, you still need to have that sense of ownership at the end of the implementation to kind of be able to drive that.

20:37
So that is going to be the last part so just you know reiterating, right? The executive sponsorship key member of the organization who is going to drive the change business process champions required for. Ensure alignment and defining what the business process is, the actual end users who are going to be using the application, and then finally the IT and tech support team. So in a successful implementation you will really see signs of all these four teams working in parallel with great collaboration and that is when you see great outcomes. Yeah I think those are all really good representatives that need to be in a successful implementation. Let me ask you this question. And if you ever, I am sure you have experienced this in the past before.

21:25
You are going through an implementation and you quickly realize that for this particular implementation the skills on your team that you have assigned to it the resources the people that are going to be doing the work on your side are the wrong people and you actually meant to pull from this team or you need this team because this scenario is too unique. So you got you got a skill imbalance and now you got to start shuffling people around different projects and implementations how does that you know has that ever happened to you and how do you deal with it because that sounds terrifying right because that’s, you know, a scary outcome is your resource forecasting is all of a sudden just out the window. See, being in this industry for this long, every possible scenario of that has happened, right?

22:13
I would not be telling you the truth. If I’m saying that all implementations never happen, absolutely right. So the key thing is that every time something like that happens, you learn, and then you better prepare yourself for your next implementation, right? So in a case similar to what we have been doing in Provus, right, learning from a lot of core experience in this area, what we do is we make it as prescriptive as possible, right. So when we start the engagement with the customer, we try to be as clear and you know obvious in terms of what is that which is really required. How do you prepare yourself to start the project, right? So we have the prime implementation methodology which kind of really details out here is the process which we need to follow, you know two weeks three weeks before kickoff.

23:07
Here are the things you need to kind of think about, right. Here are the key resources which are really required and then internal for us as well, right. Going in an implementation we really look into hey what is this vertical which the customer is looking at. Hey do we need some expertise in there you know do we have the right kind of resources to get engaged. So that planning also has to kind of happen and no matter how much you plan no matter how much there is going to be a spider is going to jump out right. So the thing is I always say luck always favors the prepared right. So you need to be prepared, prepared, prepared and then you will get lucky. Yeah. Yeah.

Advice to Avoid Scary Situations

23:43
I think that’s very true, preparing for the worst and sometimes is a positive thing, just don’t let it consume you. All right so we’ve got three scary stories we talked about starting implementation before the customer is truly ready and has their expectations set. Getting to UAT without including the end user is terrifying, and then not having the right people – whether it be your customers as part of the process or a group of customers that need to be part of the implementation, or not having the right skill sets for a particular project. What’s one or two pieces of advice I would give to just avoid these scary situations in general? How can you make it so these are as diminished as possible? So, like, understand that change is hard, right.

24:40
First of all, acknowledgement. That whatever we are setting out to do is not a small task, right. Giving it that due importance, right. That will help allocate resources and time to whatever we are setting out to do, right. And then also listen to the feedback and advice which is provided, right, because a lot of experience goes into play when we suggest hey this is probably the best recommended practice, right. So that also applies to implementation, right. And then the last thing I would say is that go with an open mind, right. So be ready for change and be ready for things not working out as they should, but we are going to figure it out and make it happen, right. So yeah. Yeah.

25:24
And I would even add that you know we were talking about people who are in charge of customer success implementations, executing the projects. You don’t have to be a bystander right. When these expectations are getting set in the sales motion and you know your sales team are having conversations with your customers or your future customers about projects. You don’t have to sit and wait to be handed whatever is going to be given to you right. Let’s call the big theme to all these stories is having projects thrown over a fence. I mean there, there you go. There’s a big scary thing. There’s just a big fence. It’s black. It’s black and you can’t see you in front of it, then projects come flying over it.

26:12
That’s how you get into these tricky situations. So don’t be a bystander and work your way into collaboration with the folks that are helping scope these things and put them together. You know how about one piece of advice Anish on how folks who are in charge of success or implementations can insert themselves into that free sales process in more meaningful ways. So I would say that you know when you are picking up an application or a platform right, you know during the sales cycle or evaluation cycle make sure that your voice is heard right. Never should be a point where, in a cross-functional kind of world, the decision of buying should be just one-sided right.

26:58
So definitely, it can be initiated by a single site but then all your end users are going to be in different tracks of the organization. So even if you’re in the finance side or you know the sales side or the revenue side make sure that your voice is heard right. Make sure that you are kind of giving your input and putting your priorities in front as part of the RFP which goes out right. So make sure that your voice is heard. That’s what I would say. I like it. I like it. All right. Anish, this has been great. I am adequately scared. Ready to head into Halloween with a little bit of fun. With goosebumps and to be the life of the party with these scary stories. So thank you for joining us and sharing your experience. And thank you to the audience. As always, thank you for watching and listening. Don’t forget to like and subscribe and follow us for more information. If you want to follow Anish on LinkedIn, look up his profile; it’s a great follow with lots of really great experiences, and go out and be brave. Don’t be too scared of these spooky stories. You can still be a brave services leader. All right. Thank you. Thank you. Thank you.