ERP052 - Scoping Projects for Success

Welcome to Evolve Radio where we explore the evolution of business and technology. Today I'm joined by John Scott from Scopestack. We talk about some of the best practices you should use when you're scoping projects. Things like fixed fee versus T&M, the difference between a proposal and a SAO, and how you can make your project scoping easier. This is a great episode with useful insights to help you up your project delivery game. You can increase profit and client satisfaction while reducing the burden on your tech team. If you enjoy the show, be sure to subscribe on iTunes, Stitcher, or wherever you get your podcast from. Also, be sure to check out the webpage evolvedmgmt.com/podcast. For show notes, links to my guests and to check out previous episodes. Now, let's get started. Joining me today on the podcast is John Scott, CEO and founder of Scopestack. Welcome, John. Hey Todd, thanks for having me. All right, so we're going to be digging into projects and project delivery and how to scope and uh develop projects for project delivery. So this will be really useful for the IT folks. And a good place to start I think would be something that that gets uh debated a lot in the industry is whether or not you should do fixed fee projects or uh time time materials. Um I personally am a big fan of fixed fee projects as much as possible. And given sort of the enterprise history that you have, as well as some of the SMB delivery, I'm curious we can bat this around a little bit. Uh what's your feeling on fixed fee versus uh time materials projects? Is there a place for time materials or should everything be fixed fee like I prefer? Yeah, I think, I mean, you're going to be right 100% of the time, right, Todd? So, um it's your podcast, you can be correct. No, but um in all honesty, I think, you know, if if you can have a really buttoned up statement of work, then fixed fee is the way to go. Right, I think the the clients prefer the fixed fee simply because it reduces their risk. Um I think there's a lot of perceived value in a fixed fee project as opposed to T&M time and materials project. There's a lot to be misconstrued in T&M. And I and I think, yes, I I prefer fixed fee because there there's a lot of value to that and there are a lot of things that you could represent to a client just by showing fixed fee, right? Like you've done it before. Um you're not making it up, you know what you you know what they want, you know how to deliver it. Um I think with time and materials, you leave yourself a little bit exposed to the ever-ending never-ending project. Um I I think from a client's perspective too, they are a little typically a little weary of that because they don't know what the budget's going to be, they don't know what the price of the project's going to be at the end of the day. So, much like construction on your home, it's a it's a little bit scary, um unless you have a fixed fee and I think it just puts everyone in a good spot. Yeah, that's I agree. I think the the the primary one is exactly what you said, just the the peace of mind around what this is going to cost me and being able to budget for that is a is a really nice part for for the client. And you can just tell them like I'm going to deliver on these deliverables and and provide the value and this is how much it's going to cost, it's not going to be more than that unless you change the scope. Uh so that's that's a really important piece. The other piece I think that um the the providers need to understand is if you're doing fixed fee, that's where you're able to build in margin. So if you can do it faster and automate things and leverage tools to do things quicker, but still have a, you know, a competitive bid that is uh is built on sort of the labor effort. Then uh then that that's really helpful, so you can kind of make a bit more margin if that's possible. Or, you know, you can um uh be use those same efficiencies to reduce your your bid cost and and potentially deliver on a lower price. Yeah, I mean, I think it's very easy for the end client to look at a time and materials, look at a resource rate, right? And say, oh, I could just go get that same level of resource from someone else or go source that resource, you know, within the market myself. Um so I think it just leaves you open to um bits of risk that you just, I mean, if you've done this before and you feel confident in your service delivery, methodology and the team, then. Um that should absolutely be your your primary goal is to lead with fixed. All right, excellent. Um another piece that people often miss, I think when they're they're maybe a bit lower on the maturity scale for project delivery is not including project management. And I hear this, you know, the the the low end or the uh the the emerging MSPs, kind of the less mature groups will typically push back saying, well, I can't include project management because the client won't agree to it or they they don't see the value in it. Uh so we just have to do that on the side of someone's desk. And this sort of comes back to the first question is, if you're doing it in fixed fee, they don't know and you can include project management which increases sort of the the the the availability for delivery and the quality of the delivery again. So uh what's your what's your sense on uh how much project management should be included and whether or not it should be included in everything? Well I think I mean I think you just hit the nail on the head. And that like project managers are there to um help you successfully deliver a project. Right, so it's not some undue burden just because you're trying to make extra money. Like they have a very specific role and that is a very special person in a project. I mean, they keep everything on the rails typically. Um it's not us engineers doing it for sure. But um no, so what what we're typically seeing in the industry and again, we're working, you know, with a lot of bars across the globe now. Um that typical, that standard rule of thumb is 20% project management on top of um your standard level of effort or, you know, the rest of the engineering hours that are in the project. So, um we've seen some customers go higher, we've seen some go lower. Um but we we typically start at that 20% mark and what we've seen is that's pretty well received across the board and and a pretty good standard to to roll with. Yeah, that's uh sort of similar to what what I what I I do as well, um uh the calculator that I built for this is similar to the the product that you guys have developed at Scopestack. And it automatically added uh it was either 12 to 15% of project management, kind of depended on what we were looking at. And then we added uh 10% contingency so that there was in that fixed fee, there was some buffer for overruns or things that didn't go quite as well as we thought. So and I think if you just combine those two and just call it project management, you can have that split into two pieces, but that that ends up being that 20 to 25%, right? Yeah, so what we um what we did in Scopestack was very similar background, right? And so we were doing the same thing in Excel calculating a percentage um for project management. But we what we did in the software was we said, okay, you can set different levels of governance around a project. So project management, documentation time, um contingency risk, right, assessment time of the existing environment. And so we give you the ability to um reduce the risk as much as possible on every single project by pre-defining a certain percentage. And so as you're increasing scope on a project, all these items are ebbing and flowing based on that that engineering effort on it. So we we've had business owners say like this pays for Scopestack because we always forget it, we always, you know, we're digging ourselves out of a hole from the getgo because we don't have it in a project. Yeah, that's another good one, uh is documentation time. A lot of people don't tend to think that being built into the the statement of work, that's a really good one to catch as well. Well, I mean, that's that's the post sales version of scoping for pre-sales, right? Yeah, that's a good way to put it. Yeah, they're they're responsible for building that as built and the documentation. So hey, this is what we delivered, especially in a fixed fee project. This is what we delivered and it just it takes time, it takes time to do that. So you need to account for it for sure. Right on. Okay, let's uh uh move up the sort of the the uh the scoping stack here, scope stack. Another piece is uh I find there's a lot of confusion between sort of the the three types of things that you'll need when you're pitching a project to to a customer or a client. And I think all of these are generally required, the sort of the complexity of them can be different given the circumstance. But uh I I find um people don't necessarily know the difference or understand how these things are used differently. And the three things would be a proposal, a bomb or a bill of materials and the SAO, the statement of work. And I'll just sort of give my my experience in this and what I've seen is um so many people tend to use a statement of work uh as a sales document. So so a client says, hey, we need to get this project done and the sales person runs over to the tech team and says, hey, can we get this project built for them? This is what they told me they need, uh technician proceeds to spend, you know, maybe two hours, sometimes 12 hours producing this awesome statement of work. The sales person runs it back to the client and the client's like, okay, thanks, we'll take that into consideration. And they've not really qualified the level of sales effort required here. Uh and I I find this is maddening that tech time is spent so much on pre-sales efforts without really qualifying sort of what should be done. So I think it's really let's let's talk a bit about like what's a proposal, which is the sales tool. Uh how is a bomb used and then how's that rolled into a SAO? Yeah, so from our perspective, a proposal is very much a yes, a sales tool. And it's got a lot of pretty pictures, it's got a lot of marketing content in it. And I think overall, it's a much fluffier document, right? And so it's not it's not technical typically from what we're seeing. Um there might be some high-level numbers in there, um but it's not an executable document that the client would sign off on and then project execution would happen. Um again, a proposal is a way to to really start qualifying the business opportunity with that client in our view. The bomb, um I think is like the interim step between that and the statement of work. So the bill of materials, so in pre-sales, what we're typically seeing is the bill of materials and the SAO are the two biggest things um that any pre-sales engineer is working on typically. Um we feel like as an industry, the the bomb development aspect is pretty good right now. I mean, tools at Cisco, Netformix, right, there are a lot of CPQ configuration price quote tools out there today that um are pretty well and pretty robust. And so it helps you validate quantities of power cords and, you know, optics and all sorts of things. So, uh what we feel like the next step is beyond that after building out the bomb and the solution. Um is the statement of work. And so the technical language, um that's required and explains to the customer how everything in that bill of materials, which we'll get converted to a quote, will be delivered in a project. Um, so I think there's a progression, right, from proposal, bomb to SAO. Um that you're correct, I I think is in your example, you know, the sales executive, the sales team came to the engineer said, hey, this is what I heard the client say that they wanted. The engineer scopes it based on the sales executives take on the project without even meeting the client potentially and that's and that's just a huge flaw in itself. Um from a process standpoint. Yeah, totally agree and that that I think that's sort of my frustration with that is the the wasted effort, the wasted time. Uh when really, I think the the the the tech and the the account exact need to determine, you know, what's their level of interest here? Do they just want to understand is this $5,000, is this $10,000, is it $50,000, right? They they're looking for that ballpark budgetary number, not not something to hold you to say, well, you told me this was going to be $15,000 and you quoted me 17. Well, okay, you know, you were talking about proposal, but we actually did the statement of work and now here is the actual price. So I think it's a matter of of positioning, but also qualification with the with the client when you're trying to determine like like what are you looking for here? Do you just want a ballpark number? Or are you are you keen to to go forward and execute on this project based on a need? Yeah, absolutely. And and I think that's what we're trying to do with Scopestack, right? So our vision is um a couple of different things. You know, that engineer sitting in a sales meeting um with a client and they could be, you know, as the conversation's happening, they could literally be pulling in specific tasks, specific parts of a project. To get them to uh kind of the framework of um the project that the client's talking about, right? And literally you can click a button and say, let's generate a services brief. And so it's, you know, high-level business outcome, high-level solution summary around what the client's saying, um as well as some pricing and and some budgetary elements. And so we can couple that with a way to qualify the opportunity very quickly as opposed to in your in your past example, the two or three hours of the engineer's time to to build that out. Right, so like how do we how do we um reduce that burden on the engineering team? Allow them to be in front of the clients a lot more, um and then, you know, create a a technical document that's accurate at the end of the day, but much faster. Yeah. And and one of the other pieces that I I really like about using a tool like this uh is the uh is the consistency of the quoting. So excuse me, if you ask uh, you know, a technician A to quote a particular project, they they they just sort of use their own frame of reference of, well, I think this will take me two hours. This will take me 12 hours, this will take me an hour, I think we're good, right? Then you go to talk to technician B who's maybe a bit more conservative and says, well, I think this is five hours, this is three hours and this is 20 hours. Right, so depending on who you talk to, the project can look very, very differently. And I I think the having like a a library of uh of defined deliverables and what the agreed upon uh deliverable time for those uh for those to execute in a project is. Is really powerful from a quoting standpoint, one because it eliminates that inconsistency. But also number two, it allows the consistency uh uh or the um uh the technicians to all agree on how much time a particular piece of work takes. Yeah, absolutely. And we I mean, we had a client, I had a um conversation with a client yesterday that said that exact thing. Right, so they have an an engineering group with different levels of maturity across every single engineer. So the more seasoned engineers are able to scope a project and have really a lot of um, you know, they don't they don't have as many questions about how to scope out this project, um because they've done it before. There's also the junior guys that do have a lot of questions. Um and so if you can use it all also as an enablement tool to kind of level set your engineering team. Um and so if you can use it all also as an enablement tool to kind of level set your engineering team. So the mature guys, you know, um or girls, they're they're scoping out a project, they're defining the standards that then the other engineers can start consuming. I mean, I think, you know, from a consistency standpoint, that's what we used to see um at a couple of partners that I was at. Was the delivery team, the back office chatter was, you know, hey, what did they scope this time? Right, it's the same technology we're deploying, but um they didn't know what was in scope this time just because we we made it up every single time and to your point, every engineer made it up differently. And and pretty and back to sort of the first question that that's that's pretty difficult to do a fixed fee project if not everyone agrees on what that fee actually is for a fixed fee project, right? Yeah, and and then think about like the the future of that, so if you can start defining some standard service offerings and levels, um but at a much more granular level. Then you can start tracking that from a delivery of a project standpoint and then, you know, update the level of effort that's being scoped. Right, so you become more competitive in the market because you know what you're doing on delivery, you know how you're scoping it and there's a really nice back and forth relationship between pre-sales and post-sales at that point that should win you more business ideally. Yeah, awesome. So, uh we we touched on the SAO. Um if you kind of review statements of work that that come out of any organization, they tend to look extremely different depending on what the organization is. And uh uh not a one size fits all, you know, you've seen I've seen a one or a two-page SAO, I've literally seen a 60-page or an 80-page SAO. Yeah, absolutely. Some good bedtime reading material. Uh what would you say are sort of the essential elements of a statement of work? So from what from what we've seen based on, you know, talking to partners and building these, you know, hundreds of these out, um if not thousands now. Um some of the basic elements are right, the basics around client info, contact info. Um then beyond that, it's, you know, an executive summary and a solution summary, so really executive summary being very business outcome, so what are they trying to achieve, what is the expected outcome from this project? And then the solution summary is a much more technical, how do I get to that outcome via technology? Right, so those two things and I think that those two parts are hard to automate, to be honest with you. Because that's some of the art of a pre-sales engineer is providing that context and that narrative around a project. Um next beyond that, we're seeing the technical language, so we're installing X widgets, Y features of each of those. Um and we we're typically seeing that technical section broken down in a couple of different ways. It could be broken down by phases, so if you have a standard phase delivery methodology, we're seeing that. It's broken down by locations, um, you know, so if you're doing a multi-site project or a bunch of e-rate work, you know, what are you doing for every single school or every single location, right? Um and then beyond that, we're seeing the governing language and the pricing, right? So assumptions, out of scope responsibilities, and then pricing, um of the fixed fee project and, you know, coupled with that typically some some billing milestones. Like, you know, if we did the phase delivery methodology, you know, phase one, we're going to bill you this much after we complete phase one, phase two, phase three, right? So that's that's typically what we're seeing um from a standard. And what about some of the other elements that that tend to get included like um uh exclusions, assumptions, uh some of the the more uh I guess risk language that would go into those statements of work? Do you think that those are always required or maybe dependent on sort of the scale risk of the project? No, I I think they're I think they're absolutely required, um and that's what I meant around governing language um around assumptions and out of scope. I think if you're doing a fixed fee project, you need to be very clear about what you're not doing, right? Um I think with a time and materials, you know, typically that delivery is mandated by the client themselves and not the business. So or the partner. Um so there's some flexibility there. Um with inherent risk, of course. But um absolutely, I think uh assumptions of this project, things that are specifically out of scope, those absolutely need to be all be accounted for. Yeah. Um and you can you can define a bunch of that up front usually. So if you're delivering this service, these things are out of scope, right? That that correlation is pretty pretty straight. Yeah, the the statements of work that I built typically, the there was sort of a default set of assumptions and out of scope items, like just that we're going to be typical with any project. And then you would just kind of review those and pop a few back in based on whatever the the particular project was. But I think a lot of those are fairly universal uh from from the the defaults that can be included, can be templated if you need to, right? Yeah. I mean, the best line is, if we didn't say it above, it's out of scope. So you start that one, um if you start that and you're, you know, assumptions and out of scope section, then, you know, at least you have a fighting chance, right? Yeah. And I guess the one of the other ones we didn't mention as as far as fixed fee and I don't want to beat this idea to death. But I think it's really important because I still find it is not uh a universal methodology and I I I think it's a a missed opportunity. But um the other bit around this is having that statement of work in a fixed fee project allows you to collect up front, right? Um because the client will know how much that project is going to get and what the deliverables are for that. So you you can bill the 100% of the project up front. And what I tell people if they push back is at the very least collect any hard costs. So if you have to purchase anything, uh get those that get that money up front. And if they're still really nervous about billing 100% of the project up front, then you can do kind of a uh maybe a 50/50 or a 75/25 uh up front and and post. Uh but then you run this risk of um, you know, the client delays on the close of the project and may complain that, you know, well, that maybe this wasn't done. And I just don't have the time to meet to approve the closure of the project. So if you're going to do that, make sure that you're in control of uh who says the project is closed versus not, they can sure push back for a couple of weeks maybe a window there. But uh I I think that billing 100% up front is a huge value and if you're scoping and and billing projects correctly. Yeah, and I think I think speed of um speed of getting back to a client. So is important as well. So if you're if you're engaged in a client conversation, they're like, okay, I'm interested in this. I think if you're able to turn around these statements of work and pricing quickly, um almost pretend like you've done this before, then then there's there's a lot of business to be had just by like lost opportunity and timing. I think. Um, you know, I I've been at several large partners and they roll out, you know, these commercial teams because they're trying to go after that business, but they're not built to go fast. Right, and that commercial space, as you know, is very time sensitive. I mean, you you've got to be able to react and put something in front of a client very quickly. Yeah, that's a great point. So, uh we've kind of touched on the the solution that that you guys have built at Scopestack. Do you want to maybe elaborate a bit more on uh how the solution can help around the the the scoping of projects, the pre-sales as well as the implementation and delivery? Yeah, absolutely. So, um again, my background is is very pre-sales oriented for some some national global partners as well as some regional partners here in the states. And um what what I found to be a gap, um and I think there are a lot of peers in this industry, you being one of them, right, that would agree is the scoping and pricing. Um function for a partner or for an ISV is is a big gap, right? So, as I mentioned, the the configure price quote part is good from a bomb development, but the services and SAO part, um especially the coupling of level of effort to language is the big gap today. So there are there are absolutely really good tools out there around proposal automation, which you can pull in snippets of text and you can kind of build it. But it has nothing to do with level of effort and pricing and resourcing of that project. So, what we did is we built, um, you know, a modern web application that that is built for pre-sales of a of a partner ISV MSP um around services. So, um our whole thesis is if we can reduce the amount of time it takes to scope, also giving you the accuracy of a project, then you can win more business. Right? Um, you can reduce the burden on the business of having engineers spinning, you know, highly paid engineers spinning a lot of time writing uh word documents, which they don't want to be doing. Yeah, they really don't. Just if anyone if anyone questioned that, right, they really don't want to be doing that. So, so what we did with Scopestack was we built a a very var specific MSP specific platform around services. Um and so we give you the ability to uh scope and price out a project in one platform, coupling together level of effort and language. But also building on things like governance, project management, all those things that need to be considered in every single project, um and just making it extremely easy. And so, um that's where we currently are leveraging integrations, API integrations with CRMs, like Connectwise and Salesforce, just to name a few. Um to make the sales to pre-sales transition easy. Um and then we're currently working on some projects to make the transition from that pre-sales scoping to project management and the PSA tools easy as well. Um so again, just bridging that gap between sales and post sales is right where Scopestack fit. Yeah, that's awesome. I I I see it as uh uh upping your maturity game while also making it easier, that's certainly a win-win, right? Yeah, absolutely. And so one one of the cool features is if you're building projects on the fly, um again, I was talking to a client yesterday about this, so like just start, you don't have to pre-define everything to use Scopestack. You can literally start scoping a project just like you would in your Excel worksheets today. Um coupling that with language and then we give you the ability later to adopt those elements into standards. So it's, you know, organically crowd sourcing kind of your mind share around technical language, level of effort and scoping that you can then go reuse on other projects, right? Um and so then, you know, the project delivery team knows what to expect um on these projects and there's there's some consistency there, um as well. Awesome. All right, so if uh people are interested or would like to to reach out to you to know more, where can they follow you or contact you and I'll include uh resource notes in the show notes as well. So, um the best way if you're interested in the platform, um we have a a free 30-day trial, um that's available to anyone via our website and it is scopestack.io and there's a big button in the top right that says sign up now. The other way to reach out, um I'm again, I'm very engineering, so I'm like, you know, not social. So, um I am on LinkedIn though, uh so Scopestack John, um again, John Scott, I'm on LinkedIn and so I'd be glad to have any conversation with anyone um around this. And again, you know, I feel more or less like we're still in the channel space, um than we are, you know, a big software organization, right? So like I think we're trying to solve a very relevant problem in this industry that um we're getting a lot of really good momentum around, a lot of really good feedback from the industry on. Um and I I think if we just continue doing that, we'll make something that's pretty great. Awesome. Well, I appreciate you being on and uh uh sharing some war stories about project scoping, project delivery with me. Absolutely, thanks Todd, appreciate the opportunity.