Mastering Project Scoping and Management: Expert Insights from Josh Moree

Speaker A: Foreign.

Speaker B: Hello. Hello and welcome again to the ENSCOPE podcast. This is John. I'll be your host today. Um, if we haven't met, I'm the CEO, co founder over at scopestack where we automate all things IT services, scoping, project automation. Which is why when I went out to the PAX8 beyond conference and I met Josh Morey, um, um, and I went into a session and it was all about scoping and scoping, hierarchy and work, breakdown structures. It was music to my ears and we instantly fell in love. So Josh, thanks for being on the show, man.

Speaker A: Yeah, I appreciate you having me. As I mentioned earlier, anybody wants to take the opportunity to ask me about projects, I'm certainly, uh, happy to entertain.

Speaker B: We're kindred spirits. We have the similar hairstyle. I haven't committed fully like you have yet, but, um.

Speaker A: Almost there. Just take it.

Speaker B: Yeah, exactly. I was actually getting my hair cut the other day and the lady was like, when are you just going to shave it? And I was like, let's not go there yet.

Speaker A: It's liberating, let me tell you.

Speaker B: Is it really? I don't know, man. Um, all right, Josh, so senior executive coach over at PAC State. And so you're kind of give us a background what you do at PAX8 and some of the conversations that you're having on an ongoing basis and then we'll get into the topic that we love to talk about.

Speaker A: Absolutely. Well, I'm, um, part of the academy branch of PAX8. Uh, we work, uh, with instructor led courses, peer groups, uh, business coaching, uh, and I primarily work on the coaching side of things, but also instructor, uh, led courses and peer groups. And my day to day is speaking to people about operational processes in various areas. Service delivery, account management, most uh, notably projects. Uh, I absolutely love what I do. Uh, we have the opportunity to help people empower themselves. We are very firm and we call ourselves coaches, not consultants. Because it's not just about let me tell you how to run your business, but let me help you grow your business for you. We're going to meet you where we are and that's something that we say quite often. Yeah. Um, so that's, that's what I do in a nutshell.

Speaker B: That's awesome, man. Again, um, you know, came out, uh, to the conference, saw your session and you know, I just sat there and like everything you were saying, I was like, yeah, I was like, we, you know, we try to say that to people all the time or, you know, that's something we should Include in marketing. He said it better than we did, you know, so it's always great again just to hear about it. And you know, um, I love to just kind of like, kind of unpack some of the highlights that I remember from, um, that session, uh, presented it. And um, you know, some of the things I think about are like, you know, what is a scope? Like I did like a post, um, a LinkedIn post the other day and it was like, I think I had a bad moment or whatever, but I was like, psa, like a scope is not a quote, it's not a proposal. Right. It's not a necessary. So I think some of that stuff can get pulled together. Um, and so I want to kind of unpack that one with you, um, templatizing, like, why should we even do it? Um, again, something that we're very high on and then just the idea of like, okay, that handoff between, if we're doing a good job, scoping, how does it impact the project management team, um, in terms of like, scheduling and so on and so forth. So, um, yeah, man, let's start with aspects of a scope. What would you say is your definition of a scope and kind of some of the highlights of things, um, that you'd want to see in it?

Speaker A: Yeah, absolutely. Um, so first of all, I'll say that much of my background is PMI based. There's different modalities when it comes to project management. M. Right, you've got, uh, Google's way of looking at project management. You have uh, Comptia's, ah, Project plus, you have PMI and you have a lot of others. So a lot of the aspects that I speak of, the concepts I speak of are straight from pmi Project Management Institute. Um, and so when we talk about scope, what is a scope? There's really different aspects of it. And if you go through PMI training, uh, which I would encourage any, anyone, uh, who's interested in project management, any current project management, if you want to go for like a PMP certification or just get extra learning, go study PMI methodology.

Speaker B: Uh, I have a funny story. I, I was, uh, I started hearing about PMI when I was, I was a network engineer and I was like, you know, I think, I don't know if this is the thing I want to do all the time, but I think project management sounds really interesting to me. And so I was telling my parents or whatever and my mom was like, who knows me well? She was like, are you sure you want to be? Because she knew I don't have the attention to detail potentially and like know it takes a certain personality, skill set and that attention to detail and um, for those things to work well. So I, I think about that all the time. Like I could never do what you do. Um, but it's important I, I think for, for someone from a pre sale side like it is important to understand the impact you're having on a project manager. You know, because that's like they are the one that will lead to a successful project at the end of the day. Like engineers are important but if it's not on time, it's not delivered accurately. Like there's a whole host of things that kind of come up from it. Sorry, that was a quick.

Speaker A: No, absolutely. Actually that leads into a whole other conversation. And uh, I talked about this in one of the instructor LED courses is what are some of the good aspects of a project manager? Yeah, right. And we could go a whole other course on that. Like one of the things is can you communicate? And if you're a poor communicator, maybe project management isn't, you know, good for you. But you know, and how we got into those roles, a whole other conversation. Um, so when it comes to um, scope. Yeah it's an interesting term. There's a term that's used quite often called scope of work. But if you go through pmi, there is no scope of work. That's not actually a term in pmi. And so when we talk about the aspects of a scope, think you know what works for your organization that you need to pull out and use. So the very top level, we have what's called our project charter. Now you talking about being in pre sales, I'm sure you were great, I hope of uh, passing the right amount of information along to the technical team. But sometimes we hear stories where that one.

Speaker B: Exactly.

Speaker A: But sometimes we hear stories and I've been there as well because I was a project engineer at one point in time where we get something from the sales team that says, uh, actually it's a great example that came up uh, a couple of months ago. We need a network segmentation because the client needs a network segmentation.

Speaker B: Wow.

Speaker A: Okay, now if I put on my technical hat for a moment, If I put on my technical hat for a second. Wait a minute. Are we doing that because of some sort of ethical walls in a line of business application? Are we doing this for performance? Are we doing this for some sort of compliancy like pci, hipaa, gdpr? I mean, because how you answer that question Depends on how I'm going to scope it.

Speaker B: Yeah.

Speaker A: So that's just an example of uh, what is the information that we are getting from our pre sales? High level, high level scope, high level objectives. What are we trying to actually get out of this at a top level? I love something that uh, Rex, uh, the founder of C level said quite often uh, and I might paraphrase them here but uh, we, the client wants ABC and there are multiple times where we're going to go to the client and say hey client, we understand you want abc. So I'm going to reiterate that all the way through this to make sure that we don't get to the end of the project and we say hey client, here's xyz. Well that's not what we wanted.

Speaker B: Yeah.

Speaker A: Oh I'm sorry.

Speaker B: No, I think you know, and that was you know prior to starting scope stack and again still in the pre sales world like we were making the shift in towards it's not so much about the technical solution as it, as it is about the business outcome that the client wants. Right. Like what are you trying to achieve um, in the business. And so absolutely understanding that um, is super key I would imagine.

Speaker A: Yeah. And what's often called a project charter, it can have different names and this is usually the top level. Now PMI will even tell you there's not one perfect project charter. It partially depends on the paradigm you're in, who's wearing what hats in your organization, the clientele you work with, what's most important as you do it deliberately and consistently and customize it to your organization, whatever that looks like. But the top down information then we move through various inputs which we can spend a lot of time on creating a scope statement. Now I sometimes say a ah, scope statement may or may not be necessary for your organization. Think of this as the written scope. Like okay, now I know what my objectives are. Here are my, I'm going to write down my deliverables, I'm going to write down my in scope and out of scope tax activities, my exclusions, uh, whatever else. But this is more the written version of the scope. And while this is quite advantageous to have not quite as detailed as getting into the work breakdown structure which I'm going to quote PMI here. The WBS is foundational to what we do and what we need.

Speaker B: Okay, so I have a, have a question for you. Um, and maybe this is a chicken and egg thing, I don't know. But which one comes first? The work breakdown or the written Language in your opinion, or can they come at the same time?

Speaker A: Chicken, egg? Uh, they can come at the same time. So if we go by pmi, it's a breakdown, Right. We have the project charter, we have the scope statement, and then you break it down even further to work breakdown structure. And that's where we really get the amount of hours the work. Breakdown structure is utilizing what's called bottom up estimating, straight PMI term. Now, there's different types of estimating in pmi and if we look at the exact opposite of bottom up estimating, we have what we call top down. And I mention it because I tell people, don't do it. How many people have you ever come across? Like, we need to migrate the server and I think it's going to cost 30 hours or take 30 hours. Well, how'd you get that number? Well, I'm a professional.

Speaker B: I know that.

Speaker A: And it's going to take 30 hours.

Speaker B: Yeah, well, that's, I mean, honestly, like, you know, unfortunately, actually not. Not even honestly, like that's what you see from growing organizations. Or it's, you know, the engineer left a large MSP or large variation, started their own. And because they have experience doing that work, like not taking the time to standardize, and I'm not intending to create a segue necessarily, but like it just happened. Um, but like they're not taking the time to put that pen to paper and say, hey, here are the standardized steps. Right. And so like, as you start to bring people onto the business, um, you know, you know what, you know, there's consistency involved.

Speaker A: Absolutely. Yeah. The top, the top down estimating, that many do. It's quick and it's easy. I need a scope right now. All right. I think it's going to cost 30 hours because I've done this before and I'm a professional. Go. But time has shown us over and over and over again when you do that type of estimating, it's usually wrong.

Speaker B: Yeah.

Speaker A: And the other problem with this. And again, this can be we can have lots of segues here that if we're not doing a, if we don't have a quality assurance progress, uh, process in place and we get to the end of the project and we're not validating our scope, you could have went over by 20, 30 hours, but you may not really realize it. And then what do you do next time? You take the same scope and you use it again and again and again.

Speaker B: Yeah, and that's, and that's really hard. Right. Um, and I think that does Go to templatizing. It's really hard to do any sort of baseline or it's hard to do any sort of. This is what we scoped. This was actual. Is bring that back and do it until you have some sort of like, consistent structure. Um, because, you know, if you said, yeah, we installed a router and another project, we installed a router and one's eight hours, one's four hours. Like, well, what did you do? Like, what. What were some of the steps involved there? If it's not the same thing, then how do you know that you're even in the right. Are we talking apples and oranges or just what are we talking about? You know?

Speaker A: Yeah, so there's. And there's one other component to it that I talk about, and definitely I want to get back to templatizing. But, you know, we have a project charter. We have our scope statement, we have our work breakdown structure. And all this is usually compiled into a statement of work. And usually the statement of work is what the client see. Now, I also often tell people we don't want to show the client our secret sauce. I generally don't recommend showing the client your work breakdown structure. Two reasons. One, then they start negotiating with you. Well, do we really need two hours here? Do we really need that four hours there? And we're not open for that. Yeah, right.

Speaker B: We're providing value at the end of the day, like value in an outcome.

Speaker A: Uh, that's m. A great way to put it. We're providing an outcome. Yeah, but also, we're not giving someone our secret sauce to go show our competitor either.

Speaker B: Exactly right. You're right.

Speaker A: So project charter, scope statement, work breakdown structure. Take the information provided into a statement of work, and that is usually what's provided to the client, which usually takes aspects of, hey, here's my ABC from the project charter. Here's my, uh, scope statement with my high level objectives, here's my work breakdown structure of my milestones and the amount to the finish all in a nice little statement of work.

Speaker B: Yeah. Do you, um, what's kind of your guidance around proposals versus statements of work? Like, do you think they're intended for the same purpose? Do we confuse them too often? Is a statement of work much more like black and white versus a lot of pictures? Like just where, where do you land on that kind of spectrum?

Speaker A: Statement of work versus proposal.

Speaker B: Yeah. Do you call them the same thing or do we. Are we trying to achieve the same objective?

Speaker A: I would say they're the same thing. Now, I know that some others may not necessarily agree with that. Because if you ask 20 people what a statement of work is, you're probably going to get 10 different definitions of it. Right. I would say what's most important is that the organization, your msp, you define what the statement of work is, you define what proposal is. And as long as you're doing that consistently and deliberately, every time, in actuality, you're doing it right.

Speaker B: Yeah, that's a fair answer.

Speaker A: But generally I call a statement of work and a proposal the same thing.

Speaker B: Yeah. All right. So you mentioned templatizing, like we often hear, because, you know, that's a big component of scopestack and we get a lot of pushback on. Hey, you know, uh, I'm worried that's going to take too much time. But like, I would say that the end result of that investment in time is way better than if you didn't do it. So.

Speaker A: Absolutely.

Speaker B: How do you address templatizing? And are we talking just the work breakdown? Just scope language? All the above. How far do you go down the templatizing rabbit trail?

Speaker A: In a perfect world, you've templatized your. You could even in a perfect world, on projects that you do repeatedly, you can templatize your project charter, your scope statement and your work breakdown structure. Now, of course, they would vary based off client environment. It's the starting point. So you mentioned something earlier. People say, oh, it's going to take too long. And to that I say, take the time to do it right or take the time to do it again. Right. You can spend an extra 2, 3 hours on the front end scoping it, or you can spend an extra 40 hours on the back end of what you didn't account for.

Speaker B: Uh, I just don't think people, you know, uh, they're Templatizing is not just a thing pre sales should do or engineering should do. Like it truly affects the sales organization because now, you know what you can sell, it affects pre sales because now you can return this, you know, back to the client faster. The statement of work, it affects engineering because they're not worried about what Timmy scoped this time that they're going to have to be on the hook for right when they're on the client site.

Speaker A: Yeah.

Speaker B: Uh, so it affects all areas of the organization if you do it right.

Speaker A: You're absolutely right.

Speaker B: Everyone should be involved in it, in my opinion.

Speaker A: I certainly agree with that. It sets the entire company up for success. An analogy often gives is, let's say I've Got Sue, Sally and Sam. We're going to give them a blank sheet of paper and I'm going to say, hey, I need you three to scope a server migration, start to finish. What's the chances that all three of them are going to give you the same work breakdown structure, the same amount of hours?

Speaker B: Yeah, not gonna happen.

Speaker A: Now here's what's even more fun. Ask them to do the same thing in six months. Mhm. Are they going to do the same thing they did six months ago? No, they're not. Especially if they don't have good processes in place for say, like, quality assurance. Yeah, so when we templatize, we're not just relying on memory for one. Hey, what was that thing that happened six months ago that I'm supposed to remember in this new scope? Right. Uh, we have a company standard. We don't just have Steve, Sally or Sue's standard or the way they think it should be done. We have it, our organization standard. We set ourselves up for a system of quality assurance. So if I have something that's templatized after every project, I can see what I did well and what I need to do better, update my templates. And you can do it better every single time.

Speaker B: Yeah, I had to explain it to me, like, presenting like the client, um, our voice as an IT services organization. Right. Not Timmy's voice or Susie's voice, it's the organization's voice. Um, and so, I mean, you think about like the impact of that too, as you're growing. That team is like, you know, as a business owner and a leader, like we're presenting our voice to our clients regardless of who's doing it. So I think it's a huge benefit. Uh, sorry, you were saying?

Speaker A: I like that. I like how you. No, I love how you say that. Our Voice. I'm going to write that down for later. Presenting our Voice as opposed to timing. And actually, now that you mentioned it, makes me think of other things. What if Timmy decides to leave the organization and all of that knowledge goes with him?

Speaker B: Exactly.

Speaker A: Well, at least you have something that templatize for the organization now.

Speaker B: Yep.

Speaker A: Right. Um, it's another interesting thing when we talk about templatizing, I get kickback on things. Two reasons. One, you mentioned earlier, sometimes people say, oh, this is going to take too long. Well, take the time to do it right or take the time to do it again. Your projects will continue to go over, you will continue to go under in gross margin if you are not templatizing because you're spending all the time at the end of the project cleaning up what you did not account for. Right.

Speaker B: Yeah.

Speaker A: Um, but another side of this is when we're not templatizing, when we're not, um, setting ourselves up with. Oh, actually another part of this with simplitizing and quality assurance as a whole. And I don't want to get too deep into quality assurance. You have to be okay with saying your stuff stinks.

Speaker B: Yeah.

Speaker A: You have to get to the end of the project. You have to say, this is where we failed. This is where we failed. This is where we failed. How do we do it better next time?

Speaker B: And that's, and that's typically an internal conversation. Uh, you're not saying, like, hey, we have to go tell the client where we failed or whatever. You're saying we have to have internal perspective on where we can be better as an organization. Where do we lose money? Where do we put ourselves at risk by just scoping the project wrong the first time? You're right. I think that's a great point. And that requires a certain level of humility and desire to be better.

Speaker A: I love how you put that. Absolutely. You have to have some introspection. You have to be able to say, yes, my stuff sometimes sinks and I'm going to do it better the next time.

Speaker B: There are a lot of organizations that do have that perspective, I will say. I mean, again, those are the ones we're talking to, so I would hope so. But, yeah, those are good ones here.

Speaker A: Well, I see a lot of organizations that don't do any sort of quality assurance and don't templatize, and they just assume everything is great and keep going until you really look at the numbers and you realize you're not doing as great as you think you are. And why. I was having a similar conversation with somebody about that, actually, earlier today. But, yes, I'm sure that was fun.

Speaker B: Um, all right, so what is the impact? Like, if we're, if we're, you know, we have a consistent structure in our scoping document, we're able to have these kind of templatized services. What does that impact on the project management team? And how does that affect kind of those downstream teams that, again, that you're working with all the time?

Speaker A: Well, how does it impact the project team?

Speaker B: Um, for the engineer, does it impact. I mean.

Speaker A: Yeah, well, for the engineers, part of it is, I believe, if they are part of the process, part of helping, uh, develop the templates, uh, being a part of the process, part of the scheduling, you get much better buy into the project. If you have a salesperson over here, and I'm not picking on salespeople, maybe you have a salesperson who says, here's your project that's been scoped for you. Well, you don't always have the buy in and the back of the engineers who are doing the work. Uh, and that, that goes into soft skills. If we would like to think that we're binary enough to say, yes, here's the work, I do it, but we're human, we're not quite as black and white. And if people are part of the process, they tend to buy into it more and really quite honestly tend to have a higher level of subjective happiness being part of the work that they are deploying. I know I certainly was when I was an engineer.

Speaker B: Yeah, because you can trust that information. It's not, it's hey, we created again our voice, an organization standard. I was a part of creating that standard. So that whether it's me or one of my peer engineers, I know what to expect and I know what the expectations are of me, um, for this particular project. And so, yeah, I could imagine. Yeah. I've also been on the engineering side where I'm just handed a document, said, go deliver this. And it's not a great feeling, you know. However, if I was a part of whether, again, whether I was part of like just a sales conversation or I was a part of a, you know, a much more kind of intentional program process around creating these standards like I do, I feel better about my confidence in delivering a successful outcome for the client. So 100% agree with that. That's huge.

Speaker A: I think you hit a point there as well where you're, uh, referring to someone's just giving a piece of paper. You say, go do it, and they may feel lost. And again, going back to the quality assurance, I always made sure that we had a survey at the end of our projects that we talked to our engineers and like, did you feel like you have support of your project manager, your project team? And if you're just handed a load of tickets and say, here, get it done with no explanation, this is going to make someone feel like they're on an island. And again, going back to the soft skills that we want to develop that even PMI talks about having as a project manager, we want to make sure that we are making sure our engineers are included in the process. And who doesn't want happier engineers? Right?

Speaker B: Happy engineers, happy. Something else, I'm sure.

Speaker A: Happy engineers, happy project manager. Can we say that? I mean, it doesn't rhyme, but happy client, happy, everybody. There we go.

Speaker B: Everyone's happy. If the engineer is happy, that's a shirt for sure.

Speaker A: I'm going to have to work on this. I'm going to come up with a little slogan for that later.

Speaker B: I'm telling you, you should. All right, so you mentioned, um, like scheduling, schedule, baseline, um, maybe walk me through, you know, we're kind of wrapping this up. Walk me through your, you know, some of the highlights of what you brought to bear in that session around scheduling and baselines and things like that.

Speaker A: Yeah, I would say out of all of the aspects of project management, scheduling is the number one aspect that I get a lot of kickback on. And there uh, are, or that I find a lot of project managers are averse to. And I used to be as well. My, my background being a project engineer, I would have a boss, they'd give me a project and I would just go get it done. I had a deadline, but I didn't really have like a certain schedule to stay within. In retrospect, I can remember when my boss and I'm talking about like 2004, 2005 was like, hey, we need to put in time. Hey, when is this all going to be delay? I say, hey, I got it, don't worry about it. And I really had no idea about gross margin, client, uh, profitability. I had no recollection of that. I thought, he gives me a project, I get it done. Why is he on me about hours? It doesn't matter. But it wasn't really until I got a management where I started to understand all this actually does matter for the profitability and success of the company. And so when we talk about scheduling, sometimes people also get the impression that we're trying to micromanage the engineers time and anything but that. In fact, I want the engineer to be a part of the schedule. Help me co create the schedule.

Speaker B: Yeah.

Speaker A: And so when we create a schedule, we're essentially creating bumpers. If I know what the project, project's budget is, especially if I know every ticket on there what the budget is supposed to be, I can schedule this project out from A to Z and I control that schedule. If I can control the schedule, I can control the budget. If I control the budget, I can control the costs. Um, are you familiar with the term, uh, uh, Parkinson's law?

Speaker B: Yeah. Couldn't tell you what it means, but I've heard it.

Speaker A: So I'll give you the deduced version of it. Work fills to the time allotted.

Speaker B: Yes.

Speaker A: So if you tell Jimmy, hey, you've got until the end of the month to do this task, how long do you think it's going to take Jimmy?

Speaker B: End of the month?

Speaker A: All the way to the end of the month.

Speaker B: Yeah.

Speaker A: If I tell Jimmy, you've got two hours within reason to do this task on Thursday, how long is it going to take Jimmy?

Speaker B: 30 minutes?

Speaker A: Well, hopefully. Well, maybe. Right. Uh, but hopefully he's allocated that time. Now we're giving you an expectation.

Speaker B: Yep.

Speaker A: So when we talk about scheduling, it's nothing about micromanaging, nothing about trying to, uh, uh, control engineers time. But we're trying to manage the budget when we have engineers who are part of that schedule, building that schedule out. Project managers responsibility is to help hold people accountable to that and get any blockers out of the way so they can do it. But again, this is one of the biggest things I get kickback on. People will say, oh, well, the schedule is going to change, or what if equipment's late? Or I actually go through a list of reasons in my beyond presentation and elsewhere. I go through a list of reasons why we don't want to create a schedule. And then I ultimately say these are not necessarily invalid reasons, but I will call them excuses. There are many more reasons why we do want to create the schedule, and the most important one really is controlling the cost. But I'll just give you one more for time's sake. Imagine that you bought a project from me and I said, hey, thanks for buying this project. Appreciate you spending $30,000 on this. I'm going to start sometime in the next few months and we'll finish it sometime next year.

Speaker B: Yeah.

Speaker A: Does that provide value to you?

Speaker B: No, no. That's a rough, that's a rough, uh, foot to start out on for sure.

Speaker A: But if I can tell you appreciate the project that you bought from us. We're scheduled to start this on in the middle of September, September 15th. We're currently scheduled to by September 30th contingent upon hardware delivery. Any issues that we see. Now, I did not promise you anything, but did I provide you value at least by giving you an idea of a schedule?

Speaker B: Oh, yeah. 100%. Absolutely.

Speaker A: I would say so as well.

Speaker B: And you can't. And again, this all kind of like it's, it's a waterfall. Right. Like without that work breakdown, you're gonna have a very hard time scheduling. Um, and you know, without that statement of work. Right. And then getting into that work breakdown, it's gonna, again, it all flows Downhill, um, at the end of the day. And like there's there, there are data elements that are needed right in each of those stages. So, um, yeah, man. I mean, you know that like, literally these are like all the notes that I had from your session. I think I have like, pictures and stuff too. But like, it was just all such good information. And this is only like just scratching the surface, um, you know, of, of the kind of the whole area. But again, I think we hit some of the highlights, um, that again, that I remember and that I wrote down. So, like, what, um, as you're talking through this stuff and you're starting to engage with an MSP for the first time or just around this topic, like, what are some bits of like, just practical advice, like, where do you tell them to start? Like, what are, what are one or two things that you can offer again, to that hypothetical msp, but then also to anyone listening on the podcast.

Speaker A: Uh, so first off, it's. We have to keep in mind it's progress, not perfection. You'll never have it right the first time you're trying to develop this, and that's okay. Uh, but you have to start somewhere, as you said. So start by engaging your team. Start by getting thoughts down on paper. It may not be perfect, but also create accountability around it. Because this is another thing often here when we talk to people about creating some sort of templates, I may speak to somebody now. I say, great, we're going to create a template for a 365 exchange. Um, exchange. Ah, migration. Great. Six months later. Oh yeah, we gave that to Timmy, but we really haven't finished it yet. So you can assign it to someone, but unless you again, as a project manager or just any sort of manager, provide accountability around that and expectations, it just becomes a good idea that sits on somebody's plate indefinitely. Now, of course, there's a lot of great resources out there, including of course, go stack that you have templates already made. People have no reason not to create and, or use and, or find templates. There are plenty of resources out there. Yeah, start somewhere because once you get it rolling, you can replicate success once you start finding where you're doing well and where you need to improve.

Speaker B: Yeah, no, uh, I love that. I mean, we say it all the time. We say just start scoping, but like, you can literally just start, like write it down, right? Follow a little, follow some sort of structure something. Right? Like no more of this back of napkin. Hey, we keep picking on Timmy, but, uh, you know, Timmy, just scope this project, go deliver it like that at the end of the day, is not going to lead to a profitable business. I would imagine so. Right.

Speaker A: And one other piece to that, and we've mentioned this a few times, you have to be okay with taking the time to do it right because take the time to do it right or take the time to do it again and constantly fail.

Speaker B: Mm, mhm. I love that. Yeah, that. That would be my line that I take away from you on this one, among the others that I already took from your session. But, um, well, Josh, man, I. Again, I think we could probably have 10 more episodes on this and maybe we will. But for now, um, if anyone wants to, like, just catch up with you, get deeper on this, um, learn more about what you're doing over at PAX8. Like, what's the best way for them to reach out?

Speaker A: Well, you can always go to pax8.com, you can connect with our Academy team. I, uh, love coaching people through project management. I coach on various aspects of our operationals guide, but project management's my bread and butter. It's my passion area and I love talking to people about it. Uh, but come find us through. Come find me through PAC State Academy or just find me on LinkedIn. Uh, I'd be happy to have a conversation with you, point in some right directions for Academy and yeah, take it from there.

Speaker B: Awesome, man. Well, hey, again, I really appreciate you getting on here. I know you got a lot going on, a lot of MSPs you're working with right now, but, um, you know, at the end of the day, again, like, this is something that spoke to me, spokes to like, essentially the core of what we do as a business here at scopestack. And so, um, really appreciate you hopping on.

Speaker A: Ah, I appreciate you having me. Thank you.

Speaker B: Yeah. And for those of you that, you know, Josh mentioned it earlier, but if you don't know anything about scopestack, go to scopestack IO. Um, but you can also sign, uh, up for a free account. Right. Kick the tires on that, try to experience some of the value there. And again, at least glean some sort of insights around how we think about services and scoping projects and work breakdown and so on and so forth. So, um, and again, if you're interested in finding more out, um, more out about these podcasts, you can go to scopestack IO podcast. There are a ton of great resources there, some other great, uh, thought leaders as well. So again, Josh, thanks for joining us today, man, and we'll see everyone out there.