ERP104 - Advanced project management

I think there's sort of desires and wishes for the industry, but I think the practical thing for these organizations to look at is they're going to have, you know, I like the term citizen project managers or accidental project managers. For a lot of these organizations, they typically aren't going to have the luxury of having a PMO with a bunch of certified PMs in that process and that they're going to have to have engineers and other folks that they can elevate. And, you know, that was one of the things that we saw as a big need in this industry was to sort of elevate the capabilities of the average person so they could operate like a PM. Welcome to Evolved Radio, where we explore the evolution of business and technology. I'm your host, Todd Kane. This episode is brought to you by Evolved Management training courses, a whole series of courses built specifically for your MSP training needs. There's a project management for MSP's course, an MSP service manager boot camp, MSP security fundamentals, and an IT documentation done right course. Check out the full suite of courses at training.evolvedmgmt.com or look for a link in the show notes. Welcome to another episode of the Evolved Radio podcast. In today's episode, I'm joined by Mike Senka, CEO and founder of Movilla to delve into the world of project management, in particular in the managed service space. If you've ever wondered why projects just can't seem to be delivered on time and how you can make your project delivery process better, you're going to love this one. We discuss the importance of understanding dependencies, critical path, and how technology can streamline the project management process. Mike also shares his insights on APMM, which is autonomous project monitoring and management and its innovative features. Whether you work in a smaller MSP or a larger organization with a PMO, there's valuable advice here for all. So join us as we explore the secret strategies and challenges of managing projects in an ever evolving world of IT. Let's get started. Mike, welcome to the Evolved Radio podcast. Thanks for having me. So, this is a topic that I I love, going to get into some some juicy details, I'm sure here. Uh today we're talking project management and especially project management in the MSP space. A bit of background just to kick off. I know you're extremely passionate about this space like I am, so how did you get so passionate about project, Mike? Yeah, well, I I I think that the thing that really kind of got me interested was, you know, God, maybe even starting this journey over a decade ago was. Why still you know, project management is a really mature thing, it's been around a really long time and the product category's been around a long time. Why is it that in any industry people still get surprised by delays, project problems and issues? And that sort of fascinated me to say, well, what's at the root, there's got to be a root cause that we're just kind of getting wrong. And there were a couple things that came up. One of those was a statistical issue that a lot of people hear me talk about, like the birthday paradox, right? You have 20. You know, people suck at probability. If you have 23 people in a room, there's a 50% chance that two of those people share the same birthday, or two people in the room share the same birthday. And that just doesn't make sense to people. But it's the truth, it doesn't matter if it makes sense or not, it's the truth. And that same thing that we realized that same statistical problem occurred in projects and work. Right? You have a very big project plan. Your team gets the work done 90% of the time, you have 50 tasks in the critical path. There's only a half a percent chance you're going to get that project done without having to crash it. And that was like an epiphany. To go, oh my God. Nobody realizes the math gods are against you in every project. How do we solve this problem, how do you we give people a fighting chance? And, you know, they ultimately at the end of the day was just about getting more time. Trying to get people more time to solve those problems. And with enough time we can solve most problems. It's just sort of sucks when you find out like the day before a due date that, oh my God, you're going to be two months late. And then the customer's like, hey, I kind of feel like you should have known this. So. The the math part of it and the stats and the probability thing got me excited because there was just sort of no awareness around this problem. I think today still, you know, I proze this a lot, but I think people in general don't realize how much the odds are against them, Todd. The other part of it was the solution was just automation. There's so many variables, so many factors associated with this that really the only way to solve this was to sort of augment the human experience. With automation so they could focus on qualitative things and not get burned. Right, not have the unpleasant surprises. So, I'd say those two factors were the things that we saw. Wow, no one's really doing this and these are two really big underlying causes of. Headaches, problems and unpleasant surprises. The stats you noted on just like projects are very likely to go wrong. I think that's a really great place to start from is the expectation that things are going to go right when you spin up a project. Especially, like if we consider the general level of project management maturity in the IT space is pretty low. But like I saw some really horrible stats that said, like globally on IT. So we're talking like ERP implementation, software development. I think it's something to relative to like 11% of projects in the IT space are actually on time and on budget. Which is a really damning stat. Right, like we're just not good at this. Because generally what we do is complex. But it's also sort of buffeted by that idea of, I mean, we're not building hospitals and bridges. And no one's reasonably going to die if our projects don't go well. But you're very likely to start losing clients if you don't do it. Uh so I think that that's where it gets to the space of like the general project maturity is is is kind of low across the board. And I suppose both of us are a bit on on a mission to help people come up at least to sort of that baseline level of maturity, right? Agreed. And I think the one thing that, you know, we were at IT Nation last week and and one of the partners came up to us and said, look, like that's how we kick off our relationship with most customers as a project. It's the handshake. And we're dropping the ball on that handshake, it's not setting a good precedent for us that we're not managing the expectation and the confidence level if we don't manage those very first projects well. So. You know, I think there's a hunger, you know, I agree with you about your assessment of that maturity level, but there seems to be a much greater interest now in the market for people to kind of up their capabilities and their competency levels. Okay. So there's a couple of things that I think are really, really crucial here. Like just kind of helping people on what should they be considering in order to increase their their baseline level of maturity. And I think like like like I noted, being a bit pragmatic and proactive about the planning around projects, I think is really crucial. And this is a step that unfortunately just gets skipped past. There's there's sort of a lack of planning and a lack of time spent to spin up a project well, people just sort of throw themselves into it, apply some resources and, you know, we'll figure this out as we go. I mean, that if projects are complex enough to begin with, that's going to be sort of a bad outcome. So I think that planning piece. And then the other part is just bad data. Like bad data management. The ticket data, we're getting a little better at cleaning up. But visibility around projects, tasks, completion dates, resources applied, how long this stuff is going to take, a lot of that stuff either doesn't exist or is, you know, highly error prone. And I think that doesn't help people again to sort of structure themselves for success to to wade well into the project management territory, right? Yeah. I agree with what you're saying completely and I think one of the bigger issues around this is that all of that bad data. Ends up contaminating so many other critical information silos and pipelines that exist in their business, right? You have bad project data, you have bad project dates in that process, that ends up contaminating your scheduling, your communication to your customers, you're giving them bad dates. That flows into your profitability analysis, your resource utilization, your capacity, your hiring forecast. All those things get poisoned when you have bad project data. But. I guess rewinding a little to what you said earlier, the industry does is is much more mature around ticket data. Right? They've got that button up. And those tickets are singletons, they're in many cases are not relationships. Projects plans are structured entities, kind of these living beings that change and move as they go forward. They have a lot of different stakeholders that are involved and because of that, that data can get damaged very quickly. And if it's not structured or automated, it can become a big problem quickly, like I said. I think but. I think there is a a growing level of awareness that in the industry that, hey, you're right. Our project data is bad and it's it's at the root of a lot of the problems that we have. Yeah, it's interesting, I often quote this client that I worked with way back in the day. And we were we were noting sort of the lower level of maturity of their their project delivery. And he said, Todd, honestly, projects are just a means to an end so I can get people to renew their MSA. And I think that like not that that's sort of something that everyone would vocalize. But I think it's actually kind of a common approach to this. Is like. Like MSPs unfortunately tend to view projects as a bit of a a second class citizen from maybe from a revenue standpoint and from a time and attention standpoint. The help desk is is so all consuming. It's like, well, you know, I'll get to projects when I have time. And that's, you know, such a fallacy, like you you don't find time in IT. But I I think, you know, you're missing a massive opportunity because a lot of the things that we do from a support perspective. There should be good margin on top. But, you know, that's predictable, it's it's sort of ops, it keeps the lights on. And you should be like really popping your margins by good project delivery with, you know, scalable approaches, good margins built in, predictable resourcing, all of those things. Like you should be able to create a lot more margin for your organization if you're running projects well. And I think that's a sort of a missed opportunity not only for for revenue, because there's some revenue applied there, but generally for good margin. Because if we're able to do these things on on time on budget, then there's a lot more margin available in projects if they're run well, right? Yeah. And the finance components of it are obviously critical to the MSPs. But they are an opportunity for keystone moments in the relationship and building trust. When those projects don't occur, the service can become much more of a commodity. Because there's less FaceTime, honestly, with your organization and what you're doing. But these projects and a lot of these projects and process engage FaceTime and engagement. At the end of the day, this is a relationship business. It is about building trust. And so. Thinking of the project as a secondary thing is a dangerous move. You know, we saw several people at Next Gen and IT Nation and had a lot of people coming up saying, hey, this is important to me, I lost my second biggest customer, I lost my biggest customer because of a failed project. Where they were lax days ago about the project and then their customer came and said, hey, I'm canceling. And they, oh my God, someone we thought would never cancel a million years, ran over there, talked to him. And they said, well, you know, you guys came in around and this was maybe they said they canceled around April, they said, oh, you guys came in running a project for us, November, December and it kind of just kind of schmoozed. And nothing really happened and you didn't communicate with us and it just kind of languished. And that was enough for me. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. So. You know, we've we've spent the last three months finding a new MSP and so I'm just telling you we found them. And they lost their biggest customer. And I said, I heard two other similar, actually two other similar stories to that. So. As you said, neglecting the project can become a very perilous thing, especially with your largest customers. Because. Your ability to execute well on a project builds a level of confidence and trust in relationship with those partners. Yeah, I strongly agree. I've I've started to see this more than I have historically, right? Like you're. Your anecdote about people losing clients on projects is the same thing that I'm seeing. And, you know, traditionally we would see IT service companies lose clients based on service delivery or account management. And project delivery was not necessarily one of the areas that tended to come up. But that's actually what I'm seeing more and more. And you're right, like the commoditization of the support services, like I expect you to be able to close my tickets. Like that's that's a basic expectation. Protect my data, support my users and keep the the bad guys out of my environment. Those are basic expectations. And, you know, how do you differentiate if you're not actually able to deliver well on projects? And. As you noted, I think probably the biggest piece of this is simply communication. Like it's incredible that like how complicated the things that we do. But and those things are generally kind of fine, it's not like you totally screwed up a project and broke a bunch of things and that's why they're they're upset. It's that like you said, like the the customer was in the dark. It's like, is this project or done? Like, like. Uh and the response often from the text is, well, I didn't have anything to say to them or, you know, there's nothing to update. It's like, well, that is an update. Right? Like you need to follow up with these people and give them some visibility to what is being done or not being done. So I think that that communication piece is is absolutely crucial. I'm sure you'd agree on communication A being a lack in part, but, you know, certainly one of those areas that people need to be better at. Yeah. No, no, there's there's no question. And. Once again, you're setting expectation with those communications. Right? You're building trust and setting setting expectations. I I I think, you know, going back to the first part of what we were talking about and saying, look. At the end of the day, you know you're going to have problems in this project. That is a certainty that that's going to occur. And so. If you know that ahead of time, if you're communicating early to a customer, they're going to understand, hey, in two months, we think we're going to have a delay or a month we're going to have a delay because of these reasons, they appreciate that early foresight. And. And our experience. And. And the people we've talked to. Generally. When people are informed early and often and accurately, that trust is there even if things go sideways. It's the. Well, wait a minute. I feel like you should have known this. Why are you just telling me this now? And it's that unpleasant surprise that damages trust. And they go, well. If you're dropping the ball on this project. Do I am I sure? That you've got all my end points covered. Like what else? What else might we be missing here that it undermines that level of trust? And the security that's so essential, I think in this industry. Yeah, I really agree. Yeah. It's and you're right, like like trust is built by relationship. You noted sort of the importance of that relationship muscle, which is is facilitated by communication. So. I guess, you know, the sort of the getting people up to sort of that base level is spend more time on project organization and planning. And then spend more time on communication, like those two things, like it'll get you 50% of the way there, right? That'd be really crucial. Anything else like maybe you would add as as sort of those base level things that that like someone who is like, uh, projects are a bit of a mess, like what should I focus on just the the real basic mechanics aside from those two? Anything? Well, so I I I think, you know, if you were to talk about a traditional pragmatic thing, it is all about dependencies. Like understanding dependencies in that process and that structure. And ideally you have a technology that will accommodate smooth and fluent assignment of dependencies and process. And the reason why I say that. You know. And some of the audience may be well versed in the world of project management. There's something called the critical path in a project. And the the critical path is sort of that minimum time required to complete that project. And that can change in your network diagram of all the tasks that you have to execute on. And. What ends up happening is when people aren't aware of what that critical path is, they become unaware of when something isn't getting done. On time, will it really introduce a delay in this project and ultimate delivery? So. You know, we think about it, like there are things like, hey. How long do we think this is going to take and what's it dependent on? Those are a couple of really simple things that are often neglected. But putting those two pieces of information, if the technology can accommodate some automated structure around it, you can start accurately forecasting. And understanding where your problems and challenges are. The other footnote to that, which is interesting. And I think a lot of people realize is in many cases. The customer is the reason why there's a critical path delay. And as as providers or as vendors, you know, as an MSP if you're delivering that. You don't want to tell the king or queen that the prince is the problem. I E, hey, your IT department or this person didn't give us this thing, they're 14 days late. And you're like, well, we don't want to upset anyone. We know, hey, they're a little late on this. But if if you set those dependencies and you know how long it's going to take in general for the other tasks, the durations, you can quickly, pretty quickly understand. That that two week delay is actually going to delay the whole project two weeks. People don't have that sense, they're like, oh, we'll make up for it. No, you won't. You won't because you budgeted everything else pretty tightly, you didn't budget this project to lose money. And this 14 days are going to keep someone on the beach that you thought was going to be working that you could have redeployed. So. Once again, this idea of, hey. How long do we think this is going to take? We're going to, you know. Two hours of work, we'll give him a week to do it. It's going to take two hours. But it's dependent on this. Hey, and what's dependent on that thing? You do those that you know, that changing of logic, you don't have to be a PMP, you don't have to be a big project manager to define those things. But if you could do that. And there's automation in place. All of a sudden, you can start accurately predicting timelines and communicating accurately to customers and other stakeholders. Okay. I like this uh the simple way that I sort of help people understand the importance of dependencies in projects is. The longest bit of work that you have, if you double it, is the risk of delay in the project. And time and time again, I see people that assign a particular project ticket or something like that. And it's scheduled like over a course of a week or sometimes even two weeks. And the intent is is like, get it done within this period of time. When really they should be like collapsing that to you get it done. Probably on this day, if not like in this four hour block. Like that's a much more predictable way to do this. Because. If you get to the end of that week or two week period and that hasn't been accomplished for some reason because you didn't check in, there was low communication. You're now at least two weeks and if it's a two, you know, two weeks or a month behind as a result of the scheduling and misfire of the delivery of that that uh bit of work, right? So. You're right, like the understanding sort of the dependency chain and how that can impact your your total delivery time is really, really crucial. What other piece you mentioned here? I think is important for people to understand is. We're not talking about people that are a PMP. If you have a PMP and you're you're delivering projects in MSP, fantastic. Like you're very, very well trained. But. I have a project management course and a lot of this I sort of like suggest is the boiled down PMP. Because as I said, we're not building hospitals or bridges. We're installing servers. But. The fundamentals of that that project management training still applies. I think people get wrong like the complexity and what's required for good project, good enough project management, I would say in in an MSP. So. Like, what do you see, do you have a I have some thoughts on this, but I want to get your opinion on on again, an owner of an MSP, he's sort of been doing projects off the side of his desk. Like, who should that owner, he or she should think about applying as their first PMP that or the first PM that they want to stand up in their organization? How would how should they think about approaching that? Yeah. So. I think the thing that, you know, I think there's sort of desires and wishes for the industry, but I think the practical thing for these organizations to look at is they're going to have. You know, I like the term citizen project managers or accidental project managers. For a lot of these organizations. They typically aren't going to have the luxury of having a PMO with a bunch of certified PMs in that process and that they're going to have to have engineers and other folks that they can elevate. And. You know. That was one of the things that we saw as a big need in this industry was to sort of elevate the capabilities. Of the average person so they could operate like a PM. Because, you know, we've talked to other. You know. We've talked to some very large MSPs and MSPs that have said, look. You know. The reality is, we need the engineers to have these PM capabilities through training, through technology. Right? We've got to get them leveled up a little because we need them to be able to execute. And we also need our PMs to operate at a higher, more efficient level, even if we have those PMs. So. At the end of the day. I would say if you in your organization. Have someone who has a little bandwidth, getting them trained around some project with courses like yours. Getting them trained around those basics so they can bring that and kind of train the trainer. Right? They can bring that knowledge and information. That's for the smaller MSPs that might not have a PMO, getting at least one of their engineers trained up on that. Or the owner trained up on that. Because the things that you're asking the people who are going to be executing on their projects to do, it's not that tough. Yeah. You have, like I said, a couple of people in the organization who understand those basics. They don't have to go through pert analysis and, you know, they don't have to go through all the massive details of it. You know, as you said. There's sort of a bare minimum they can execute on. Larger organizations that have the PMOs, it is about efficiency on that and and automation, honestly, to solve their problems. Because. The data volume that they're dealing with and how dynamic that data is, it's just not possible for a human being to keep up with it. Yeah. It's just. And that's why they kind of get underwater and they spend all their days doing date and calendar math. And not sort of solving customer problems. Totally. Yeah. I strongly agree. Like there's that Delta kind of between the the complex project or, you know, sort of program management, portfolio management. Where you're managing, you know, upwards of 50 or 70 projects. And you've got a couple of PMs underneath you. The requirements there are very, very different. But. You know, I think a lot of people sort of start with that in mind of like, oh my God, like all this is going to be very complicated. When really like at first we're we're talking about like maybe five. Upward to 10 projects in flight. And honestly, what I often tell people is. Like first and foremost, like if you if you do anything around project management in your MSP, don't let the text manage their own project. Like that's first and foremost. Right? Because there's a strange sort of psychological influence that we can create on ourselves of justifying things that we will do or haven't done. Right? And it's it's not from a sort of a a mal intent place. It's just it's that psychological tricks that we can play on ourselves of justifying how we're approaching something. It really helps to have that secondary accountability. If it's the owner. If it's, you know, just an admin in the office, like it like if you're following these processes. It's not a high degree of complexity, so much of this is just like like uh being detailed. And keeping good notes, holding people accountable and communicating, right? Like anybody can do that reasonably. Right? So I think the bar is actually a lot lower than people think to just sort of throw someone into the PM territory. And give them enough training and framework to be able to to to lift off of that. Now. Getting to sort of that secondary space of like, okay, now there's tons of projects in flight and, you know, I've got a couple of decent PMs. But we need to actually organize. More of a PMO structure. We need to understand resource balancing, all of the sort of more complicated resource impacts. You know, project drift, a lot of these things that start to get a lot more almost math-like in in scheduling and stuff. And you guys have a a really cool solution around this and just start implying sort of data analysis. Some machine learning around its capabilities. Two things that I really, really like was was blown away by you guys having the platform is the risk indicator. Where it's kind of figuring out like what's the level of risk in these projects. And I think that as an independent judgment of just here's what I see in the data. I think this this project is at risk. And that the system determining that, I think is a really cool aspect. And then the other one, I know you're quite passionate about the sort of what you guys refer to as the APMM for projects. And it's sort of like an RMM for projects. So. You know, I'll give you a chance to just sort of give us a a bit of a window on those capabilities in your system. Yeah. Yeah. Absolutely. Thank you. Yeah. And I guess I'll I'll start with the latter one. APMM autonomous project monitoring and management. It is that idea that it's like RMM for your projects. Right? I mean. If you think about what RMM does. Right? It allows a much broader span of control for the engineers. It identifies problems earlier. So you could address those problems at a lower cost kind of way. And it observes and monitors 24/7 with objective measures, right? Things you can trust. Like when those things pop. At end points and process, you're alerted to those, you address those issues and you move and you manage those quickly. And APMM. This autonomous monitoring of your project portfolio does the same thing. It's observing those projects 24/7, identifying where objective risks are arising in those projects and plans, even if no one's touching the project plan. So an owner or a PM or a program manager can look and identify where those risks occur. And that second, that first thing that you said, the what we call the R pack score, which is a robotic project assessment index. It's sort of like a credit score for the project. And it's a zero to 1,000 score, it's an objective measure that looks at several dozen factors around project structure, defects, best practice, how that gets deployed, delays, capacity, resource utilization. All of these factors and boils it into a number. And if you look at that number and it's color coded as well. If you look at that number and you see a high number, you can be confident that the plan was structured well. And by the way, a completely separate conversation is the vast majority of project plans are not structured well, unfortunately. Agreed. Not predictable. But. If the number's low, and it would let you know that it's on time. But if the number's low, you immediately go, uh oh. Either we got a plan that was built poorly. Which I don't think we want to be cool with. We don't want bad plans, especially when it's easy to fix those. With a technology like APMM. Or it means there's a critical path delay. And if it's a valuable project, you can communicate that to the customer. It also means you could have resource or capacity problems on that project. Which you're going to want to find early so you can redeploy people and eliminate those risks. So. Once again, finding out about those things early is critical to people. Now. Within inside the APMM structure and that score, the next level is we have something called. And. And this this part goes to. And backing up a little when you were talking about, hey, what can what can MSPs do? The reality is, it's hard to level up PM capabilities quickly. One of the things we're really proud of and that our customers get a lot of value in is within our project management functionality. We have the world's first debugger. So. Most people out there probably have done some level of programming or may have done some level of programming or understand what it is. There isn't a programmer in the world that could write code without a debugger. It's just not possible. They all make mistakes. You depend on it. I got news for you, there isn't a PM in the world that builds project plans, especially large ones in a portfolio where they haven't made mistakes. And those mistakes are preventable. And curable and so this debugger does that, identifies and let you drill in. Just like a code debugger with a very graphical UI. And then lastly. There's an AI agent called Carmen that will guide people like in a wizard, you know, almost like a turbo tax wizard. This is how you fix this. This is how you fix this. And it kind of guides them through in a click way where they can fix and remediate. So it allows a really inexperienced or a non PM to operate. Much more like a very experienced PM so they can kind of trust their data. So yeah, we're super excited about bringing that APMM technology into the marketplace because it solves a lot of the pain points. That MSPs have around, hey, we don't have the time to mess around with all this stuff. Can't you guys, you know. And that sort of, hey, just automate, automate all these painful math dependency, just can you automate all that stuff for me? So when I look at this, I you know, can click a couple buttons and recast the project quickly. Um. You know, things like that are really important. Having interfaces by the way with this technology to the major platforms and players is essential because they don't want to do double entry. Right? They want to be able to go in, look at it and go. Update everything. You know, with one click and and that saves. Enormous amounts of time for these guys. Yeah, and I think that that piece is really crucial for me. Right? Like that's what I what I saw you guys's solution is like why I got kind of excited about this. Is because I rant a lot about like don't use third party tools to manage projects. And I'll be the first to state, like I understand the draw to that. Right? Because the project modules in most of the PSAs are are underwhelming, right? They they're functional, but they're they're really rudimentary. There's some improvements. There's some improvements slowly being made to them, but I really love the fact that you guys do a two-way sync. Right? And that is the distinction that I think is really important here. Is if you go. And start using like Monday or Asana or something like that, like you're in a totally different silo and now your data is removed. You're doing double entry for time. Like it's it ends up being a total nightmare. And generally doesn't improve sort of the the uh the actual process or delivery for a lot of MSPs. It just over complicates things. So I like the fact that you guys are kind of applying a much more sort of usable and mature skin on top of the existing infrastructure. And allowing that two-way sync. With that. One thing. One thing I would ask is is just so people are aware of like, okay, so I haven't managed projects that well, my data probably is pretty dirty. Like am I going to get the value? That I would that I that I I think I or hope I could from having Movella added on top of this, is there sort of a baseline that needs to be uh there bring their PSA up to and and sort of clean things up in order to be able to draw on those functions? No, so that that's a great question. I think once the interface is up and the sync occurs, all of that data comes into the platform. And that AI agent that I was telling you about before will guide them through the remediation process. So. There is sort of step-by-step guided remediation to let them know, you need to do this, you need to do this. And that's a pretty easy process for them to click, fill out. And when they're entering the data, it's like they're entering it into a spreadsheet. It's super simple for them to get those things up to snuff. For a lot of customers as well, the other component of it is templating. So there's a lot of template automation in the platform as well if they have a standard server setup or firewall replacement. They can set those things up very easily and instantiate it when they have a new project. Or they have to spin that up. They just click a button. The project gets invoked, they know the resources they have to track and manage on it. And now they're off to the races with kind of that automated management. So. That's another there's a lot of repeat work. That MSPs do and that sort of automation around the templates and the process and feeding it into the systems. Is another just kind of big time saver. The last little part of it is. You know, our background was business intelligence and analytics. And like I said. For a separate conversation. There is so much critical data about process improvement and margin optimization that exists once you do begin structuring these templates and the projects well. And once you begin executing on it well. You really get a treasure trove of data about how you can be more efficient. Improve your margins and grow your business. Amazing. As we talked about. It's an area of low maturity and I don't think it really needs to be. Right? So as I said, I'm I'm excited about what you guys are doing, I think it'll be incredibly valuable for a lot of people just to start to put a bit of more focus on this and then be able to really skill forward. And and apply a lot of these modern techniques to project management in the same way that they're trying to automate and enable and minimize sort of the wasted labor effort in in the support side of things. They can start to apply this to projects as well. So awesome stuff, Mike. Really appreciate your time. Yeah. Thanks so much, Todd. Really appreciate it. Thanks for having me on.