1 00:00:01,840 --> 00:00:05,400 Mike, welcome to the Evolved Radio podcast. Thanks for having me, 2 00:00:05,400 --> 00:00:08,960 Todd, great to. Have you back as well. A returning guest. 3 00:00:09,280 --> 00:00:12,920 I think your previous episode, Advanced Project Management, it 4 00:00:12,920 --> 00:00:16,480 was episode 104. If people want to go check out 5 00:00:16,720 --> 00:00:19,120 some of the fun stuff that we talked about there. 6 00:00:20,560 --> 00:00:24,160 I want to start us off with basically 7 00:00:24,160 --> 00:00:27,040 my favorite stat that I've been quoting kind of the last two years, 8 00:00:27,940 --> 00:00:31,780 two stats actually, because I still feel like 9 00:00:31,780 --> 00:00:35,460 this is something that people are not alarmed enough about. So I will continue 10 00:00:35,540 --> 00:00:38,540 to talk about this. So the first stat, one of my favorite stats in the 11 00:00:38,540 --> 00:00:41,980 industry, people have probably heard this because Paul Dipple has been talking about this for 12 00:00:41,980 --> 00:00:45,540 a long time, is that a full 25% of the industry 13 00:00:45,860 --> 00:00:48,900 and the MSP channel is break even or losing money. 14 00:00:49,860 --> 00:00:53,700 So alarming stat enough to begin with, right? Everyone's kind of 15 00:00:53,700 --> 00:00:57,480 heard this probably at some point. The really interesting part of this 16 00:00:57,480 --> 00:01:01,200 was service leadership dug a little deeper and in the data they 17 00:01:01,200 --> 00:01:04,640 found that in that 25% that is struggling, 18 00:01:05,120 --> 00:01:08,840 most of them actually have profitable services. The problem is, 19 00:01:08,840 --> 00:01:12,600 is they're so bad at project management, they're cannibalizing all 20 00:01:12,600 --> 00:01:15,760 of the profits from the other departments of the business. 21 00:01:16,240 --> 00:01:19,960 And when I saw this, I was like, this absolutely makes sense 22 00:01:19,960 --> 00:01:23,170 like this. Why are people not recognizing this? 23 00:01:23,570 --> 00:01:27,250 They continue to sort of fight through service and automation. 24 00:01:27,330 --> 00:01:31,010 Projects still tends to be a bit of an afterthought in a lot of 25 00:01:31,090 --> 00:01:34,730 immature MSPs. And I don't think people recognize the 26 00:01:34,730 --> 00:01:38,450 damage that it's doing. And you guys obviously have a bit of a front row 27 00:01:38,450 --> 00:01:42,290 seat to this. I'm curious, sort of your take on, you know, 28 00:01:42,290 --> 00:01:45,730 how true you find this to be and what do we do about this? Both 29 00:01:45,730 --> 00:01:49,290 in promoting the idea of projects is how you fix your 30 00:01:49,290 --> 00:01:52,760 MSP profitability and then how do you go about that, I suppose. 31 00:01:53,470 --> 00:01:57,070 Yeah, yeah, absolutely. And it's a great question. And we know that statistic well, see 32 00:01:57,070 --> 00:02:00,870 that and kind of advise organizations around that. I guess there are a couple 33 00:02:00,870 --> 00:02:04,470 of components and this can kind of be split into several areas of sort of 34 00:02:04,470 --> 00:02:08,310 why does this happen for businesses? One of them is organizational 35 00:02:08,310 --> 00:02:11,830 maturity, right? A lot of MSPs as you know, even self 36 00:02:11,830 --> 00:02:15,670 describe, are accidental entrepreneurs. The way their business grows up and what 37 00:02:15,670 --> 00:02:19,230 they're doing. And so this idea of sort of disciplined project 38 00:02:19,310 --> 00:02:23,000 management around that process wasn't necessary if they were a 39 00:02:23,000 --> 00:02:26,840 single engineer or growing from small process and kind of moving forward because, 40 00:02:27,160 --> 00:02:30,840 you know, the human brain is amazing at managing a certain number 41 00:02:30,840 --> 00:02:34,440 of tasks, process and sort of Quote, unquote, the critical path in your head. They 42 00:02:34,440 --> 00:02:37,080 know the things to do to execute process, and when they're doing it on their 43 00:02:37,080 --> 00:02:40,440 own, there's no repercussions. But there's a point that, that business 44 00:02:40,600 --> 00:02:44,440 scales to a certain level where that no longer can be 45 00:02:44,440 --> 00:02:48,170 maintained in someone's head, how they're tracking and managing 46 00:02:48,170 --> 00:02:51,570 that. And so that becomes an issue organizational maturity. But 47 00:02:51,730 --> 00:02:55,010 this still happens even in a larger business 48 00:02:55,650 --> 00:02:59,450 where organizations struggle because of the scale of what they're 49 00:02:59,450 --> 00:03:02,970 doing and how they're tracking and managing all of their 50 00:03:02,970 --> 00:03:06,770 data. And so one of the big issues that we talk to 51 00:03:06,770 --> 00:03:10,050 organizations about is as they go forward on this is 52 00:03:10,690 --> 00:03:14,350 managing, how are you managing the critical path, your projects and how are you structuring 53 00:03:14,350 --> 00:03:18,150 your data? And for most organizations, they're just, 54 00:03:18,390 --> 00:03:21,510 I guess there are a couple of things we'll talk about structurally, how they manage 55 00:03:21,510 --> 00:03:24,550 projects. So it's sort of, it's sort of like you're saying, 56 00:03:25,190 --> 00:03:29,030 why is this program running badly? Well, because the code is bad, it's 57 00:03:29,030 --> 00:03:32,230 got lots of bugs in it. Would you ever expect software to run well that 58 00:03:32,230 --> 00:03:35,750 had buggy code in it and incomplete code? You're like, 59 00:03:36,230 --> 00:03:39,970 no, that's an absurd notion. But running projects that 60 00:03:39,970 --> 00:03:43,570 have really buggy plans that weren't complete and so 61 00:03:43,570 --> 00:03:47,290 it's aren't predictable, they aren't accurate, they're managing that. And I don't think 62 00:03:47,290 --> 00:03:50,850 that for a lot of these organizations. One, the technology 63 00:03:51,010 --> 00:03:54,570 that exists in the PSAs that they use don't 64 00:03:54,570 --> 00:03:58,090 have super robust project management platforms. And 65 00:03:58,090 --> 00:04:01,810 so they're managing shared lists. And lots of times 66 00:04:01,810 --> 00:04:05,330 when they use third party tools, certainly non integrated third party 67 00:04:05,330 --> 00:04:08,630 tools, they're using like shared lists that aren't 68 00:04:08,630 --> 00:04:12,270 reconciling with their psa. And this can become a really dangerous, 69 00:04:12,270 --> 00:04:15,990 risky thing. And so once again, the surprise is 70 00:04:15,990 --> 00:04:19,670 why are these projects going badly? Well, then there's 71 00:04:19,670 --> 00:04:23,470 the next thing, right? So let's say you had, even if 72 00:04:23,470 --> 00:04:27,110 you were managing the data in a third party system, to 73 00:04:27,110 --> 00:04:30,350 overcome the limitations of your PSA and 74 00:04:30,750 --> 00:04:33,390 you had really capable PNs in there. 75 00:04:34,500 --> 00:04:38,180 The thing that nearly everybody doesn't realize is 76 00:04:38,180 --> 00:04:41,940 that statistically for your project you're 77 00:04:41,940 --> 00:04:45,780 going to have problems. So the statistic that we'll often quote 78 00:04:45,780 --> 00:04:49,540 is a project plan that has 40 tasks on the critical path. You 79 00:04:49,540 --> 00:04:52,820 know, the dependent chain of tasks. For those listening who are not familiar with it, 80 00:04:52,980 --> 00:04:56,500 the critical path is, you know, this task is dependent on this, is dependent on 81 00:04:56,500 --> 00:04:59,300 this. It's that longest chain that defines the 82 00:04:59,780 --> 00:05:03,380 minimum length of that project and there could be 83 00:05:03,380 --> 00:05:06,540 100 or 200 tasks in the project. But if there were 40 on the critical 84 00:05:06,540 --> 00:05:10,260 path, if everybody got their 85 00:05:10,260 --> 00:05:13,700 work done on time, 90% of the time, that includes the 86 00:05:13,700 --> 00:05:16,940 customers and their responsibilities and distribution. 87 00:05:17,980 --> 00:05:21,540 Let's be real. And I think we all agree that's a ridiculously 88 00:05:21,540 --> 00:05:22,220 high number. 89 00:05:25,340 --> 00:05:29,180 Sorry, Mike, I cut you off like, oh, can you restate that? Yeah, yeah, I 90 00:05:29,180 --> 00:05:32,140 was just saying so. So I think we can agree that's a ridiculously high. Like 91 00:05:32,300 --> 00:05:35,780 I don't think any MSP would go, yeah, my engineers and everybody gets their stuff 92 00:05:35,780 --> 00:05:39,420 done on average 90% of the time. That's a high 93 00:05:39,420 --> 00:05:43,140 number. Self reporting in. But even if they did get it 94 00:05:43,140 --> 00:05:46,340 done, there's only a one and a half percent chance that that project would be 95 00:05:46,340 --> 00:05:49,700 on time. Even if it was beautifully built, beautifully 96 00:05:49,700 --> 00:05:53,180 structured, with all the detail in the world, the odds are horrible. 97 00:05:53,340 --> 00:05:57,160 And these are the same odds. To put it in the context that 98 00:05:57,160 --> 00:06:00,720 msps can understand, a task in a project 99 00:06:01,200 --> 00:06:04,600 is like an endpoint you're managing. It has a 100 00:06:04,600 --> 00:06:08,400 failure rate. And by the way, that task has a much 101 00:06:08,400 --> 00:06:12,040 higher failure rate than any endpoint you're managing. It just 102 00:06:12,040 --> 00:06:15,640 does. That failure is, oh, the parts didn't come in. I didn't know I was 103 00:06:15,640 --> 00:06:18,000 supposed to do it. I had to go to the customer site and it got 104 00:06:18,000 --> 00:06:21,710 rescheduled. So once again, you think about the ecosystem 105 00:06:21,710 --> 00:06:25,350 that you're managing. You have a lot 106 00:06:25,350 --> 00:06:29,110 of endpoints out there, a lot of tasks. And for some MSPs, they have as 107 00:06:29,110 --> 00:06:32,430 many tasks and projects as they do endpoints that they're managing over the course of 108 00:06:32,430 --> 00:06:36,230 a year. Right. But they get surprised and they think that everything's going 109 00:06:36,230 --> 00:06:39,310 to go off perfectly and the failure rate's higher. So they're like, you're telling an 110 00:06:39,310 --> 00:06:42,070 MSP, what are the odds you're going to go a couple of months with not 111 00:06:42,070 --> 00:06:45,880 a single endpoint problem? They would laugh at you. But 112 00:06:45,880 --> 00:06:48,600 they don't realize the failure rate is so much higher on the task. So that's 113 00:06:48,600 --> 00:06:52,160 the other part of this is that the, I'd say not just MSPs, the whole 114 00:06:52,160 --> 00:06:55,840 world doesn't realize all projects statistically are doomed to have problems. 115 00:06:55,840 --> 00:06:58,960 Now, what are you going to do about it? So hang on, let's pause on 116 00:06:58,960 --> 00:07:02,560 this because this sits on one of my other sort of favorite stats of 117 00:07:02,560 --> 00:07:04,720 project management in IT is that 118 00:07:05,440 --> 00:07:08,800 65% on average IT 119 00:07:09,040 --> 00:07:12,560 related projects are a failure. Right? Which is a pretty 120 00:07:12,560 --> 00:07:16,400 shockingly high number based on what you're saying around like the 121 00:07:16,400 --> 00:07:20,080 failure rate of projects. Do you think that that's more global across projects in general? 122 00:07:20,320 --> 00:07:24,080 Like projects as a whole are fail. Are tend to be failures or is 123 00:07:24,080 --> 00:07:27,760 the inherent complexity of it projects that leads to a higher 124 00:07:27,760 --> 00:07:31,360 failure rate? Yep. So, and I'm going to differentiate 125 00:07:31,440 --> 00:07:35,000 between delay and failure. Right. So there are lots of 126 00:07:35,000 --> 00:07:38,780 projects that are delayed, that are ultimately successful, successful 127 00:07:38,780 --> 00:07:42,500 projects, but they were delayed. So when I say there's a one and a half 128 00:07:42,500 --> 00:07:45,900 percent chance that that project will be done on time as planned. 129 00:07:46,300 --> 00:07:48,740 So you've got to realize we're going in this, we're going to have delays. Now 130 00:07:48,740 --> 00:07:52,100 if there's a drop dead date, you better know that you're going to be 131 00:07:52,100 --> 00:07:55,740 scrambling and you know the term crashing that project because 132 00:07:55,740 --> 00:07:59,180 you're likely to have problems unless you're at the 99 133 00:07:59,260 --> 00:08:03,020 percentile or 99. Like the probability is just bad. So, 134 00:08:03,020 --> 00:08:06,470 so that other statistic gets confounded 135 00:08:07,030 --> 00:08:10,630 by the fact that there are delays and risks and those projects get 136 00:08:10,630 --> 00:08:14,430 killed because confidence is lost. One of the big things that we 137 00:08:14,430 --> 00:08:17,190 always talk to a lot of our customers about and I think one of the 138 00:08:17,270 --> 00:08:19,190 interesting things that we learn 139 00:08:20,870 --> 00:08:24,430 improving to the point of the benefit to 140 00:08:24,430 --> 00:08:28,070 improving project management is not only the margins, which is 141 00:08:28,070 --> 00:08:31,790 really, really important atomically when you look at a project and go, hey, 142 00:08:32,030 --> 00:08:35,470 we were profitable on this project. But the other really 143 00:08:35,630 --> 00:08:38,110 super important thing that we learned over the last couple of years that We've heard 144 00:08:38,110 --> 00:08:41,870 from CEOs of a lot of our customers was the fact of I 145 00:08:41,870 --> 00:08:45,469 have better credibility now with my customers, which means they're a better reference and they're 146 00:08:45,469 --> 00:08:49,230 more likely to renew. In the past, when I was missing dates 147 00:08:49,230 --> 00:08:53,070 which they didn't know they were doomed to have problems with and they didn't 148 00:08:53,150 --> 00:08:56,490 know when they were missing the dates the customer would call him and go, 149 00:08:57,610 --> 00:09:00,890 feel like you should have known about this, feel like you should have known about 150 00:09:00,890 --> 00:09:04,490 this delay. And by the way, if, if you didn't know we were going to 151 00:09:04,490 --> 00:09:08,330 be a month late on this, what else are you missing? And a 152 00:09:08,330 --> 00:09:12,090 lot of these organizations lost customers and big customers because they were. 153 00:09:12,490 --> 00:09:15,930 The customer went, you're making me stressed because 154 00:09:16,330 --> 00:09:19,330 you don't seem like you're on top of this. And they're, they were totally on 155 00:09:19,330 --> 00:09:22,290 top of their managed services. But it gave the 156 00:09:22,930 --> 00:09:26,650 appearance of. So there's a, like to your point, there's 157 00:09:26,650 --> 00:09:29,730 two really important reasons why do you want to get your house in order on 158 00:09:29,730 --> 00:09:33,410 this. One, don't lose 159 00:09:33,410 --> 00:09:37,170 money. You don't need to lose. But Two, this is your reputation and you 160 00:09:37,170 --> 00:09:40,770 know, we're an AI vendor and AI project management, blah blah, blah, and automation. 161 00:09:41,010 --> 00:09:44,650 But I don't care how much AI and automation comes into the 162 00:09:44,650 --> 00:09:48,350 MSP industry will be relationship based. I think it will 163 00:09:48,350 --> 00:09:52,150 always be relationship based. And if it isn't relationship based, it 164 00:09:52,150 --> 00:09:55,550 goes, goes away. I mean, so that 165 00:09:55,550 --> 00:09:59,190 relationship is based on credibility. And one of the, what I would 166 00:09:59,190 --> 00:10:02,750 love to hear, and I don't know how we get to this statistic is how 167 00:10:02,750 --> 00:10:06,390 much credibility damage is occurring. You know, you're saying, oh, 25% 168 00:10:06,390 --> 00:10:09,870 lose money and that's based on bad project management. What 169 00:10:09,870 --> 00:10:13,630 percentage of churn is related to the fact that they dropped the ball 170 00:10:13,630 --> 00:10:17,460 in a project? Not, not race to the bottom on pricing 171 00:10:17,460 --> 00:10:20,660 per node, not other things, but damaged 172 00:10:20,740 --> 00:10:24,540 customer sentiment because hey, you mismanaged some 173 00:10:24,540 --> 00:10:27,860 really important projects to me was really frustrating to me and my team 174 00:10:28,340 --> 00:10:31,940 and you know, maybe if you'd communicated better, 175 00:10:31,940 --> 00:10:35,140 we wouldn't be so mad. And that was the other issue. We'll tell clients 176 00:10:35,700 --> 00:10:39,460 you're not going to eliminate delays. This 177 00:10:39,460 --> 00:10:43,270 idea that you think you're going to ever prevent a delay with the world's best 178 00:10:43,270 --> 00:10:46,910 project, but you want to know early, you want to know soon, so you can 179 00:10:46,910 --> 00:10:49,510 call your customer and go, hey, we're going to have a problem in six weeks. 180 00:10:49,590 --> 00:10:53,070 Not oh, we had a problem a week ago and it's going to create a 181 00:10:53,070 --> 00:10:56,790 six week delay. Like that's what happens for a lot of these organizations. And 182 00:10:56,870 --> 00:10:59,990 so like I said, there's a two hit thing. You lose money and then you 183 00:10:59,990 --> 00:11:03,670 lose customers and you lose reference of all customers with bad project management. 184 00:11:03,670 --> 00:11:07,310 So yeah, this is, this is huge because like this is, I'm 185 00:11:07,310 --> 00:11:10,950 pulling out all the stats today. Like this is the other thing that I found 186 00:11:10,950 --> 00:11:14,650 really fascinating, especially kind of two years ago. Similarly related, 187 00:11:14,650 --> 00:11:18,450 like I was doing this talk all year about sort of efficient project management. 188 00:11:18,450 --> 00:11:21,490 So I was talking about these things ad nauseam all year. 189 00:11:22,530 --> 00:11:26,250 The other piece was that more MSPs are losing customers 190 00:11:26,250 --> 00:11:30,010 due to project failures than service failures. And that's a switch. Like that's not 191 00:11:30,010 --> 00:11:33,810 always been the case. It was usually service desks that caused that loss 192 00:11:33,810 --> 00:11:37,410 of trust. Of like I submitted a ticket two weeks ago, 193 00:11:37,490 --> 00:11:41,340 no one ever even called me back. Right. Like that stuff is what eroded 194 00:11:41,340 --> 00:11:45,020 that trust. Most people, I think of most organizations have gotten 195 00:11:45,020 --> 00:11:48,340 to a place where their help desk is pretty good. You know, there's obviously 196 00:11:49,140 --> 00:11:52,740 like a spectrum of people's capability of maturity on delivery on that side, 197 00:11:52,820 --> 00:11:56,539 but projects again, like it's just, it's really dropping the ball. And I've heard multiple 198 00:11:56,539 --> 00:12:00,020 stories from MSPS where they got completely blindsided by 199 00:12:00,020 --> 00:12:03,820 customer customers canceling their contract because of 200 00:12:03,820 --> 00:12:07,460 project failures. And they were, they were, they were totally caught off guard. 201 00:12:07,540 --> 00:12:11,180 So I think again, like that's a really important reflection of like this means a 202 00:12:11,180 --> 00:12:14,840 lot because now, now not only you more, more likely to 203 00:12:14,840 --> 00:12:18,560 lose money because of projects, you're actually more likely to be fired because of 204 00:12:18,560 --> 00:12:22,080 projects and lose customers as a result. Yeah, it's a double hit. 205 00:12:22,320 --> 00:12:26,080 Yeah, it's a double hit. All right, 206 00:12:26,080 --> 00:12:29,640 so I want to understand a bit about what we do about 207 00:12:29,640 --> 00:12:33,400 this, right. Because I think there is a general baseline like, 208 00:12:33,400 --> 00:12:37,120 like what you're talking about, I strongly believe in is that there are just 209 00:12:37,200 --> 00:12:40,720 fundamentals that people are not putting in place in managing 210 00:12:40,720 --> 00:12:44,160 projects. Right. Like a lot of this just happens off the side of someone's. 211 00:12:44,620 --> 00:12:48,100 Because you know, the tyranny of now, you know, I do this whole band, 212 00:12:48,100 --> 00:12:51,940 busy campaign and everyone excuses the fact that 213 00:12:51,940 --> 00:12:55,540 the stuff doesn't get done because I'm busy. Right. And 214 00:12:55,540 --> 00:12:59,180 that because of these reasons, that's unacceptable. So like where do you 215 00:12:59,180 --> 00:13:02,540 start? Right. I guess is the important aspect of this because 216 00:13:02,940 --> 00:13:06,180 sure, like I'm always, I would say I'm the first to admit the 217 00:13:06,180 --> 00:13:09,980 psa. Most of the project modules in there are okay at best they're not 218 00:13:09,980 --> 00:13:13,710 great but as you say, don't go into a third party tool 219 00:13:13,710 --> 00:13:16,750 because that's not the problem. It's the 220 00:13:16,990 --> 00:13:20,750 fundamental systems that you're putting in place, the expectations of how 221 00:13:20,750 --> 00:13:24,430 these projects get scoped, implemented and managed. And that doesn't 222 00:13:24,430 --> 00:13:28,190 require a lot of rocket science. Like that's just the basic tasks of this stuff. 223 00:13:28,190 --> 00:13:31,390 And then you can layer on the complexity on top of that and make things, 224 00:13:31,470 --> 00:13:35,310 you know, spin tops and do amazing things and automate 225 00:13:35,310 --> 00:13:38,670 stuff and. But you need those fundamentals in place, right? 226 00:13:39,700 --> 00:13:43,420 Yeah, yeah. And I guess, I guess a couple of things in that regard and 227 00:13:43,420 --> 00:13:47,180 just at least from, and everyone has different sort of industry perspectives and 228 00:13:47,180 --> 00:13:50,940 I, and I hear what you're saying as far as, hey, what is the need? 229 00:13:50,940 --> 00:13:54,500 What is the baseline? It's, there's not one quick 230 00:13:55,140 --> 00:13:57,620 solve for it. And it depends on the size of the organization. 231 00:13:58,900 --> 00:14:02,660 Right. And what are their problems and their challenges. The 232 00:14:02,660 --> 00:14:06,020 larger organizations will say for sure it is a technology problem. The 233 00:14:06,020 --> 00:14:09,700 PSAs are inadequate to do that and manage the scale when you know, 234 00:14:09,700 --> 00:14:13,420 we have customers with 3,500 projects 235 00:14:13,420 --> 00:14:17,220 in their portfolio with projects of a thousand tasks, 236 00:14:17,780 --> 00:14:21,340 you know, individual Projects that have a thousand tasks in them, the 237 00:14:21,340 --> 00:14:24,900 PSAs cannot manage this in any way, shape or form and it becomes a 238 00:14:24,900 --> 00:14:28,180 dumpster fire. Now, I will say using a third party tool that is not integrated, 239 00:14:28,740 --> 00:14:32,500 you're. The costs and the chaos of that are a huge problem. 240 00:14:32,500 --> 00:14:36,220 Right? So having a third party with swivel. Chairing between two systems, you 241 00:14:36,220 --> 00:14:39,820 have no data integration, right? But like layering something on top of the 242 00:14:39,820 --> 00:14:43,420 psa, I'm still a fan of that, to be clear. Yep, yeah, 243 00:14:43,420 --> 00:14:45,660 yeah, we have customers that come in and go, oh, I don't want to do 244 00:14:45,660 --> 00:14:49,460 the integration. We're like, yeah, you do, you do want to do the integration. Because 245 00:14:49,460 --> 00:14:52,820 you're just not going to want to deal with that. And, and having the integration 246 00:14:52,820 --> 00:14:56,499 where it's not just the tasks and its completion, but the structure, 247 00:14:56,499 --> 00:14:59,500 the product process, the tickets, the time, the notes, 248 00:15:00,060 --> 00:15:03,780 all of that, the custom status is the role, all of that stuff 249 00:15:03,780 --> 00:15:07,600 has to go back and forth because you want your engineers looking at the PSA 250 00:15:07,600 --> 00:15:11,240 is a source of truth for their work, right? You have your PMs and 251 00:15:11,320 --> 00:15:15,120 you got engineers floating in between regular ticket 252 00:15:15,120 --> 00:15:18,920 work and project work. So, so having a place where 253 00:15:18,920 --> 00:15:22,759 accurate data can live is critically important. Once again, I'm not 254 00:15:22,759 --> 00:15:25,960 saying anything that. And I will say the PSA vendors and the heads of products 255 00:15:25,960 --> 00:15:28,160 have come to me and talked to me about this, going, hey, we know this 256 00:15:28,160 --> 00:15:31,800 isn't kind of great in our product, but that goes into resource management 257 00:15:31,880 --> 00:15:35,590 isn't just the project management because what's important to the MSPS dates isn't 258 00:15:35,590 --> 00:15:39,230 just about the project delivery dates, it's about effective resource management because 259 00:15:39,230 --> 00:15:42,470 that impacts the margins, right? So, yeah, automating 260 00:15:42,470 --> 00:15:45,310 scheduling. So I'll say a couple of things, right? 261 00:15:48,190 --> 00:15:51,630 People do things that they have to do and want to do. They don't do 262 00:15:51,630 --> 00:15:54,950 things they should do. So you and I can sit here all day long and 263 00:15:54,950 --> 00:15:58,590 tell people, you should do this, you should stop smoking or 264 00:15:58,590 --> 00:16:01,950 stop drinking or lose weight. And nobody will do that 265 00:16:02,440 --> 00:16:05,960 unless they want to or they have to do it. So 266 00:16:06,040 --> 00:16:09,760 the first thing that any MSP listening to this has to 267 00:16:09,760 --> 00:16:12,720 look at it and go, like, if they're listening to you and I and they 268 00:16:12,720 --> 00:16:16,440 see us as pontificating about best practice and what you should be 269 00:16:16,440 --> 00:16:19,640 doing is not going to do it. Don't waste your time. But if they go, 270 00:16:19,640 --> 00:16:22,560 hey man, I am tired of this, like, I have to move to the next 271 00:16:22,560 --> 00:16:26,000 level. This is painful, I'm tired of the embarrassment. I don't want to waste money 272 00:16:26,000 --> 00:16:29,780 unnecessarily there's a real want there. And there's also a risk 273 00:16:29,780 --> 00:16:33,180 for them to sort of say, hey, we have to do this. And you know, 274 00:16:33,180 --> 00:16:36,340 if someone's not willing to kind of go, hey, we have to do this, then 275 00:16:36,580 --> 00:16:40,220 I do believe anything we say is a waste of time and they should just 276 00:16:40,220 --> 00:16:44,020 turn this off. Sorry, I don't mean to like reduce the viewership or even 277 00:16:44,020 --> 00:16:46,740 watch the rest of it, but if they are willing to do it, 278 00:16:48,100 --> 00:16:51,780 there are two things that we always say, hey, maybe you're not 279 00:16:51,780 --> 00:16:55,580 doing this today and you have to add these two data items that 280 00:16:55,580 --> 00:16:59,190 maybe you're not doing today. Like, so they're describing what the task is 281 00:16:59,190 --> 00:17:02,990 today, right? Hey, we've got to go install a firewall or 282 00:17:02,990 --> 00:17:05,390 we have to do this or we have to do that. And they're assigning a 283 00:17:05,390 --> 00:17:09,150 resource and maybe they're putting a work estimate in there. 284 00:17:09,150 --> 00:17:12,630 Like we think this is going to take three hours, that's our budget, four hours. 285 00:17:12,630 --> 00:17:16,270 And they know their cost. But two things a lot of them aren't 286 00:17:16,270 --> 00:17:19,910 doing. We say the double D is a dependency and a duration. 287 00:17:20,070 --> 00:17:23,920 You know what has to happen before this? Sometimes there 288 00:17:23,920 --> 00:17:27,680 are different types of dependencies, but they don't even have to go down that path. 289 00:17:28,080 --> 00:17:31,760 They have to give it a duration. Like, hey, I want you to 290 00:17:31,760 --> 00:17:35,200 configure this firewall. I understand it's going to take an hour, two hours, whatever it 291 00:17:35,200 --> 00:17:38,800 is, I'm going to give you five days to do it. That 292 00:17:38,800 --> 00:17:42,400 dependency and duration, the minute you do that in any project plan, 293 00:17:42,720 --> 00:17:46,440 you've now programmed work that unlocks a 294 00:17:46,440 --> 00:17:50,140 ton of automation. It also means your work can be debugged. It 295 00:17:50,140 --> 00:17:53,700 means you can autonomously look at resource capacity conflicts. 296 00:17:53,780 --> 00:17:57,220 You can automatically schedule. Like it unlocks a 297 00:17:57,220 --> 00:18:00,940 universe of efficiency. But if you go, I can't 298 00:18:00,940 --> 00:18:03,980 be bothered with that. My team, they don't do it today, they're going to find 299 00:18:03,980 --> 00:18:07,660 it to be a hassle. Then you go, okay, but just so 300 00:18:07,660 --> 00:18:10,660 you know, you are 301 00:18:11,140 --> 00:18:14,900 abdicating your ability to ever get out of 302 00:18:14,900 --> 00:18:18,670 this hell of the unpleasant surprise of why were we late on that? 303 00:18:18,670 --> 00:18:22,230 What happened with that project? Why did we lose money on it? You're 304 00:18:22,230 --> 00:18:25,470 foregoing automation. And it's almost like you're saying we want to be a break fix 305 00:18:25,470 --> 00:18:29,270 business. No, MSP would go, we love being a break fix business. And people 306 00:18:29,270 --> 00:18:33,110 who aren't automating project management are running break fix projects. 307 00:18:33,110 --> 00:18:36,670 That's what they're doing. And so if they're willing to add those 308 00:18:36,670 --> 00:18:40,350 two Other details, hey, dependencies and durations. If the 309 00:18:40,350 --> 00:18:43,910 technology can support it, they now have the ability to 310 00:18:44,070 --> 00:18:47,710 automate a lot of functionality, accuracy and 311 00:18:47,710 --> 00:18:51,470 predictive capability in the platform. So we always say like, 312 00:18:51,470 --> 00:18:54,550 that's a, for us, that's a pre qualifier. We're like, look, if you're not willing 313 00:18:54,550 --> 00:18:57,910 to do these two things, you're just not going to reap 314 00:18:58,310 --> 00:19:01,990 benefits that AI and automation can provide you in project management and you're 315 00:19:02,230 --> 00:19:05,990 just going to continue to get blindsided. So you have to do that math, figure 316 00:19:05,990 --> 00:19:09,380 out whether or not that's worth it to you. Well, this is the part, like, 317 00:19:09,380 --> 00:19:11,740 one of the things that absolutely drives me crazy about the way that we do 318 00:19:11,740 --> 00:19:15,580 projects in the MSP industry because we found this business 319 00:19:15,740 --> 00:19:19,580 model that we get paid regardless of whether or not we're doing work, which 320 00:19:19,580 --> 00:19:23,020 allows scale, right? Like the MSA model versus time and 321 00:19:23,020 --> 00:19:26,820 material. That's why margins are 60 to 70% instead 322 00:19:26,820 --> 00:19:30,660 of 25. And then we pivot to doing projects and 323 00:19:30,660 --> 00:19:34,460 go right back to the TNM model where we're just paying for hours, right? Like, 324 00:19:34,460 --> 00:19:37,860 how many hours did we do? What are we billing for? What's the labor rate 325 00:19:37,860 --> 00:19:40,840 on this person? And therefore how much margin can we make? The only way you 326 00:19:40,840 --> 00:19:44,520 make more money is by adding more people and more hours. So you're like, 327 00:19:44,520 --> 00:19:48,280 why have we given up on the MSP 328 00:19:48,360 --> 00:19:51,840 model for projects when we recognize how great it is for our 329 00:19:51,840 --> 00:19:55,519 businesses, right? I think like this, this drives me nuts of like not 330 00:19:55,519 --> 00:19:59,280 being able to plan, resource plan and understand sort of how this project 331 00:19:59,280 --> 00:20:02,840 gets implemented so that it is, it is more predictable. I think 332 00:20:03,320 --> 00:20:06,480 it's a call to arms for people of like, work towards this. This is not 333 00:20:06,480 --> 00:20:09,760 something you can do tomorrow. But these are the basic things that you need to 334 00:20:09,760 --> 00:20:13,500 start to put in, can evolve your process and make 335 00:20:13,500 --> 00:20:16,980 it more mature over time so that you can move from 25% 336 00:20:17,060 --> 00:20:20,260 to, you know, 40, 50, 60% projects. 337 00:20:20,900 --> 00:20:24,660 Well, and this is one of the things that also, you 338 00:20:24,660 --> 00:20:28,500 know, we talk about limitations of the tech that they may be using in 339 00:20:28,500 --> 00:20:32,300 the PSAs is this ability to analyze the performance of their 340 00:20:32,300 --> 00:20:34,700 projects. Like, so if you're going to go to a fixed fee model and we 341 00:20:34,700 --> 00:20:38,350 talk about this, you're going to do a fixed fee model, you're not going to 342 00:20:38,350 --> 00:20:41,910 have the time to do a retro. Like large organizations, when they have large monolithic 343 00:20:41,910 --> 00:20:44,870 projects, they do a retrospective and go, how did we perform? What did we do? 344 00:20:44,870 --> 00:20:48,710 What do we do? But msps, even the large ones, don't have the Bandwidth to 345 00:20:48,710 --> 00:20:52,390 do these retros to understand. Where did we misquote this? Where do we need to 346 00:20:52,390 --> 00:20:55,550 modify this? So once again, coming back to 347 00:20:56,110 --> 00:20:59,270 listing dependencies, durations and work estimates and being able to 348 00:20:59,270 --> 00:21:02,990 automatically analyze that template that you're using and 349 00:21:02,990 --> 00:21:06,840 this idea of productizing services to your point, right? So, hey, 350 00:21:06,840 --> 00:21:09,880 what is our service delivery offering? Let's create a template. 351 00:21:10,440 --> 00:21:13,600 Let's make that a product that we're going to offer. We're going to estimate the 352 00:21:13,600 --> 00:21:17,080 work hours. But then being able to understand after the execution of that project, hey, 353 00:21:17,080 --> 00:21:19,760 we got it wrong. We thought that was going to be two hours. It's actually 354 00:21:19,760 --> 00:21:22,840 six hours. Okay. When we bid this out again, we're going to bid it at 355 00:21:22,840 --> 00:21:26,600 six hours and, and knowing that ahead of time and because they're 356 00:21:26,600 --> 00:21:29,720 not doing retros, to your point, this is one of the areas why 357 00:21:30,870 --> 00:21:34,430 so many of these MSPs lose money in their projects. They're scoping because they have 358 00:21:34,430 --> 00:21:37,990 no ability. They're not big enough. They don't have to. Even the big companies can't 359 00:21:37,990 --> 00:21:41,710 do the appropriate analytics to dial that template in. And the 360 00:21:41,710 --> 00:21:45,350 other component is scope creep, that they don't have a structured 361 00:21:45,350 --> 00:21:49,110 process to capture new cost and then move 362 00:21:49,110 --> 00:21:52,710 that into the customer and, and you can't tell a customer. And 363 00:21:52,710 --> 00:21:55,830 this is one of our favorite statistics too, that we talk about is 364 00:21:56,390 --> 00:21:59,910 they'll identify cost overruns 60 to 90 days 365 00:21:59,910 --> 00:22:03,630 after when, you know, if they don't have an automated way to 366 00:22:03,630 --> 00:22:07,390 do that retro or identify the risk automatically. Once again, this is the benefit of 367 00:22:07,390 --> 00:22:11,070 AI and automation during project execution is you identify when 368 00:22:11,070 --> 00:22:14,630 it's coming off the rail. So, you know, if I was renovating your bathroom, Todd, 369 00:22:14,710 --> 00:22:18,310 and I came to you midway through and said, 370 00:22:19,270 --> 00:22:22,150 hey, you have rotted floorboards. We pulled the tile up. I know you want a 371 00:22:22,150 --> 00:22:25,810 new tile. You got rotted floorboards. We're going to have to rip that out and 372 00:22:25,810 --> 00:22:29,010 put it in, blah, blah, blah, blah, blah. And it's going to be an extra, 373 00:22:29,010 --> 00:22:32,410 you know, six grand. Like, but we kind of need to do this. You're gonna 374 00:22:32,410 --> 00:22:36,210 go, yep. Okay, now imagine, finish 375 00:22:36,210 --> 00:22:40,010 the bathroom. I bill you, and 90 days later, after 376 00:22:40,010 --> 00:22:43,730 billing you $38,000 to redo your. Bathroom, by the way, 377 00:22:43,730 --> 00:22:47,530 I replaced your. Four, by the way, we had to rip out the 378 00:22:47,530 --> 00:22:50,690 floor. I forgot to tell you, we had to rip out the wooden floor to 379 00:22:50,690 --> 00:22:54,290 do this. It's another six grand. You're going to go, no, 380 00:22:54,450 --> 00:22:57,850 like you were willing to pay it in the middle of the project, but you're 381 00:22:57,850 --> 00:23:01,530 Now, a hard no, because you paid that bill 30 or 60 days 382 00:23:01,530 --> 00:23:04,290 ago. And so this is another major reason 383 00:23:04,930 --> 00:23:08,290 MSPs get stung on this. And once again, if they're 384 00:23:08,530 --> 00:23:11,690 willing to make some process changes, and you preach this a lot, and I know 385 00:23:11,690 --> 00:23:15,530 you're trying to develop and elevate their experience for project management, but there 386 00:23:15,530 --> 00:23:18,950 are big dividends that they're willing to, you know, 387 00:23:19,270 --> 00:23:22,470 one, change their process a little and get the right tech in place 388 00:23:22,950 --> 00:23:26,590 so they can live real time, identify these risks, the 389 00:23:26,590 --> 00:23:30,230 delays, real time, the budget overruns, real time, because then they can 390 00:23:30,230 --> 00:23:33,990 adjust in flight. And once again, and I'll shut up here in a 391 00:23:33,990 --> 00:23:37,750 second, it goes back to that endpoint model. Like, do you want to find 392 00:23:37,750 --> 00:23:41,270 out about that, that noisy node or potential problem 393 00:23:41,830 --> 00:23:44,990 early or do you want to find out after it blew up and took the 394 00:23:44,990 --> 00:23:48,730 whole network down? And right now, once again, for most MSPs that 395 00:23:48,730 --> 00:23:52,450 don't have discipline around this, it's blowing up and taking the 396 00:23:52,450 --> 00:23:55,930 whole network down, I. E. The whole project down, that they don't have any kind 397 00:23:55,930 --> 00:23:59,610 of early detection or warning about that. And this is like, I think, 398 00:23:59,610 --> 00:24:02,370 like, this is full circle, right? Because I feel like the 399 00:24:03,730 --> 00:24:07,570 part of the reason that people are not able to manage those costs on 400 00:24:07,570 --> 00:24:11,050 the fly is that they're uncomfortable having these conversations with the 401 00:24:11,050 --> 00:24:14,880 customer around a change of scope and cost. Right? But they're. 402 00:24:15,120 --> 00:24:18,800 So, they're just absorbing it because they're like, well, you know, the customer will probably 403 00:24:18,800 --> 00:24:21,960 say no, maybe they're going to be angry at us. They, they sort of justify 404 00:24:21,960 --> 00:24:25,640 the idea that they should eat the costs on the project or the scope 405 00:24:25,640 --> 00:24:29,240 change or the overruns without sort of having a transparent business 406 00:24:29,240 --> 00:24:32,880 conversation about that. The problem is, is I think most people don't recognize the 407 00:24:32,880 --> 00:24:36,600 impact of that, right? Because their P and L has a 408 00:24:36,600 --> 00:24:40,240 blended service between help desk and projects, 409 00:24:40,240 --> 00:24:43,960 right? So it's like, well, you know, we're, we're doing okay not 410 00:24:43,960 --> 00:24:47,180 recognizing your Service delivery is 411 00:24:47,180 --> 00:24:50,820 60%, but your project delivery is like 5 or negative 412 00:24:50,820 --> 00:24:54,620 15, right? Yes. And 413 00:24:54,620 --> 00:24:57,460 the thing is, some MSPs are like, well, we're just not going to do project 414 00:24:57,460 --> 00:25:01,100 work anymore. And you're like, okay, so now you're opening the door for a competitor 415 00:25:01,100 --> 00:25:04,700 to come in and do that project well and take your business. 416 00:25:04,860 --> 00:25:08,460 So they're like, this idea that you can ignore this problem and 417 00:25:08,460 --> 00:25:11,790 it'll go away or just give it to somebody else is 418 00:25:11,790 --> 00:25:15,550 chording churn, right? Yep. All 419 00:25:15,550 --> 00:25:19,070 right, so one other bit I wanted to get, get your, your Input on 420 00:25:19,630 --> 00:25:23,270 is how much detail is enough. And maybe this is kind of a continuation 421 00:25:23,270 --> 00:25:26,750 of what we're talking about here because there is sort of this happy 422 00:25:26,750 --> 00:25:30,550 medium somewhere between like it just 423 00:25:30,550 --> 00:25:34,270 a gory amount of detail and everything has checkboxes and 424 00:25:34,270 --> 00:25:38,110 you know, every little, little unit is tracked. You know, 425 00:25:39,080 --> 00:25:42,920 been working with this organization. They do a lot of physical deployments and it 426 00:25:43,000 --> 00:25:44,520 has a lot of 427 00:25:46,440 --> 00:25:50,040 individual devices in numerous places. So there's a huge amount of 428 00:25:50,040 --> 00:25:53,800 information to track here. And they're looking to improve their project delivery 429 00:25:53,800 --> 00:25:57,320 process from where they were and they're getting good gains as a result of that. 430 00:25:57,400 --> 00:26:01,160 But they're getting a bit of pushback from or from the staff of just like 431 00:26:01,400 --> 00:26:05,240 oh my God, like this spreadsheet is eight pages long 432 00:26:05,240 --> 00:26:08,560 of things that we kind of need to go through and verify in order to 433 00:26:08,560 --> 00:26:12,320 make sure the project is complete. And like I'm of two 434 00:26:12,320 --> 00:26:16,120 minds of this recognizing like look, that information is important. This is just 435 00:26:16,120 --> 00:26:18,920 the stuff we need to do on the project. But if you're coming from a 436 00:26:18,920 --> 00:26:22,480 low maturity state and you're asking for high maturity delivery, 437 00:26:22,640 --> 00:26:26,400 then there's going to be a lot of friction in sort of how you move 438 00:26:26,400 --> 00:26:29,920 that ball forward and get the buy in from the team. Any thoughts on sort 439 00:26:29,920 --> 00:26:33,640 of a circumstance like that of like we're meeting resistance on trying to 440 00:26:33,640 --> 00:26:37,040 do the right thing because maybe we're asking for too much too early. 441 00:26:38,060 --> 00:26:41,740 Yeah. So the ROI 442 00:26:41,740 --> 00:26:45,260 is sort of a step function on this about the changes an organization's 443 00:26:45,260 --> 00:26:49,060 willing to make and the benefits that they're going to receive. But and there's a 444 00:26:49,060 --> 00:26:52,340 little bit of this. Don't. If you're not going to do at least this much 445 00:26:52,340 --> 00:26:55,500 then don't bother doing anything because it's going to be a bigger problem. So 446 00:26:56,860 --> 00:26:59,980 let's talk about detail in two different 447 00:27:00,140 --> 00:27:03,510 structures. There's the detail of number 448 00:27:03,750 --> 00:27:07,350 of tasks and then there's the detail within 449 00:27:07,350 --> 00:27:11,150 an atomic task. Those are sort of two levels of detail that you have 450 00:27:11,150 --> 00:27:14,150 to contemplate in this. So one of the biggest mistakes that we see 451 00:27:14,150 --> 00:27:17,990 MSPS make and we actually are head of operations 452 00:27:18,390 --> 00:27:21,190 who speaks a lot in the industry has a. I think he's got a webinar 453 00:27:21,190 --> 00:27:24,830 on it called the Project which is basically the entire project is one 454 00:27:24,830 --> 00:27:28,600 ticket. Like they're so used entering tickets and they just load the whole. This 455 00:27:28,600 --> 00:27:32,360 is clearly an insufficient level of detail for a large scale project and 456 00:27:32,360 --> 00:27:36,160 you're once again courting disaster by loading everything into 457 00:27:36,320 --> 00:27:39,960 a ticket. So there's the issue of what is the 458 00:27:39,960 --> 00:27:43,440 appropriate level of detail and you could do a whole 459 00:27:43,680 --> 00:27:47,320 session on what is the level. And people now could use 460 00:27:47,320 --> 00:27:50,440 ChatGPT to find out the appropriate level of detail for the number of tasks on 461 00:27:50,440 --> 00:27:53,960 stuff. So I don't need to cover that. But, but, but certainly more than 462 00:27:53,960 --> 00:27:56,880 one for a large project. And that's going to vary on the scale of the 463 00:27:56,880 --> 00:28:00,710 project, whether it's 20, 30, 50 or without. Like I said, we have, you know, 464 00:28:00,710 --> 00:28:04,510 customers that have over a thousand tasks, MSPs, you know, that do that for 465 00:28:04,510 --> 00:28:07,710 their customers. The second thing, so, so 466 00:28:08,750 --> 00:28:11,230 look and get some level of detail. But the second thing is what do you 467 00:28:11,230 --> 00:28:14,510 have to do on an individual task to execute function? 468 00:28:14,910 --> 00:28:18,190 And when we talk about sort of bare minimum, you need 469 00:28:18,510 --> 00:28:22,110 to know what the task is. I don't think anyone would debate, like you have 470 00:28:22,110 --> 00:28:25,760 to describe what that task is and have detail 471 00:28:25,760 --> 00:28:29,320 associated with that as a bare minimum, you have to 472 00:28:29,320 --> 00:28:33,040 assign that to a person. Like, you gotta do 473 00:28:33,040 --> 00:28:36,440 that, you gotta assign that to a person. And then for msps, because of their 474 00:28:36,440 --> 00:28:40,000 financial models and their budgeting, you have to put a work estimate on it. We 475 00:28:40,559 --> 00:28:44,240 think this atomic task configure 476 00:28:44,240 --> 00:28:47,720 this Device typically takes 22 minutes or 477 00:28:47,720 --> 00:28:50,600 typically takes an hour and a half. Whatever it is, you got to do those 478 00:28:50,600 --> 00:28:54,030 three things. And then to unlock 479 00:28:54,030 --> 00:28:57,790 automation and accuracy, you gotta have dependencies and 480 00:28:57,790 --> 00:29:01,110 durations. Like you gotta have those because if you don't, 481 00:29:02,550 --> 00:29:05,430 then you're gonna be in the blind, you're gonna be kind of blind again. You're, 482 00:29:05,430 --> 00:29:08,750 it's gonna be difficult. Now there's a lot of additional detail that you can add 483 00:29:08,750 --> 00:29:12,510 above and beyond that, right? A lot. But when, you know, 484 00:29:12,510 --> 00:29:16,070 when we try to coach organizations and go, hey, we know today, 485 00:29:17,040 --> 00:29:19,880 you know what the task is, you've already got that. You're doing that in your 486 00:29:19,880 --> 00:29:22,960 PSA and saying like, we got to do this. And you kind of know that 487 00:29:22,960 --> 00:29:26,720 list of things you should do. You know 488 00:29:26,720 --> 00:29:29,800 the resource type at least that you want to assign it to, if not the 489 00:29:29,800 --> 00:29:32,760 person, you know the resource type that you're going to assign it to and you 490 00:29:32,760 --> 00:29:35,840 roughly know how long it should take and if you get it wrong, 491 00:29:36,880 --> 00:29:40,600 you can update that. But once 492 00:29:40,600 --> 00:29:43,760 again, if you're willing to say, I mean, how long do we think we'll give 493 00:29:43,840 --> 00:29:47,500 someone to do this? Three days, four days, and what is it dependent on? 494 00:29:47,580 --> 00:29:51,340 You add those two things, you can unlock, once again, automated 495 00:29:51,340 --> 00:29:54,540 timelines process and updating, automating your 496 00:29:54,540 --> 00:29:57,740 timelines, because it's going to change statistically. You know, we talked about 497 00:29:58,140 --> 00:30:01,379 you're going to have problems and that means the project's got to be recast. And 498 00:30:01,379 --> 00:30:05,020 once again you want to be integrated with the psa because the minute you recast 499 00:30:05,020 --> 00:30:08,740 that, you want all your engineers tasks to get their 500 00:30:08,740 --> 00:30:12,330 dates updated automatically to go, hey, this is the new 501 00:30:12,330 --> 00:30:16,050 normal. Just quickly on this. This again 502 00:30:16,050 --> 00:30:19,450 calls forward. One of my favorite quotes on projects from Patton 503 00:30:19,610 --> 00:30:23,370 is planning is everything and plans are nothing. Yeah. Because 504 00:30:23,450 --> 00:30:26,450 the assumption is this is going to go sideways so you're going to have to 505 00:30:26,450 --> 00:30:30,130 replan as you're going. Right. I think to this, like don't meet, don't 506 00:30:30,130 --> 00:30:33,930 recognize this as resistance or a failure. This is, this is just how things 507 00:30:33,930 --> 00:30:37,330 go. Like you've got to be probability. That's the point. We, you know, come full 508 00:30:37,330 --> 00:30:40,340 circle. Like you said in the very beginning of the conversation, that's probability. So but 509 00:30:40,340 --> 00:30:44,060 this is what you want. You want AI and automation 510 00:30:44,060 --> 00:30:47,860 to recast that reintegrated and updated. You don't want. 511 00:30:47,940 --> 00:30:51,740 And this is why project plans are terrible because when people deal to try 512 00:30:51,740 --> 00:30:55,460 to manually do this, it's not possible. And so they get 513 00:30:55,460 --> 00:30:59,220 garbage dates and they're communicating garbage dates to their customers. So 514 00:30:59,220 --> 00:31:02,260 this is why, you know, what we're passionate about is to say, look, 515 00:31:02,740 --> 00:31:06,210 we statistically know that this is 100% chance your 516 00:31:06,690 --> 00:31:10,410 99.9999 chance you are going to have 517 00:31:10,410 --> 00:31:13,650 a problem. We talk about the portfolio of work. It is a 518 00:31:13,650 --> 00:31:17,090 septillion times more likely that the sun 519 00:31:17,170 --> 00:31:20,530 won't rise tomorrow morning then your project 520 00:31:20,530 --> 00:31:24,290 portfolio, if you have 20 of these 40 task projects is going to go off 521 00:31:24,290 --> 00:31:27,930 as planned. Like the odds are terrible. So what are you going to do? And 522 00:31:27,930 --> 00:31:31,370 that's where we step up. Like what do you plan to do about this? Hope 523 00:31:31,370 --> 00:31:34,850 that it doesn't happen. I mean, good luck with that. 524 00:31:35,250 --> 00:31:39,070 Yeah, let us know how your custom. Right. All right, so 525 00:31:39,390 --> 00:31:43,110 and this I think gets to, I think a really interesting space in this again 526 00:31:43,110 --> 00:31:46,550 like PM in general being somewhat 527 00:31:46,550 --> 00:31:50,190 underserved in our industry. And this is sort of an interesting 528 00:31:50,190 --> 00:31:53,830 segue because a big part of what you guys do and bring to 529 00:31:53,830 --> 00:31:57,430 MSPS is a level of AI and automation that is 530 00:31:57,430 --> 00:32:01,070 absolutely not available in other platforms. And I think it's 531 00:32:01,310 --> 00:32:04,750 the stuff that you guys add is super cool, especially because as you said, it's 532 00:32:04,750 --> 00:32:08,550 integrated, it's not a standalone platform. So the fact that you're, you're servicing the 533 00:32:08,550 --> 00:32:12,370 MSPS in this way is, is really interesting. That said, you 534 00:32:12,370 --> 00:32:15,690 know, we talked about this two years ago on, on a previous 535 00:32:15,690 --> 00:32:19,450 Episode two years ago in AI is a frigging lifetime. 536 00:32:19,450 --> 00:32:23,290 So I would be curious on what has changed with sort of the 537 00:32:23,290 --> 00:32:26,770 base capability of those platforms and you know, the back end 538 00:32:26,770 --> 00:32:30,570 mechanics of what you guys can bring to bear on projects. It must be somewhat 539 00:32:30,570 --> 00:32:34,410 radically different, I assume. Yeah, so, so I'll 540 00:32:34,410 --> 00:32:38,160 say this. So. So we rolled our own over a very 541 00:32:38,160 --> 00:32:41,920 long process using deterministic, symbolic 542 00:32:41,920 --> 00:32:45,640 and heuristic technologies. The new so 543 00:32:45,640 --> 00:32:49,000 and we also have other things where we use the latest gen AA stuff in 544 00:32:49,000 --> 00:32:51,839 hybrid fashion. Right. And so there are a couple of things that are really important 545 00:32:51,839 --> 00:32:55,480 about to know about this. So in our platform 546 00:32:55,480 --> 00:32:58,960 because it's deterministic in nature, it means it's repeatable, 547 00:32:58,960 --> 00:33:02,790 interpretable the results and why we got what we got. I think everybody 548 00:33:02,790 --> 00:33:06,270 now dealing with AI knows the idea of hallucination in the generative 549 00:33:06,670 --> 00:33:10,350 platforms and the probabilistic systems and you don't know why it's 550 00:33:10,350 --> 00:33:14,150 giving you the wrong answer. The thing that, that we know 551 00:33:14,150 --> 00:33:17,430 now is true because like, you know, obviously we went and certainly when 552 00:33:17,430 --> 00:33:20,990 ChatGPT came out we went oh gosh, is this going to be an existential risk 553 00:33:20,990 --> 00:33:23,470 to what we're doing? Are people just going to be able to throw garbage project 554 00:33:23,470 --> 00:33:27,190 plans or any project plan into an LLM and it's going to just tell 555 00:33:27,190 --> 00:33:30,890 you how to do everything and fix it? Right. And so we did research 556 00:33:31,050 --> 00:33:34,650 and fortunately through connections have access to people who are in research 557 00:33:34,730 --> 00:33:38,330 circles around this papers as recently 558 00:33:38,410 --> 00:33:41,810 as this year coming out of Harvard, Michigan State, Microsoft and 559 00:33:41,810 --> 00:33:44,810 Amazon, all of the LLMs. And this 560 00:33:45,290 --> 00:33:49,130 linearly probabilistic generative AI solutions are terrible with 561 00:33:49,130 --> 00:33:52,690 graph data. So and what I want to, I just want to sort of unpack 562 00:33:52,690 --> 00:33:56,100 when we talk about error rates around a solution. 563 00:33:56,500 --> 00:34:00,300 So for scheduling a project like hey, I 564 00:34:00,300 --> 00:34:03,900 want to schedule, we talk about what's an acceptable error rate. We have different error 565 00:34:03,900 --> 00:34:07,540 rates for that we as a consumer will accept 566 00:34:08,660 --> 00:34:12,380 around the task of automations and those can get expressed 567 00:34:12,380 --> 00:34:16,180 of acceptability of percentage rates of like a less than a 568 00:34:16,180 --> 00:34:19,660 half percent, 10%, 5%. You know, if you're 569 00:34:19,660 --> 00:34:23,100 writing a poem for one of your kids or whatever, like an error rate of 570 00:34:23,100 --> 00:34:26,700 not quite even getting. You don't care about, about that. Right. But if you're saying 571 00:34:26,700 --> 00:34:29,980 what's the error rate of my parachute opening? You're going to want that to be 572 00:34:29,980 --> 00:34:33,540 less than, you know, 100th of a percent or a thousandth of a percent chance 573 00:34:33,540 --> 00:34:37,300 that your parachute and that might even be high for the number of people go 574 00:34:37,300 --> 00:34:40,620 Skydiving, less than a half a percent would be 575 00:34:42,060 --> 00:34:45,820 range or quarter. What would be expected for automating 576 00:34:46,460 --> 00:34:50,300 project scheduling? Like getting that out and saying, oh, this is when this project's going 577 00:34:50,300 --> 00:34:53,350 to be due. This is what, here's your scheduling problem, 578 00:34:53,830 --> 00:34:57,510 here's your conflict, here's your resource issue. Right 579 00:34:57,510 --> 00:35:00,870 now, the error rates for teeny tiny graphs and 580 00:35:00,870 --> 00:35:04,390 projects, but is 40%. It is so 581 00:35:04,550 --> 00:35:08,350 extraordinarily high as to not even consider and there's 582 00:35:08,350 --> 00:35:11,990 no improvement. So these models, if you look at the 583 00:35:12,790 --> 00:35:16,630 drop in error rates for the models on on language 584 00:35:17,870 --> 00:35:21,070 in 2D and 3D vision, those error rates drop 585 00:35:21,070 --> 00:35:23,950 significantly because of the nature of what they're doing 586 00:35:23,950 --> 00:35:27,750 generatively. So I'm generating text and a 587 00:35:27,750 --> 00:35:31,070 letter for you, or a business plan, or I'm generating an image. 588 00:35:31,390 --> 00:35:34,750 That generative process, they've really been able to drop it. 589 00:35:35,310 --> 00:35:39,150 But the idea of observing a living dynamic system that is in a graph, 590 00:35:39,470 --> 00:35:43,090 it gets lost. It can't relate beyond its nearest neighborhood, 591 00:35:43,400 --> 00:35:46,520 it gets confused. And because it can't traverse a tree 592 00:35:47,000 --> 00:35:50,520 in a depth first search or breadth first search, 593 00:35:51,240 --> 00:35:54,760 it falls apart and gives bad data. And unfortunately, 594 00:35:55,240 --> 00:35:58,800 like some of the things we talked about before, you get one bad answer in 595 00:35:58,800 --> 00:36:02,280 that graph and that cascades because it's all connected. 596 00:36:02,440 --> 00:36:04,280 So, you know, we look at this and go, 597 00:36:06,040 --> 00:36:09,810 any of you hoping that you're just going to be able to plug your crappy 598 00:36:09,810 --> 00:36:13,530 management into an LLM and get the solve? And you're just waiting for 599 00:36:13,530 --> 00:36:15,410 that because it's AI and it gets better. 600 00:36:17,090 --> 00:36:20,930 There's no line of sight of that and there's no papers. So ChatGPT 601 00:36:21,010 --> 00:36:24,210 came out and it was amazing. I think 22 is when we started to go, 602 00:36:24,210 --> 00:36:27,170 wow, that's really something. I think that paper came out in 18. 603 00:36:28,290 --> 00:36:31,890 And certainly things move quickly and we can say things happen overnight, 604 00:36:31,890 --> 00:36:35,730 but there was line of sight. And we did know back when that paper 605 00:36:35,730 --> 00:36:39,220 came out that, oh my God, we can parallelize this computer. 606 00:36:39,690 --> 00:36:43,130 We just need to get more compute and more data. They, they weren't 607 00:36:43,130 --> 00:36:46,450 surprised when they were going down that path. They knew they were going to get 608 00:36:46,450 --> 00:36:49,650 better results. They knew those error rates were going to drop, which is why all 609 00:36:49,650 --> 00:36:52,850 that money flowed into it and why there was a hype cycle. And we as 610 00:36:52,850 --> 00:36:56,450 consumers saw the benefit and we're like, oh my gosh, this is 611 00:36:56,450 --> 00:37:00,130 amazing. Once that error rate dropped to a point where we trusted it once 612 00:37:00,130 --> 00:37:03,770 again, they're nowhere near that for managing projects. And 613 00:37:03,770 --> 00:37:07,540 so we look at this and go, you got 614 00:37:07,540 --> 00:37:11,340 to use traditional you need to have an expert system in place, deterministic. You can 615 00:37:11,340 --> 00:37:14,980 layer, we have customers that layer other AI stuff on top of our data because 616 00:37:15,060 --> 00:37:18,860 they're operating off of a foundation of accurate data. Like they're taking the 617 00:37:18,860 --> 00:37:22,420 guesswork and the hallucination work out of it. And then they're going, okay, 618 00:37:22,420 --> 00:37:26,260 summarize this. Yeah, this is interesting because, like, I play with 619 00:37:26,260 --> 00:37:29,980 enough AI that I recognize what you're talking about in the boundaries of this. Right? 620 00:37:29,980 --> 00:37:33,670 So I think a lot of people saw 621 00:37:33,750 --> 00:37:37,470 early on hallucinations where you would ask an AI about something and it would 622 00:37:37,470 --> 00:37:41,310 just completely falsify something. You can tell it's, it's, it's not 623 00:37:41,310 --> 00:37:45,030 even remotely true. My brother had a great example of this. He asked 624 00:37:45,910 --> 00:37:49,430 GPT a long time ago, like, who was, who is the, who ran 625 00:37:49,430 --> 00:37:52,990 his company, and it responded with a real person that had 626 00:37:52,990 --> 00:37:56,470 nothing to do with his company. I'm not the CEO of my own company. 627 00:37:56,470 --> 00:37:59,940 Interesting. Okay. But that was the early 628 00:37:59,940 --> 00:38:02,980 versions of this. And it seemed like a lot of that got solved because 629 00:38:02,980 --> 00:38:06,540 hallucinations dropped precipitously. But I 630 00:38:06,540 --> 00:38:10,220 still regularly see situations where, like, it has no idea what 631 00:38:10,220 --> 00:38:14,060 it's talking about, even in basic math, right to the point where it is trying 632 00:38:14,060 --> 00:38:17,660 to generate the next token. And unless it's, you're asking it to solve a 633 00:38:17,660 --> 00:38:21,300 particular math problem, it can get some of this stuff absolutely wrong, which is 634 00:38:21,300 --> 00:38:24,620 weird. And the other part that I see this show up and is, and probably 635 00:38:24,620 --> 00:38:27,980 relates a lot to projects is I am 636 00:38:27,980 --> 00:38:31,660 regularly fascinated by the fact that GPT has no idea what day it 637 00:38:31,660 --> 00:38:34,900 is even when I tell it, you know, and then I'll, I'll say the data 638 00:38:34,900 --> 00:38:38,580 is this, blah, blah, blah. And then we'll go through like not a huge context 639 00:38:38,580 --> 00:38:42,100 window and I'll, I'll try to ask it to plan for something else. And it 640 00:38:42,100 --> 00:38:45,740 completely misses the mark. Like it's like it's April 2023. You're like, 641 00:38:45,740 --> 00:38:49,460 what? No, where are you? Right, yeah, well, and you just 642 00:38:49,460 --> 00:38:52,690 hit on another really key point of why it's limited in projects. 643 00:38:53,160 --> 00:38:56,680 Right. Is this the larger. The context window, that 644 00:38:56,840 --> 00:39:00,560 performance rate decays in a non linear fashion, so it 645 00:39:00,560 --> 00:39:04,040 can perform really well with a paragraph or two of data. Goes off a cliff. 646 00:39:04,440 --> 00:39:08,280 Any large project plan blows up context windows. And 647 00:39:08,280 --> 00:39:12,080 so like I said, it's just, there's no line of sight that, that's gonna, you 648 00:39:12,080 --> 00:39:15,080 know, I think this idea of, oh, they'll figure it out, they'll figure it out. 649 00:39:15,080 --> 00:39:18,880 You know, like the figuring out is A hybrid solution. Like you're. And 650 00:39:18,880 --> 00:39:22,730 it is doable in a hybrid solution today, right? I mean that's, 651 00:39:22,730 --> 00:39:25,370 that's the big question. But you're spot on in saying like, 652 00:39:26,250 --> 00:39:29,530 and projects have a lot of data right? There is at the end of the 653 00:39:29,530 --> 00:39:32,650 day, a lot of data. When you're talking about what are the engineers on. Even 654 00:39:32,650 --> 00:39:35,890 on a smaller project that has 15 tests, well, who's working it, what are their 655 00:39:35,890 --> 00:39:38,410 schedules and what are their resources and what are their skills and what's the time 656 00:39:38,410 --> 00:39:42,170 like? Once you get to that level, it blows up. 657 00:39:42,170 --> 00:39:45,570 It might be able to generate a plan, but it can't observe it, monitor it, 658 00:39:45,570 --> 00:39:48,840 identify risks and problems. And, and that's, 659 00:39:49,080 --> 00:39:52,880 that's the issue right now that these MSPs face is, as you said, your 660 00:39:52,880 --> 00:39:56,720 patent quote, like, oh, we had it to start. Why did it blow up? Well, 661 00:39:56,720 --> 00:40:00,480 it was doomed to have problems. You didn't know that because humans suck 662 00:40:00,480 --> 00:40:03,640 at probability. But it was doomed to have problems. 663 00:40:04,280 --> 00:40:08,040 You just didn't put an early warning system in place through best practice, 664 00:40:08,120 --> 00:40:11,640 process structure and technology so that when that inevitably 665 00:40:11,640 --> 00:40:15,410 happened, you could adapt to it and adjust. You're doing that with your 666 00:40:15,410 --> 00:40:19,130 endpoints. You pivoted from being a break fixed MSP 667 00:40:19,770 --> 00:40:23,570 to a managed service provider that's actually observing through your 668 00:40:23,570 --> 00:40:27,290 noc. You got to kind of build a NOC for your projects. 669 00:40:27,530 --> 00:40:31,250 Yeah, yeah. I mean, I guess that's the project, right? Start, 670 00:40:31,250 --> 00:40:34,850 start working on, on these iterative improvements, get the basic 671 00:40:34,850 --> 00:40:38,570 mechanics in place, start working on resourcing dependencies, time 672 00:40:38,570 --> 00:40:42,250 windows, and then start to pick up steam from there. 673 00:40:42,250 --> 00:40:46,050 So really appreciate this, Mike. Thank you so much. If people 674 00:40:46,050 --> 00:40:48,610 want to get in touch with you or your team, what's the best place for 675 00:40:48,610 --> 00:40:52,130 them to check.com M. O O V as in 676 00:40:52,130 --> 00:40:55,930 Victor I L A dot com. Yeah. And we'll be at, we go to 677 00:40:55,930 --> 00:40:58,890 a lot of shows during the course of the year, so hope to see you, 678 00:40:58,890 --> 00:41:02,650 Todd, or other folks if possible, at those shows. And thanks 679 00:41:02,650 --> 00:41:06,490 everyone for taking some time to talk about projects because I know both 680 00:41:06,490 --> 00:41:10,090 you and I are interested. Yeah, yeah, we're pretty passionate about it, but, 681 00:41:11,110 --> 00:41:14,590 but glad for anyone who's also expressing interest and happy to answer any 682 00:41:14,590 --> 00:41:18,150 additional questions. Awesome. Appreciate it, Mike. Thanks so much.