Day 2 Operating Model: What Happens After Go-Live (And Why Transformations Fail)

WEBVTT
1
00:00:02.000 --> 00:00:07.000
1, 2, 3, 4. Pretty good. Good afternoon. How are you doing?
2
00:00:07.000 --> 00:00:09.000
I'm okay. How are you?
3
00:00:09.000 --> 00:00:15.000
Good. I can't believe October and the year is, like, almost over.
4
00:00:15.000 --> 00:00:32.000
It's a little stunning. The Burrs are off to their usual burnous in my world. And I keep thinking we're just getting started, folks. We're getting started. So we still have time to go. Yeah, the. The Burr movement. So it is busy. It's busy, but it's an exciting time.
5
00:00:32.000 --> 00:00:45.000
But these last couple of months just seem to go by so fast because, you know, you get all the vacations and all the craziness ensues with holidays, and then, of course, January starts with sales kickoffs and all that crazy stuff. So.
6
00:00:45.000 --> 00:01:08.000
Yep. And we are now full on into budget season for a lot of our clients. Planning for what does the next wave look like? And so you see, see in the horizon where this is going, and, you know, you hope that the fresh energy and maybe some fresh funds come with, okay, let's get on to the work to be done and find a more efficient way, all those sorts of things to deliver.
7
00:01:08.000 --> 00:01:21.000
Yeah. Yeah, it's. It's interesting because I feel like every time you say budget season, I feel like budget season is just now a constant discussion versus. I know there's a big event that
8
00:01:21.000 --> 00:01:57.000
happens around it oftentimes, but it's interesting that you say that, because I think that one of the things that I see is budget season is constant, but change is also constant. And it feels like that change is something that is coming on heavier and thicker than it has in the past. And I suspect some of it is because of AI that everybody is in the middle of some of these transformations, whether it is a formal transformation or whether it is a personal transformation, but businesses, it feels like changes. The only thing that we can count on, and we know that from the adage, but, man, it's heavy right now.
9
00:01:57.000 --> 00:02:45.000
Yeah, I. I was talking to somebody the other day about just, you know, large programs in general, and, you know, how they're just so hard to sometimes manage, and AI has kind of added that layer of complexity because there are so many people doing so much with AI and I don't know that all the companies have a handle on it and, and what's happening. And so it'll be interesting because the converse. Some of the conversations we have planned over the next couple of. Of months, we'll. We'll. We'll talk about that with. With some experts. So I'm excited for our listeners to hear more about those topics. And, and dive into it. But today we want to talk about day two, which sounds ominous.
10
00:02:45.000 --> 00:02:50.000
Day two. Day two, the day that nobody plans for.
11
00:02:50.000 --> 00:02:51.000
Right.
12
00:02:50.000 --> 00:02:52.000
So what is day two, Rich?
13
00:02:52.000 --> 00:04:02.000
So we at SaaS Business Advisors define day two as the day after go live. When. So when we plan these massive programs, everybody seems fixated. When we talk about budget, when we talk about assembling the team, when we talk about what it means for the business, we focus on go live. Everybody puts that date on. We say that's the date where we're working towards. What people don't think about is often what happens after go live. So go live, you know, June 1st. What happens June 2nd. So for us, that's day two. Day two is how do we plan for operationalizing the business for this change? And for some people, they'll focus. Well, that's just change management. Right? That's your change management work stream. It isn't. It goes beyond that in our mind. And that's kind of the topic we wanted to talk about today, is helping people think about how to plan to operationalize these big programs beyond change management. Because one, as we talked about a little bit earlier, people don't even invest in change management. I think you can universally talk about
14
00:04:02.000 --> 00:04:08.000
always one of the first things that either gets deprioritized or taken out altogether.
15
00:04:08.000 --> 00:04:29.000
Right. It's just. It's not. I don't think that it's not valued. I think it's not tangible. Yes, right. Like, like, it's not. It's not the software I can touch. Right, right. And it's a little similar to how people feel about strategy. Right. Strategy is a deck and it's a set of words and it's a set of concepts. But I don't really feel it.
16
00:04:29.000 --> 00:05:17.000
But it's that the ants go marching two by two, like that's what we need. And I think with day two, that's where the value was won or lost. Because now you've got, okay, we have drawn the line. Let's see. And this is our end date, and we may be a year from that. But day two is where the rubber meet meets the road. And now you have that value that you need to drive, that your business case is built on. And I think all of us, you know, we are aware of what is the business case, what are the metrics that I'm looking for? What do I need to do between now and then to turn whatever on, New process, new technology, whatever it is. But what does that day two look like? What's my receiving team look like? And what is the, what are the, what's the cadence that we're taking in order to, to really make sure that we are filling that, that value hole? Yeah.
17
00:05:17.000 --> 00:06:20.000
And I think for, for some companies, I think the challenge is, is twofold. One is you have a lot of these initiatives on your plate, and so they go live at various times. And so the change sometimes from a process perspective is, could be a little slower or could be stitched together through many releases. And I don't think when you do a lot of the design work upfront and, and, and you talk about the requirements that, that people ever say, oh, well, here's a technical process change or a technical change, here's a process change. And oh, that process change needs to go back into the business. And so you need to account for that in day two. Right. So I think there's, there's not a really good document that comes out of Solution Design that, that the business owns. Right. We all know that the technical team owns the technical document that comes out of it, but I don't think the business owners at times own that process change. And part of.
18
00:06:20.000 --> 00:06:34.000
Until it's too late and they're scrambling. And I think that's one of the biggest challenges is, oh, gosh, yeah, I know we needed to do this. I guess I just didn't fully recognize it until we got to do it. So when, when should that start?
19
00:06:34.000 --> 00:07:24.000
That should, that should start at the design sessions. So, like when I plan design sessions and we think about it, you know, we think about who's in the room, right? And inevitably you get, well, you want a whole week of people's time. That's too much. And da, da, da. So one, being thoughtful about who's in the room and how much time you're taking of them is critical. But I think the other part is, well, what do the sessions look like? Right. And so forth. Most people, I think they are focused on, well, you're giving me a new technology, so I want to focus on what the technology is going to do. And I think that's. That leads into the second problem most people have is, well, the technology isn't solving the problem. The technology is either making you more efficient or streamlining something, maybe removing stuff from the process.
20
00:07:24.000 --> 00:07:30.000
Exactly. Bringing data in, bringing. Informing your decisions, whatever it might be.
21
00:07:30.000 --> 00:07:48.000
And so I think what, what also needs to happen is this process mapping. Right? Because I think that the process mapping, I mean, I don't know, years ago, I feel like it was more prevalent maybe in the 90s because I'm aging myself. And I don't know if you guys ever heard of this company called Sapien. Have you ever heard of Sapien?
22
00:07:48.000 --> 00:07:50.000
Yes, yes. But it's been a minute.
23
00:07:50.000 --> 00:08:03.000
Amazing. And I remember when I worked at the bank, we all went to Sapien. We're all sitting in a room and we're talking and we're saying, this should be this. And they're all in the backgr typing, and then they come out with a process map and they're like, here's what you said.
24
00:08:03.000 --> 00:08:04.000
Right?
25
00:08:03.000 --> 00:08:08.000
And we're all like, that's not right. We shouldn't do that. We shouldn't do that because it was tangible.
26
00:08:08.000 --> 00:08:13.000
But that's the right conversation. That is exactly the right conversation. Yeah.
27
00:08:13.000 --> 00:10:17.000
Because once you realize that your process is inefficient, then you realize that your requirements for your technical solution are going to be inefficient too. And so I don't think people often connect that dot is that technology is the manifestation of a business process. Really all it is, period. At the end of the day, it really is about taking what I do today and putting it in a system. Now, some of it is streamlined, some of it is inherently easier, but sometimes it's inherently harder. And so without that first step, it's really hard. Because what happens during these design sessions is, oh, yeah, yeah, this is what we do. And then you go to design sign off, and they're like, well, but Tuesday, when it rains, I have to do this. And you're like, well, why didn't you say that? Oh, I forgot. I didn't think of that. But if you put a process map in front of people and you say, okay, guys, let's start. The customer comes to you and says, da, da, da. And I just had a client say to me, they're like, why do you always start with the client? You're always talking with the client. And I was like, because that's the beginning of the journey. I said, ev. I said, everything is client centric. I said, in the beginning of the journey is when the client engages you. You as an employee, whoever they engage has to do something. And if it's cx, they do it one way. If it's sales, they do it another way. If it's partner, they do it another way. And the goal isn't necessarily to, you know, make these all the same, but the goal should be to understand the variations and where you can align and where you don't, because that's where the technology is going to say, yeah, but now it's going to take you six more steps and I'm going to customize this and cost you six times more money right now. Like no, no, no, no. We don't want to cost more money, so just go the easy route. But had you had that process discussion up front and you said, well yeah, we realized that, you know, these six steps probably we don't need to do. And oh by the way, we've been doing them because sales didn't want to do them. So they got CX's pudding.
28
00:10:17.000 --> 00:10:18.000
Yeah.
29
00:10:17.000 --> 00:10:29.000
And or hey, we, we did it because we bought another company. Or hey, it's always been an Excel spreadsheet. So it's just always been limitation of
30
00:10:29.000 --> 00:10:32.000
how we do it. Yes, exactly, exactly.
31
00:10:32.000 --> 00:10:47.000
So, so I think that when, when people start this journey, it really starts at well, what are our outcomes, what are we trying to accomplish? And so going back to, you know, strategy and having this idea of what the end looks like.
32
00:10:47.000 --> 00:10:48.000
Yes.
33
00:10:47.000 --> 00:10:56.000
I don't think people ignore it. I don't want to say that I think it's there, but I think it's there in the context of the program, not in the context of the company.
34
00:10:56.000 --> 00:12:10.000
Exactly. And I think that's one of the things that I would almost say that I think the planning needs to start before that because I think that the, you know, if I think about some, you know, key projects, I have walked into a client site before where we are, you know, getting to the point where a system is almost configured. And so we've got the tech team working on that and now we're working with the business owners and, and I say who's going to run this? Like who owns the process? And I have seen like that panic in, you know, in leaders eyes. Like what do you mean? Like tech is going to, I'm like, no, no, no. Like who owns this and who owns the final decision? And so I know that look of panic of oh gosh, good question. So I like starting before then even to say just with the primary business and tech leads. Let's just pretend, magic wand that the next six months or the next 12 months, whatever the project timeline is, that's already happened. Let's just take an example of what's going to happen next. You guys, your process has changed. Like how do we envision that happening in the future? And how do, who's going to be the catcher in this new state of those, of those who's going to be the decision maker? How are we going to make that work?
35
00:12:10.000 --> 00:13:06.000
Yep. And you know, when we talk about measuring success. A lot of people think measuring success is go live. Like we said in the beginning of the conversation, I think measuring success is achieving the results that you have set out to achieve within your strategy. So it's reduced cost, it's increased revenue, it's whatever that metric is. A lot of those metrics are not discussed during the project. I always make a point to discuss them because at the, a lot of times it has to do with, well, that data isn't available. Right. And so when you talk about metrics, I always think this is an interesting kind of challenge is you talk about the metrics and you have people say, oh, well, we want to measure X, Y and Z. And you're okay, how do you measure it today? Well, we don't, we can't because we don't have the data. Okay, so how are we going to measure it in six months or nine months?
36
00:13:06.000 --> 00:13:07.000
Exactly.
37
00:13:07.000 --> 00:13:09.000
And we'll create the data.
38
00:13:09.000 --> 00:13:14.000
Okay, how? Right, right. No benchmark to start with for sure. Right.
39
00:13:14.000 --> 00:15:09.000
And, and how are you going to do that? And for me, the benchmark is so important. So if you're telling me you're going to raise revenue by 6%, then you better know what your baseline is today, because how am I going to know I achieved my goals and at what frequency am I going to achieve them? And to your point is, who owns that? Does the business own it? Does it own it? Is it a joint? Is it a new role that nobody's achieved? Are there metrics outside of our project that we need to consider? Do we need to align with them? Does this become operationally operationalized into a dashboard? Does it go into qbr, dac? Like, like some of these things are such afterthoughts. And so for us at least, what we talk about is you need to plan for it to your point, even before you start the project. But through the project, there should be a work stream that actually addresses operationalizing the this work stream in the context of the business, not in the context of it going live. Because it's, you know, in former clients, we've done, you know, CPQ projects, salesforce, service projects, whatever, you know, the different ones are. And there's always dependencies, but those dependencies necessarily aren't hard dependencies on your project. They're dependencies after your project goes live. And a lot of those stakeholders sometimes might be informed through the project, hey, this is going on, it's going to happen, it's going to happen. They don't pay attention. Right. It's, yeah, yeah, yeah, yeah, yeah, yeah. And then it goes live. And you're like, okay, so I now need to pull on this thread. And they're like, I didn't know you were going to pull on that thread. Yeah, I, I'm not prepared for you to pull on that thread. And you're like, okay, well, we've been telling you for six months this is happening. And they're like, yeah, but I didn't realize that what you meant you said was going to happen actually was going to happen.
40
00:15:09.000 --> 00:15:10.000
Right.
41
00:15:10.000 --> 00:16:20.000
Okay. I'm confused about how I couldn't have been any clearer about how I was going to do. And so the operational. It's easy for me to say operationalization, thank you. Of the business, I think, is such an afterthought. And I think day two is where your focus should be. I think the project team needs to focus on getting you today, but when you start handing it over to a client. So we look at this as the lens of consultants. Right. I don't look at lens of. I own this. So I was having this discussion today about, you know, org charts on, on programs, and I said, I'm here to guide, inform, provide knowledge and expertise and, and the muscle to get it done. I said, but I don't make decisions on your behalf. I give you all the, the information to make decisions and I'll give you options. But the decisions are how this thing gets run in perpetuity. And those, those belong to the client. And any consultant that doesn't allow the client to make those decisions is doing it wrong.
42
00:16:20.000 --> 00:16:21.000
Yeah, yeah, yeah.
43
00:16:21.000 --> 00:16:27.000
Well, because what's the client going to say when the, the wrong decision? Well, the consultant made that decision.
44
00:16:27.000 --> 00:16:37.000
Right, right. No, no, no, no. I mean, the consultant's going to own a lot. Walking out the door because that is part of our role. Blame for decisions is probably not one of them.
45
00:16:37.000 --> 00:16:38.000
Yep.
46
00:16:38.000 --> 00:17:09.000
That's okay. That's okay. Or not to your point. Not for, not for a good consultant. One of the things that you've mentioned in the past is how do we leverage uat? So practically speaking, like, you've got a bit of a dry run on, on some of, some of this. How do you use UAT as a, a kind of a, A view into the future? How do you effectively use UAT as a tool to start to test your operating plan?
47
00:17:09.000 --> 00:17:49.000
Yeah, I mean, I think again, kind of to your point, it starts before that and with Sprint reviews and starting to get people comfortable with what it is. And I think that's where, you know, we can't under downplay change management, I think that's where the messaging starts to come in. But during uat, I think it's really important, if possible to test not only the system and get the end users, but start testing those metrics, start looking at dashboards, start modeling data. And it's sometimes hard because you know, you don't, people don't really account for that. And then you have to have all these really crazy like future state data
48
00:17:49.000 --> 00:17:54.000
visions and it's the hair on fire that oh my gosh, now it's happening.
49
00:17:54.000 --> 00:18:18.000
Right. But, but I think during uat it's a really good opportunity that the, the use cases are not only positive, negative, but they're also process driven. Right. So the use cases are written in a way that say, okay, so you used to start here guys, now we're starting here. So remember, you don't have to do these six steps or you know, give them a journey, give them a story.
50
00:18:18.000 --> 00:18:20.000
Right, right, right.
51
00:18:20.000 --> 00:18:49.000
And so many use cases are, or UAT use cases are happy path. And you know, a CIO we know very well, she would say I want negative, I want happy path, I want path, I want like the company burned down tomorrow yesterday and what do we do? Like, you know, all these kind of scenarios. And so I think one is UAT is really important not only because you're introducing the product to the people end to end.
52
00:18:49.000 --> 00:18:50.000
Right.
53
00:18:50.000 --> 00:19:30.000
But you should also do things like bring the ops team in because the ops team sometimes isn't involved in, in all of it. Sometimes they are, sometimes they're not. Depends on the program. Pull your report. Pull your daily report. Does your daily report make sense? Does it work? A lot of times reporting and those things are thought of, but you don't again seed all the right data. You don't think about all the variables. So I think a proper UAT is thinking through all the variables and making sure you have them, but making sure that the team is not only signing off because that's ultimately what you want. We did a good job back sign off of course.
54
00:19:30.000 --> 00:19:31.000
Right.
55
00:19:30.000 --> 00:20:01.000
But I also think it's to your point is preparing you to go live and to operationalize it and to start thinking about those SOPs and those dashboards and those metrics you want to build. I've seen many programs go live without those things in place. And at times it could be because the application you're building has reporting, but really the reporting you need is in the warehouse. To marry, you need a power bi.
56
00:20:01.000 --> 00:20:05.000
Right. A qlik whatever it is. Right, right.
57
00:20:05.000 --> 00:20:13.000
And so in certain, you know, I would say good leaders and good consultants will call that out early on and that will be a workstream.
58
00:20:13.000 --> 00:20:14.000
Right.
59
00:20:14.000 --> 00:20:19.000
I think others tend to say, well, I can't do anything until the date is available.
60
00:20:19.000 --> 00:20:24.000
Right, right. So it's so from one fire to another. Right, right.
61
00:20:24.000 --> 00:21:21.000
So the day two problem becomes a day 60 problem. Yeah, right. And so we all know once it starts going into production, people just start doing their thing. And one of the things I always say is, well, what looks different before go live? So the day before go live. And what looks different to the day too. Because if the people are doing the same job in the same way they did on, you know, let's just say, you know, October 31st and then we go live November 1st, November 2nd, they're acting like October 31st, then we've done something wrong because fundamentally everybody's job should have kind of changed on that go live. But definitely the day after. And so if you're not waking up with new SOPs, new metrics, new goals, you know, and of course it's change management and adoption is happening through all this.
62
00:21:21.000 --> 00:21:22.000
Right.
63
00:21:22.000 --> 00:21:30.000
It is a bit chaotic, but, but, but the change is usually focused, focused on the end users, not on the entire organization.
64
00:21:30.000 --> 00:22:28.000
Right, right. Yeah. So let's talk about how do we take this into practice? Because I know you and I have talked about. Okay, frame the conversation upfront so that you've got a path and so that your key stakeholders understand that this is, is part of, of the process that needs to be accounted for. Now make sure your planning accommodates that for your, for your go live planning. But there are rhythms that the business may have to, particularly with the technology that they may have to adopt that they have not had in the past. So if it's a technology based transformation, now we've got a new partnership between the business and technology that might have been tightened up during this process or it may have come around for the first time. What are the top recommendations that you give to organizations in order to really put an operating model into place? What are the bare minimums that need to be covered?
65
00:22:28.000 --> 00:23:52.000
Well, I mean, I'm a process person, so I like process. So I think a good SOP standard operating procedure is a good place to start. Write down whatever it is. So the process document was the as is to be from that process document. What are the steps? What are the things we're measuring? Because I think often we measure like, let's just say you implement Salesforce in a CRM, so you're, you're you're measuring potentially the velocity of the sales stages, measuring the, you know, maybe it's the size of the deals you wanted bigger, right? But the size of the deals you want bigger is based on sales selling differently. It's not based on sales putting data into sales force. Let's be honest. Right. Like you fundamentally probably said, hey, we need a new sales process and we're buying Salesforce to support that process. Right. So we get the insight. So I think some of this is, you know, again, part of training and change management, but then part of it is I feel like rests at the feet of the leaders. Right. So how are you leading differently? How are you making sure that the conversation that's happening in step one is actually happening and putting something in a system isn't really monitoring those conversations. Now I know people say, hey, you have gong and you have, you know, AI now and, and people can listen to the conversation.
66
00:23:52.000 --> 00:23:54.000
Right.
67
00:23:54.000 --> 00:24:22.000
But I, but I still think it's a human driven process. Right. And so I think having that SOP and having that in writing and that SOP having a, a metric next to it that talks about behavior. Right. It doesn't, you know, there, there's, I don't want to say it's, it's, it's not tangible because I think it is tangible. But, but what are those kind of underlying metrics? So the leading lagging.
68
00:24:22.000 --> 00:24:23.000
Right, right, right.
69
00:24:23.000 --> 00:24:38.000
So what's leading? What's lagging? I don't, I still don't think people use that terminology. Well, I don't think they, they often do it. What are the leading indicators that tell me you're doing your job, that you understand that your behavior has changed.
70
00:24:38.000 --> 00:24:39.000
Right.
71
00:24:39.000 --> 00:24:42.000
So much of it is behavioral change. So much of it.
72
00:24:42.000 --> 00:24:48.000
Right. So is adoption a metric or is there something beyond that that is more action oriented?
73
00:24:48.000 --> 00:25:01.000
I think adoption is the laziest metric in the world. It's, it, it's, it's the right one for the first couple of weeks. But when you think about it, in the early days of Salesforce, we used to say, are people logging in?
74
00:25:01.000 --> 00:25:02.000
Right.
75
00:25:02.000 --> 00:25:06.000
A hundred percent login rate. We adopted the system. Really?
76
00:25:06.000 --> 00:25:07.000
What did you do?
77
00:25:07.000 --> 00:25:09.000
Percent of your people logging in.
78
00:25:09.000 --> 00:25:10.000
Right.
79
00:25:09.000 --> 00:25:12.000
But what are they doing when they're logged in?
80
00:25:12.000 --> 00:25:13.000
Right.
81
00:25:13.000 --> 00:25:33.000
You know, at Dell when we, we finally started analyzing, it's like we had all our servers were being lost to Apple. Well, Apple doesn't make servers, at least at this time. Well, I don't think they do now. And, but it was, what was the competitor? It was the first name on the list, and it was a required field. So what do people do? Apple.
82
00:25:33.000 --> 00:25:34.000
Bingo.
83
00:25:34.000 --> 00:25:35.000
Just so they can move forth.
84
00:25:35.000 --> 00:25:36.000
Bingo.
85
00:25:36.000 --> 00:25:40.000
That's. That's not following the process. That's not giving me the data I need to run my business.
86
00:25:40.000 --> 00:25:41.000
Right, right.
87
00:25:41.000 --> 00:26:40.000
Because it was probably hp. Right, right. Probably where I was losing the deal. And so my marketing department or my pricing department wants to do analysis against hp, not Apple. Right, right. And so the ripple effect of what this data and what this process is serving throughout the organ. Important, but that's not always understood. So a good SOP would start laying out like, you know, I always say, like, hip bone connected to the leg bone. Right. Like, what are the connective tissue between this project going live and operationalizing it into your business? And what does it really mean? What does it mean at the executive level? What does it mean at the SLT level? What does it mean at the working level? And what does it mean tangentially to the people who are on both sides of that? Right. And so if you think about sales data, I mean, sales data has impact on marketing, it has impacts on customer service, it has impacts on sales, it has impacts on product. Like all those teams. Want some kind of insight?
88
00:26:40.000 --> 00:27:28.000
Right, right. Absolutely, absolutely. So the SOP and the metrics, and I think. And, and the metrics have to be tied into the business case because you built your, your. Whether it's AI that you're using, you know, whatever, whether it's a process improvement, you have spent time, which equals money, and so you've got a payoff for that. So your metrics need to be tied into what is the business impact, whether it's reduction of time spent doing something or improvement on, you know, on revenues, whatever it might be. What else? So sfp, we've got metrics, you and I have talked about monthly reviews, quarterly resets, what's most effective for leaders and what's most effective for the users who. Ultimately, it's the ants two by two, that make things happen.
89
00:27:28.000 --> 00:28:52.000
Yeah, I, I always struggle with the quarterly weekly. I don't know that anybody has done it really well. I mean, I think for each individual group, I would argue you probably get some value out of it. But when you kind of start rolling those metrics up, I don't know that teams spend enough time analyzing what the metrics mean. And so it's one thing to go in, you know, at Salesforce, we used to have these decks and quarterly reviews were, you know, hundred slides long sometimes. If you were looking at the global business and you never got through a hundred slides. No one ever read a hundred slides with AI. People can just throw the deck into AI and say, give me the salient points. Right. But I think that they misinterpret what a quarterly or a review is. And I think a review is more about, you know, are we achieving a goal, are we not? And if we are, great, maybe we don't spend a lot of time there today. But if we're not, why aren't we? And what are those again, indicators of why we're not? I don't know that people spend a lot of time, you know, doing look backs and look forwards and comparisons and comparison. You know, there's always the line, the line chart. Right, right. But I don't know that they get into the details of, well, what is inefficient here? What are we missing?
90
00:28:52.000 --> 00:29:37.000
I was going to say, I think that's what's missing exactly. Who owns. Looking to see if we were to change this process by 1%. Can I move one of these numbers? That is a core KPI for my business unit, my department, whatever level it is that we're, that we're looking at. And I think that again, when we talk about day two, it is who is the process owner, who is the one who may not be carrying a number or a quota, depending on what organization they're in, but they are the ones who are looking to see where can we continue to improve and how do we make a single change, eliminate a step, whatever it might be, in order to get that throughput faster.
91
00:29:37.000 --> 00:31:16.000
I had this woman I used to work with at Accenture was just brilliant. And I was, I met up with her for coffee, it was a couple of years ago, and she was working at a software company and there she was taught. She, she had, she had always been in, you know, in consulting and so leading these big strategic programs. And she was, she wound up in a sales role. And so they went through the sales kickoff and, and she, she got up and she said, you know, everybody stand up if you know X about your clients. Everybody stand up if you know. And she went through this list of questions and at the end of the question, there was like two people standing. She goes, that's everything my team has done. Everyone on my team is standing because we do this differently. My team knows this information. And it was a really telling thing to say that she understood what those metrics were and what they meant to the business and what it signaled as a result of the goals they were trying to achieve. And she was 176% to goal. Right, right. Because she understood the underlying metrics and how those metrics related to the behavior and how those behaviors were manifesting and what, what she needed to do. And so, you know, you'll, you'll flip back, flip, flop, plop and say, well, that's, isn't that just change management? Isn't that a just adoption? And you'll be like, yes, but what you usually, if you do fund adoption and you do fund it properly, it ends at hypercare. And then to your point, it gets turned over to the business and the business is now accountable for it. And what's the first thing? There's nobody in the business to pick up.
92
00:31:16.000 --> 00:31:24.000
Right, right. There's no chance or it's a mad scramble and everything runs long. Agree, agree.
93
00:31:24.000 --> 00:32:46.000
And so when you talk about those things like who's accountable? Yeah, right. You talk about these quarterly reviews as well. Who are you sitting in the hot seat to say that this doesn't work? And to me, it falls on the feet of leaders and it goes right up the chain. That's my opinion. And if, if sales isn't meeting their goal, then what is sales leadership doing? And if sales leadership isn't doing anything, what is the chief revenue officer doing if chief revenue officer isn't doing it, the CEO doing? And, and I know that may sound simplistic, but I just feel like we've seen time and time again where companies are struggling and you just look and you say, well, that's because there's no procedure for them to follow. You're not measuring them in a way that is holding accountability to anybody. Sure, you get upset when the number's not made, but then the number is made the next quarter. I didn't see any change between when you didn't make the number of the prior quarter and you didn't make the number of the next quarter support. Right. Why are we getting 10,000 more support tickets? Well, sometimes it's a product problem. The product shipped and it was crappy or had bugs or. So the idea of these quarterly reviews is one is I think sometimes you boil the ocean.
94
00:32:46.000 --> 00:32:47.000
Right.
95
00:32:47.000 --> 00:33:18.000
And so you had a very watered down. And then there's never tangible outputs that people say, well, I want to come back and address these things. So, you know, example, like, hey, we said the metric was supposed to be 6%. We're at 2%. I need by next quarter that to be at 4%. And I want a tangible, you know, result or plan to how we're going to get that and the next quarter when we come in, it was 4%. I want to know that what worked, what got you to that 4%? Because now we're going to, because now
96
00:33:18.000 --> 00:33:19.000
we're going to double down.
97
00:33:19.000 --> 00:33:40.000
Right, but if it didn't work, then why didn't it work? Right? Like, and, and I think sometimes those could take, it could be a whole day or several days or whatever. But I don't think people have the patience, I don't think people have the like gravitas to dig into it and really get messy with it.
98
00:33:40.000 --> 00:33:44.000
Yeah, yeah, no, that's true. That is, that is true.
99
00:33:44.000 --> 00:34:25.000
And so I would just say for day two, when you're planning the project is, you know, how are you incorporating those metrics into what works, what, what is happening today? And if all those things aren't happening today, then how do we measure success? Because you're always going to measure it in the context of that program, not in the context of the business. And it doesn't, it doesn't work because once that program's over, that program's over. We've, we've achieved our results to deliver the technology. We haven't achieved our rights because that could be two, three years before we see that return on investment. Because to your point, the business case says, hey, year one, we get X, year two, we get year three.
100
00:34:25.000 --> 00:34:26.000
Exactly.
101
00:34:26.000 --> 00:34:42.000
And, and we were looking up stats earlier, we were talking about it and it said McKinsey had a stat that said only 12% of organizations sustain transformation gains for more than three years. So what they've gained is gone after three years.
102
00:34:42.000 --> 00:34:46.000
There's a slide back. What do you think contributes to that slide?
103
00:34:46.000 --> 00:36:12.000
I think a lot of things contribute to it. I think that often, again, to your point, starting up front projects are scoped wrong. They're, they're, they're scoped, they're under scoped. So when you get through design, the pot was this big, but the, the, the, the budget is this big, right? So then you're cutting, but the scope didn't change, right? So then you're adding phase after phase. So then, and they never re baseline the business case, which is wrong. So if I said the business case is going to deliver $10 million in the first year, but the $10 million predicated on that, you give me this. If at the end of solution design, I said, well, I can't give you this, I can only give you this, then you need to re baseline the business case. And a lot of people don't do that. Right? So, so then you Go through the project and you deliver it. And they're like, well I don't have X, Y and Z. So that's one thing. The second thing is what we had talked about in terms of stakeholders, business process, making sure you have the right people in the room is really understanding pain points, objections and tractors. So I will say on a project that I worked on, I will spend time with the stakeholders and say what's not going to make this successful? Why don't you know what, Sorry. The question would be what's your confidence?
104
00:36:12.000 --> 00:36:13.000
Right, right.
105
00:36:13.000 --> 00:36:55.000
That this will go successful. Let's say they say 70. Okay, let's talk about that 30 and, and that 30%. Let's document and then let's validate the hundred percent against the requirements. Right. But I'm really trying to get that 30% that you think is not there. And if it's truly not there, then that has to be go up to the steering committee. It has to be elevated. Like we're not delivering this. So if this is tied to value, we're not delivering it. So you can change the scope and increase the cost and the timeline or you make this phase two and we re baseline what the value of the output is. Because when you do the business case, you say, hey, I'm going to get $10 million in return.
106
00:36:55.000 --> 00:36:56.000
Right.
107
00:36:55.000 --> 00:37:11.000
And programming has only cost me a million. Great. I'm getting 9 million return in the first year. That's an amazing program. But really that isn't the case. Right, right. So I think that's, that's a big part of it is, is having that kind of understanding up front.
108
00:37:11.000 --> 00:37:12.000
Right.
109
00:37:12.000 --> 00:37:26.000
That I don't think happens because then you get on the back end and you have those people saying, well, I can't use it because it doesn't do X, Y, Z. Well, why didn't you say that in the design sessions?
110
00:37:26.000 --> 00:38:01.000
Which I think that's fair. Because some you can't, you cannot predict everything. And to your point, we get there and we're like, except for it's that rainy Tuesday and we missed it. Which I think makes the, the ongoing operating model even more critical. Because your process should not stop your development. If it's a tech, it shouldn't stop because we've suddenly gotten to the end of the end of the project. Because to your point, it is underpinning a business process. We need to continue to deliver on that business process because rainy days on Tuesdays happen.
111
00:38:01.000 --> 00:38:33.000
But I would argue that a couple of things happen with the rainy day Tuesdays. One is it Is it pushed enough and questioned? Well, how many times does that happen and are we building towards the exception? And a lot of people will just say, nope, you have to have it. You have to have it because nobody's challenged anybody to think differently about it. And so a lot of people don't want to change the business process because business process change just seems, I don't know why it seems harder than.
112
00:38:33.000 --> 00:38:35.000
Right.
113
00:38:35.000 --> 00:38:36.000
Technology.
114
00:38:36.000 --> 00:38:37.000
Right.
115
00:38:37.000 --> 00:39:38.000
In the age of AI, people don't care about that as much. But I think, you know, over the next couple of weeks we're going to have that conversation with a couple of experts which is, and in cap kind of talked about it last week is comp. And you asked that question is are we compressing the relationship between the business and IT to create more of iterative process? Where before when we do design review it was, you know, give me, give me answers to the questions and then over six months I'll give you a result. Whereas, you know, when we talked about what we did with them with the Vibe Fest and with the launch of aor, it was, people came into the Vibe Fest at the end of weeks, each of the teams with a prototype built in. Claude. So everybody sitting in the room was seeing a live demo of software, theoretically of how it would work. And so it did give a different perspective for people.
116
00:39:38.000 --> 00:39:39.000
Sure.
117
00:39:38.000 --> 00:40:20.000
And people I think connected some dots versus how they do it today. So maybe some of this goes away with the future of AI, but some of it, a lot of customers are straddled with 30 year old systems that they have to get off of and AI is not going to do that overnight. They're still buying SaaS, products like Salesforce, like Zendavo, like, you know, Service Max, go, go down the list. So those systems are adapting to this ecosystem as well. Right, right. You know, Dreamforce just happened. Claude. Force and, and AI Force and all this other branding they're doing, but they're changing with the time. So what does that mean?
118
00:40:20.000 --> 00:41:04.000
Right, right, right. Well and I think it still comes down to the, you know, people, people have to change what is the goal and if we stay focused on that again, starting with the customer most of the time, because that is usually the impetus for most of what a business does. What is it that we're trying to, that we're trying to, to resolve. And if we're making a change to that, then we need to get commitment all the way up to the top in terms of what does that change look like. And then we need to make sure that we are building for receiving that change and then continually monitoring that and rolling it out. Because to your point, the business case is multiple years long. We need to make sure that we've got owners for multiple years to make good on that.
119
00:41:04.000 --> 00:41:43.000
Well, and I also think that we can't discount that business has changed. So the strategy that existed in year one isn't the strategy in year three. And depending on the business and depending on the volatility of the market, that sometimes happens quicker. So what best laid intentions just doesn't happen. I mean, when we deployed Salesforce at Dell in 2007, I mean it was a two year project right before we were live with 174 countries, right? So I mean, what was true day one was not true day 642 or
120
00:41:43.000 --> 00:42:10.000
even day 30 in some cases. And, and what we're seeing with AI is, you know, three months is full, full life cycle of, of a product in some cases. And that's perfectly legit. But again, we've gotta have that rhythm for knowing when to say, okay, yep, this works, I have met my goal, or there's a better way to do it. And more importantly, that's where that operating rhythm really helps to identify is it time to move to a new, a new version?
121
00:42:10.000 --> 00:43:35.000
Well, and the point, that's a good point too because the business case should become part of the operating rhythm, right? It should become part of the standard of how we measure it. And so sometimes that, that number gets integrated into bigger numbers, right? And so sometimes the isolation of that number becomes harder. And so I do think that again how we kind of started the conversation is it takes a lot of thought and effort to think about how all these things connect. And so sometimes on these programs you don't engage those stakeholders like finance. Like, let's face it, finance is not, they're out there in the beginning to give you your money and they're measuring your budget month over month or quarter over quarter. But, but are they partnering with you when it goes live and saying, okay, now how do we measure this and how do we integrate it? And then when the budget changes or when the, the, the, the numbers change, have we lost that and do we have to re baseline to a different number? So I think the partnership with, with finance is an interesting one. And I also think it's interesting sometimes the, the corporate setup. And so, you know, one of the clients we work with it reported into finance, which I thought was weird, right? Because what does the CFO know about technology? But, but the output of every technology
122
00:43:35.000 --> 00:43:40.000
project goes to the Business, either the bottom line or the top line. Pick one.
123
00:43:40.000 --> 00:43:59.000
Right, right. And that's. It's funny you say that because that's the way we said it. It's like, is this bottom line or top line? Like what are we doing here? Are we saving money? We are we given money? And if we're giving money, that, that's a lot harder. If you want to save money, sometimes it's a little easier. Right. Like, hey, employees, I can take out.
124
00:43:59.000 --> 00:44:04.000
That is a very clean proof point. The other is a little, a little less.
125
00:44:04.000 --> 00:44:17.000
Right, right. And so I think that, you know, in terms of, you know, what is kind of, you know, putting these rhythms into practice to put a kind of bow on that piece is.
126
00:44:17.000 --> 00:44:19.000
Yeah.
127
00:44:19.000 --> 00:44:57.000
I think projects are seen in their inception as standalone things. Even if they, they talk about it in the context of the bigger thing. I think when you get into the execution of the program, the end is. Seems so far away. Nine months, 10 months, six months, whatever that timeframe is even I will say in three months. Right. Like you're so heads down developing that product and doing that. I don't think you're thinking of how it integrates. And I think people also have a hard time latching onto that because they can't touch it and feel it. Right, right, right.
128
00:44:57.000 --> 00:45:01.000
How do we bring that picture to life before they have to get there?
129
00:45:01.000 --> 00:45:02.000
Absolutely.
130
00:45:02.000 --> 00:45:31.000
And that is part of our job. But it is difficult sometimes to get to get your stakeholders to feel it, to touch it, to understand what the pressure of that situation is going to feel like. Right when we're still at day one of design versus far away from hypercare and UAT and go live. Okay. So we typically end these things with our guests with a rapid fire. You ready for some rapid fire?
131
00:45:31.000 --> 00:45:32.000
Let's do it.
132
00:45:32.000 --> 00:45:36.000
Okay. One meeting every company should kill.
133
00:45:36.000 --> 00:46:06.000
Probably a thousand of them. They should kill, but I think they should kill the meeting that doesn't produce a quality outcome. And I know that sounds very generic, but I think that every time there's a meeting like we had talked about, if there's not an accountable person coming into the meeting with whatever that meeting is about, and there is an accountability coming out of that meeting, then it was, then it wasn't time well spent.
134
00:46:06.000 --> 00:46:25.000
I'm going to chime on to that one. Somebody's accountable for the, for the meeting itself, but everybody who's attending needs to be accountable for taking something away with a follow on action. Because I think a lot of meetings are informational. Well, you know, the person will walk Away with information that person's not listening. So let's get real. Well.
135
00:46:25.000 --> 00:48:50.000
And I also think that meetings are run poorly and we used to do this thing for, for our EVP at, at Salesforce where we had leadership meeting. And his thing was he had direct reports, but he had many SVPs and VPs that didn't report directly to him and he wanted to engage them on a regular basis. So we had this leadership council and the way we ran it was there was an agenda for every, I think it was every two weeks. There's a set agenda that went out a week or so in advance. There was anybody who was presenting how to have a deck to me three days in advance and there was no exceptions. If you didn't get it in, you got cut from the agenda. And that the team members joining were expected to read and be knowledgeable about the deck and that the meeting was not about somebody presenting to them. The meeting was about having a conversation about this specific topic and how it relates to. If you want to be part of the management team and you want to be, you want to be contributing to the vision, right Then you can't just to your point, show up and listen and not have an opinion. And so the debates that would happen would help inform or adjust that strategy or that program. In some cases it may have been a update from the last time that they presented. Very rarely those were isolated but. But the point being is there was a structure and organization around how that meeting was run and the outcomes you expected. And if you couldn't achieve those, then you didn't have the meeting. And I think people should say define their meetings. This is informational only. I am here to engage you, to have a discussion, to get your feedback, to understand where your brain is at on this topic or this is a working session to actually dig into X, Y, Z. So I will have sessions where I'm like, hey, let me gather information from you. Then I'm going to send you a document and say I want you to read this document. Then I'm going to have a meeting because I know you didn't read the document that walks through the document. And at the end of that I'm going to expect you to tell me from that document what I'm missing. Because a lot of people are very reactionary, so they need to see it, touch it, feel it, like we talked about. So for those I would say like that's a good cadence and I know that isn't a rapid fire answer to your rapid fire.
136
00:48:50.000 --> 00:49:04.000
That's okay. But it does answer what meeting every company should start. But I think we've established that. Start making them effective with a very clear outcome. So I like that. Rhythm or strategy? Which one fails first?
137
00:49:04.000 --> 00:49:30.000
I think strategy. And the only reason I say strategy, and I'd like your opinion, is I think it changes constantly. I think people don't stick with a strategy long enough. And I don't know if it's because they never really thought through the strategy to begin with or they don't do a good job at creating a base strategy and adding onto it.
138
00:49:30.000 --> 00:49:57.000
Interesting. I was gonna say the base strategy plus the cascade, because I think a lot of times strategy fails because I don't know what my piece is. And if I've got a whole bunch of people who don't know what my piece is, then strategy fails, but we keep the rhythm, because that's the natural rhythm. These are people I work with. I know in my heart that, yeah, I should, you know, stay connected to these people. But we're not sure what we're working toward anymore or not with the fire that we need to.
139
00:49:57.000 --> 00:50:29.000
I also think, like, these programs, it's, you know, the people necessarily who are responsible for the outcome are not necessarily engaged in the strategy. And that's a really hard one because you can't have everybody involved. So I think, like, you know, it's like everything. It's like a filter that comes down. So the strategy, this big vision, you know, the CEOs CEO says we're going to achieve, you know, world dominance by X, Y, Z. Right, right. And then it's okay, how are we going to achieve world dominance? And who. Who needs to be part of that?
140
00:50:29.000 --> 00:50:31.000
Exactly.
141
00:50:31.000 --> 00:50:53.000
And so I think if you really look at these programs and how isolated sometimes they become from the strategy is because the people who then start running the programs are not attached and haven't. And nobody interpreted it down to your point and what you own. And then that goes back to. Well, then the SOP never changes, then the operator.
142
00:50:53.000 --> 00:51:03.000
Exactly, exactly. But it's all eventually got to go back up to. And again, that where it's okay. How do we operationalize this and how do we make sure that that payoff is coming in?
143
00:51:03.000 --> 00:51:04.000
Yeah.
144
00:51:04.000 --> 00:51:09.000
Nice. Okay, that's the end of my line of questioning for Rich Nazaro today.
145
00:51:09.000 --> 00:52:55.000
Okay. Yeah. No, I think. I think for people who are. Are thinking about day two and how their projects run, I think that they should think about it more. I think they should call us and talk to us about it, because we have a lot to say about it. But I also think just, you know, when you're hiring consultants, when you're thinking about it, are you hiring somebody to deliver a project? Are you hiring somebody to help you make change? Because consultants necessarily. I think you can separate the physical change aspect, which is adoption, communications, like those traditional things to, you know, what's the arc of this program that changes the trajectory of my business? And so what I always say when we run these programs is, you leave your badge at the door. I don't care who you work for. And we're here to make XYZ clients successful. And the way that looks like is this. And so everybody has to contribute their part and their feedback, and everybody's a sum of their experiences. So I may not know a lot about, you know, X's and O's and how are ones and zeros or how to code something. I do know when something doesn't smell right. And we need to make a change. Yeah. And so I think that people need to look at these programs more holistically, and I think that people like us and roles of transformational leadership for programs. We have a big burden on our shoulders to. To have those conversations and, and at least acknowledge the conversation exists, even if the client isn't ready to accept it. But continue that drumbeat of, like, is that success? Is that defined success? Does that define success?
146
00:52:55.000 --> 00:52:57.000
Right, right, right.
147
00:52:57.000 --> 00:53:09.000
Yeah. So the cool news is I think the next couple of guests we have over the next two months are going to dig into a lot of. Some of this from the aspects of AI. So I'm excited about that.
148
00:53:09.000 --> 00:53:10.000
Yeah. Yeah.
149
00:53:10.000 --> 00:53:17.000
And we'll. We'll. We'll continue to give people the information we think they need to be successful.
150
00:53:17.000 --> 00:53:25.000
Yeah. Yep. And we'll keep feeding the ideas of what's working and what's not because we've. We're in the trenches every day with it, so.
151
00:53:25.000 --> 00:54:07.000
Every day. Every day. Okay, we'll talk. All right, bye. One, two, three, four. Sam?
152
00:54:07.000 --> 00:54:27.000
Yeah.