Scope Creep Decoded: Balancing Flexibility and Project Control | Episode 14
[David Guthrie] (0:00 - 0:09)
If you have too much scope creep, obviously that's going to affect timelines, it's going to affect budget. You know, maybe it affects the quality of what you end up developing.
[Calvin Smith] (0:09 - 0:18)
On every single project, every single web development project, it's going to happen. Even in the best case scenario, it's probably going to happen, because ...
[David Guthrie] (0:21 - 1:01)
All right, welcome to the Ksense podcast. I'm here today with Calvin from Ksense Technology Group, and we're going to be answering some questions that a lot of you have around software projects. Specifically today, we're going to talk about scope creep, what scope creep is, how you can manage it, when to allow it, and just generally how to manage it successfully in a software project.
Thanks so much for joining me today, Calvin. You bet. Awesome.
Let's start off just defining it for people out there who might not know, what does scope creep mean?
[Calvin Smith] (1:02 - 2:56)
Scope creep, fundamentally, just means that as you build out a project, and this can be any project, not just software development, but as you start building out a project, you start seeing the scope basically expand to include things that you either didn't know about before, or that weren't included, but then got added because someone wanted them, or for some reason, that scope is growing larger and larger, which means the budget is going to go larger, and the time that it takes to complete the project is also going to go to expand. So you can see this with all sorts of different projects, construction projects, like government contracts are notorious for this, where you have a scope that just keeps getting larger and larger over time, and in software development, it's particularly difficult just because in construction, at least you have a blueprint for exactly what you're going to build. You have every single nut and bolt basically laid out in the blueprint, and so it's a lot easier to estimate exactly how long it's going to take, especially since a lot of construction projects, if they're standard, like houses or buildings, they've been built before, everything's been built before, like everyone knows how to build an elevator shaft or a staircase or these sort of components that have been done many, many times. With a software project, we're basically building something that's never been done before because every app is unique. So it means that the scope can increase more easily because it's not defined in the first place necessarily because it's impossible to truly define the scope in such a way that would be airtight and that won't be susceptible to that kind of scope creep.
So I guess that's basically what I would consider the definition of scope.
[David Guthrie] (2:57 - 4:02)
Yeah, I like how you're highlighting some of those differences in how the project itself works when it comes to software, it's a little bit unique. So a lot of times you kind of need some flexibility and you might have a bit of what's called an open scope, where you outline kind of like a blueprint. If you were to say, well, we need a living room and a kitchen and these many bedrooms, it's sort of like a blueprint, but to your point, in order to get everything planned perfectly, you basically have to go and build the thing, right?
So how does that work where there's a little bit of flexibility? Should there be some scope creep in a good software project or would you not consider it scope creep if you do a good enough job planning first and saying, well, the scope is we need a kitchen and a bedroom, for example. You know, we need this page and that page as long as it's within that scope, right?
Or how should you think about that? Does that count as scope creep?
[Calvin Smith] (4:03 - 10:46)
There's two different types of scope creep. And the first type we could call like, you know, official scope creep. And then the second type would be like an unofficial scope creep.
And I guess you can think about two different types of projects. So if you have a waterfall project, that means that you're planning out every single aspect of the project up front, you're writing it all out in a document, and then the customer signing that document and saying, OK, here's all the features. We've planned them all out.
And here's how long it's going to take and how much it's going to cost. Right. So in this case, if they want to add something later, you know, they start using the app and they realize, oh, actually, we need this new feature that we hadn't discussed before.
You could consider that like a contractual scope creep or like official scope creep, because you had a scope that was very well outlined or hopefully, I mean, some of them aren't well outlined, but basically you had some kind of document that tells you what the scope is. And now you're actually, you know, increasing it where everybody can see clearly, you know, here's how much it's increasing. You might need to do a change order of some sort like, hey, I want to, you know, officially request that we increase the scope.
Right. And then there's like the more unofficial kind of scope creep. And that is let's say you have an agile project where you don't plan everything out up front.
Right. Just because you don't have a scope planned out doesn't mean that you can't have scope creep, because what will happen is those change requests and those additional features, they'll still get added. They'll still get requested.
And the development team, if they're doing an agile project, they're just charged by the hour. Maybe they'll go ahead and build those things. And the budget and the timeline will still expand for the project, even though there's no official scope increase, if that makes sense.
So. What are the so how do we decide what type of project process we should follow? And, you know, like you were saying, what?
How do we minimize scope creep or what even counts as scope creep in certain situations? Well, the downside of doing a waterfall based project is that it assumes that it's possible to actually outline the scope well enough, and it also assumes that it's possible for the requirements to be known well enough to even outline a scope in the first place. So.
When you're building a web application, the thing is, the requirements will change over time. And that's usually not something that you can help, like they're going to change no matter what. And the reason for that is there's a few different reasons.
Number one, if you're building something for your business. Part of that process is actually, you know, building business processes that didn't exist before. So you're basically expanding that your business processes, you're you're creating new protocols, you're creating new ways of doing things.
And that process, how you can't really draw that out up front, right? You can't really know all the different ways you're going to need to change your processes down the line. So, yeah, you're going to have some scope creep when you introduce new features, but maybe you need those new features and maybe there's no way that you can that app will work for you without them.
And there was just no way to see that at the beginning of the project. So. So that's why I would say that Agile would be better in general than a fixed price project or a waterfall project, because in a waterfall project, what happens is they build the app, they deliver it to you and then it doesn't work the right way.
And then everything you ask for is a scope increase from that point on. So that's why the project can balloon so much in size is because, you know, there's basically a delivery and then after that delivery, you know, you've got to pay however much money for every single thing you ask for. It's all out of scope.
So going back to Agile projects. Within an Agile project, you can think about scope creep in a couple of different ways, too. So the first way is the way I just talked about where things are going to change throughout the project.
Right. And that is expected. And that's actually a good thing a lot of times because you're you're using the actual product and then you're adjusting it and then using it and then adjusting it so you're iteratively improving it.
But the other type of scope, and maybe this is what you might think of as like real scope for an Agile project, would be where you start. You start being inefficient in the way that you're expanding the requirements. So you start building things you maybe don't need.
You start building things out of order. So, you know, less important things get built just because maybe it's more convenient or easier to build them now. Or maybe you think they're going to be more important than they are.
So that's the type of scope you start getting in an Agile project that can really be bad is basically building things that you don't need and not not being able to cut down the scope to the the most important features that you need first. It's always better to ask yourself, do we really need this feature now or can it wait? Because every feature that you think of is going to be something you eventually want, you know, and then but then later on, you might change your mind and say, oh, we don't need that anymore.
The question is, do you need it now or can it wait? And that's what I see a lot in projects is people want features now and maybe those features haven't been well thought out. And it's sometimes really difficult to even wrap your mind around exactly what a really complicated feature is going to do or how it's going to how it's actually going to be used in practice, which is why the more like the more of the app that's actually done, the easier it is to then see how the next piece fits in.
And so that's why you want to cut that scope down and get to the minimum viable product as soon as you can. Because once you have the product in your hands, it's it's much easier to ask what is the next most important thing we need and that will deliver the highest ROI. It's easier to ask that than to make a full list of every single feature that's in scope and build it all now, because half of those features might not even be valuable in six months, you know, or maybe half of them are going to be built wrong because they were the requirements were misunderstood because we didn't have the app.
We didn't have users actually using the app and discovering exactly how they need things to work before we start building them.
[David Guthrie] (10:46 - 11:01)
Yeah, so it's like the best way to prevent scope creep is to just shave the scope down in general, right? Is like constantly be asking yourself that question. Do we need this now?
And doing that prioritization you're talking about.
[Calvin Smith] (11:02 - 14:29)
Yeah, and it sounds easy to do, but there's some there's some details and nuances around how to do that, because what happens is you'll have a you'll have a business owner wants to build an app and they want to they want all these features, right? First of all, everything seems like it's really important at first glance, because, you know, you're just the first reason actually is because when the business owner thinks of a new feature, they have they have no they usually have no idea how long it will take to build because in web development, a really there's a really strange thing where there's basically no correlation between how hard something seems like it should be to build and how hard it actually is to build.
Like, you know, something could seem like it's going to be super hard and actually be pretty easy to build. Something could seem like it's going to be really easy to build. And actually be super hard to build.
Right. And hard by hard, I mean, it's going to take more time and cost more money. Right.
So. That's that's part of the problem is they think of a feature. It seems easy to them.
And therefore, they're thinking, well, this is high priority because in their calculation of priority, they're accounting like they're they're basically making an assumption about how much they're going to spend on this feature. If you tell them that that feature is going to cost three times as much all of a sudden, it tests whether how important it really is to them. Right.
So when you're cutting the scope and it's not like you can just cut the scope without knowing this. Right. Like you could you could you could just try to cut features like any features you possibly can.
But it's so much easier. And the business owner really needs to know how much time a particular feature is going to take in order to be able to weigh its importance against another feature. Right.
So so knowing how long things are going to take and talking about those things in the planning process and then asking, OK, based on the difficulty level of these features, now let's prioritize them and cut the ones we can cut. And then there's also the issue of basically that depending on how you build the feature also impacts how long it's going to take. So there's basically like, OK, there's there's a trade offs basically with how to build something.
And maybe, you know, if you build it one way, it's a little more convenient for the user. It basically it's a little bit better for the user. But to make it that much better, you have to double the effort it's going to take to build like a tons of that type of stuff.
That's an extreme example. But there's a lot of those type of examples where there's like five different ways to build the same thing. And there's trade offs with each way.
Right. So there's trade offs and costs. There's also trade offs and functionality and like trade offs in.
Basically, if you if we build it this way, it's going to be easier for us to build and it's going to work really well for us right now. However, if we're planning down the line for this app to have other features that are going to interact with this feature, we have to plan for those features. And that might cost more now to build this feature in a future proof way.
But if we don't, we're going to have to redo or do rework later on. So preventing rework and things like that. So all of this goes into being able to actually cut the scope because you have to really understand what you're building, how it's going to be built, what the trade offs are for different ways of building it and how much development work is going to have to go into each feature.
[David Guthrie] (14:29 - 14:55)
I mean, that's kind of a big cause of scope creep probably is just not thinking through the pros and cons of of every feature. Right. And the nuance of how you want it to be built for the future version as well as the current version.
What are what are some other causes of scope creep? Is it just, you know, maybe a lack of planning? Is it poor communication?
What are some of those common causes that you've seen that are that are driving scope creep?
[Calvin Smith] (14:57 - 17:38)
You could have a situation where you don't do enough planning. And so you start building this feature and, you know, the developer as they're building it has to sort of figure out how to build it. And then they discover all these different issues or different trade offs or different questions that they need answered.
They might come to you like as the product owner, if if I write up a feature sent to be developed and they come back to me with an issue, what they might say is like, hey, this product or this feature that we're building, it's going to change how these other features work. And we didn't know that before. So in order to build this feature, we basically need to also revamp these other features at the same time.
That's going to increase the scope of that feature quite a bit. Right. So, yeah, if you plan up front for like, OK, what are the risks in implementing this feature?
What other features does it interact with? And what are what is the goal of building this feature? Understanding all that stuff up front.
It can help reduce scope creep in in the long run, because really. If you think about scope creep is basically. Work that is getting done on the app or the project that shouldn't be getting done, right?
It's basically something that you're paying for that you shouldn't be paying for. That's either because it's not valuable enough, it's not worth it or, you know, maybe it's not worth it right now, but it will be later. So it's not it's, you know, it's something you want to hold off on for now.
Or maybe it's never going to be worth it because it's just too expensive. Or maybe it is worth it, but only if we build it in this certain way because it like building it in this certain way. You know, there's some trade offs where doing it this way will take less time and also make it more simple for the users.
Like these are basically all situations where you're building something that you shouldn't be building and you're paying for that development. So. So, yeah, if you the more planning you're able to do and the more understanding of the requirements that you have and also whoever's in charge of understanding this and designing this app, the more they understand the technical aspect as well of how these features are designed, the easier they're going to be able to avoid situations where you're doing unnecessary work, whether it's rework that you have to have to redo work on something because, you know, for some reason or whether it's building unnecessary features that you end up having end up building just because no one really thought to cut those out of the scope or no one really realized how much time they were going to take or something like that.
[David Guthrie] (17:39 - 18:07)
Yeah. How common is that? Would you say?
I know a lot of people out there are trying to, you know, save money on their software projects. They're trying to build just what they need. They're trying to do something that's going to give them an ROI.
So how common is it for people to just have unnecessary features or for the client to be driving this kind of scope creep? Is it still a pretty common issue, even though, you know, you think these people are pretty budget motivated most of the time, right?
[Calvin Smith] (18:08 - 21:19)
Yeah, well, I guess a good analogy is if you go to the auto repair shop, right, you take your car in there and, you know, how often do people get repairs that they don't need to get? Right. So the reason that happens, even though they're financially motivated to not do that is number one.
I mean, the mechanics have an incentive to do sell you something you don't need. Right. But number two, they just don't understand their car well enough to understand what is needed.
And so it's not a perfect analogy, but the part of it that is good, I think, is basically you have this big complex thing, this big complex system that unless you know what you're doing, it's going to be hard to be efficient, because everything you're going to change as part of that system, every change you're going to make is very expensive. Because you're basically, you know, you're either building a new feature that's complicated or your, you know, web development is expensive, basically. So the way to reduce that is to really know or to hire somebody who knows how this thing works and how to design it the right way.
So how common is it? I would say on every single project, every single web development project, it's going to happen. Even in the best case scenario, it's probably going to happen because, I mean, the way to make it so that you never have any scope creep is basically spend twice as much or three times as much or 10 times as much time on the planning.
But you can only do so much of that because it's, you know, you got to get the software in the user's hands. Otherwise, you're planning in the abstract, but as soon as people actually start using the software, you know, like you just they do things you didn't expect, they need things you didn't realize they needed. So there's like a balancing act of, you know, how much planning, how much time to spend on planning and how much time to spend on actually delivering working software and then iterating.
But yeah, it's very common with the more complicated the project, the more common it is because, you know, with a very simple project, it's a lot easier. Like, you know, you probably don't have too much scope creep on just a WordPress website, right? It's much less less of a problem because it's more simple.
You know, the client can fully, they fully understand every aspect of what's being built for the most part. At least they're going to understand the end result because all it is is a static page with images, text, maybe a video or maybe like a carousel or something. But basically they understand it and therefore they can more easily control the scope because controlling the scope is basically a combination of deciding what needs to be built and also deciding how we're going to build it and how we're going to design it in order to get the required result without, you know, being inefficient with how we go about it.
[David Guthrie] (21:20 - 22:10)
Yeah, so you talked about a few ways that people can prevent scope creep. I think it's important to think about that for a sec. And I think the biggest thing is, like you mentioned, just the iterative approach, right?
Being able to get software, working software back really quickly so that if there are changes along however long the development timeline is, you're aware of those incremental changes as you're going rather than, you know, having a whole app built and delivered and then going, oh, like, so much of this needs to change. So yeah, that makes a lot of sense. Basically what you were saying at the start of the Agile approach versus the Waterfall approach is super important in being able to get as close to your original budget as possible.
[Calvin Smith] (22:11 - 24:14)
Yeah, so on that point too, so basically when we're talking about Waterfall versus Agile, the funny thing is that the reason people do Waterfall is because they want to protect themselves against scope creep, basically, like both on the customer side where they don't want to end up paying for scope creep and on the developer side where they don't want to do free work, right? You know, they don't want to, like they require a scope to be written out along with the fixed price. Like if there's going to be a fixed price, there needs to be also a scope so we know what is included, basically, right?
So they try to do it to prevent scope creep but the truth is that type of project leads to more scope creep, not less. And so think about this way, if you're building an app, the way to have the most control over what's being built, if you want maximum control, it would be to build, to basically sit down, look at the app that you want to build or start thinking about the app you want to build and then choose a very small piece of it and then really spend the time to really understand that piece and how it's going to work and how it needs to function and to cut as much out of it as possible that you don't need.
Then to build that small piece, then deliver it to the user, have them test it. And only when they've tested it and it's working exactly how they think it should work, then move on to the next piece, right? Because how much can the scope really expand if you're only working on a tiny piece of the project at one time before the user's getting their hands on it?
With the app you're building waterfall style, the scope can expand way more because you're not going through the verification process to give the feature to the user and have them use it before you go on building something else. Because if you build something else first and then they use it and they want you to change things, that work that you already did to build the next thing may need to change as well, right? So I hope that makes sense.
[David Guthrie] (24:15 - 24:39)
What about other general tips or prevention strategies? Actually, let's move past prevention strategies and talk about how to manage scope creep throughout the project. So you mentioned some prioritization techniques.
How often do you need to go back to the drawing board on prioritization? How often should you be kind of re-ranking the tasks that you have planned?
[Calvin Smith] (24:40 - 27:21)
So let's say you have a backlog, right? And you have all your whole wish list back there. You can feel free to add as many things to that wish list as you want.
And you don't need to prioritize all of them. The only thing you really need to do is when you're ready to build something else, just take the thing off the very top of that wish list and build that. So out of that entire wish list, you just need to know what the most important thing is so that you can then build it when it's time to add to the project.
So it is recommended if you're doing like Scrum or if you're doing certain agile approaches, they usually do what's called grooming the backlog. They'll go through every couple of weeks or every month and they'll do that. And that, you kind of do you need to do that in a sense because how else are you gonna know what's the most important thing, right?
In that whole backlog. So every two weeks to a month going through and prioritizing things is a good way to do it. But another good way to do it is by just focusing on one thing at a time.
So you build this feature, you test it, you get the users to test it, you talk to them and see how they liked it and how it works for them. And then maybe you don't even have a massive backlog, but maybe you just, if you're the product owner, you ask the client, or if you're the client, you think to yourself, okay, what do I want next? Like what is the next most important thing here?
And sometimes it's obvious, sometimes it's maybe not so obvious. So what I would recommend doing in that case, if it's not really obvious, like what should I prioritize? Talk to the product owner or talk to the business analyst who's in charge of designing this app and start talking about your biggest pain points and goals, right?
And then ask them to recommend, okay, what do you think we should build next to solve my problem? That's really a good way to do it because a lot of times the issue is if you get too feature focused, you're focusing on features and then you're not able to focus on what really matters is why are we building these features in the first place to solve pain points and to achieve goals or achieve objectives of some sort? Like it comes back to the business goals, right?
The business use case. So going back to that and just really asking, okay, where we are right now with this app, what is the next most important thing that will give us the highest ROI in the shortest amount of time? You know, like what are our main pain points and goals?
Like asking those type of questions makes it much more clear what you should build next, right? Because it's getting back down to brass tacks down to the business needs.
[David Guthrie] (27:22 - 28:06)
So what are some of those impacts of scope creep? You know, we kind of talked about what happens a little bit during the project, but you know, if you have too much scope creep, obviously that's gonna affect timelines, it's gonna affect budget. You know, maybe it affects the quality of what you end up developing.
And I imagine it also could prevent them from developing some of the features that they really wanted because they spent too much time and too much effort on some things that, you know, the feature was a high priority, but then they expanded the scope of it in ways that maybe they didn't really need to. Can you think of any examples of that kind of thing and you know, how you kind of manage that process with the client?
[Calvin Smith] (28:07 - 32:33)
Yeah, so yeah, you brought up some good impacts. Obviously budget, you know, budget is gonna expand, you know, timelines expand, then you can't afford to build the features you wanted. There is another one that's really interesting actually, and that is you actually end up building a worse app if you have too much scope creep, right?
So you might think, well, why would that be? You know, we're just adding features. So even if we, like the main problem there is just either budget or that we didn't get to a feature we needed, right?
But how could the app actually be worse? And the reason the app can actually get worse for the users if there's a scope creep is because it's because it gets either too complicated for them, it gets confusing, or the features that you're giving them are not the right features that either they need or they're not done in the right way that makes life easy for the users. So you may have used apps in the past where you just ask yourself, man, like this app is so poorly designed, you know, like you're just feeling like the app is poorly designed, like it's way too complicated, like it has all these unnecessary things that you don't need.
If you've ever felt like that when you're using like a web app, then it's probably partly due to scope creep because, you know, if you're thinking about, you're creating an experience for the user, right? So if they go into experience your app and they're bombarded with all these unnecessary features or it's too confusing for them to navigate around and find what they need, like if they're having a hard time finding what they need, then that's a problem that's gonna be worse for your users. And, you know, the business is gonna make less money because users aren't satisfied, right?
Or maybe employees aren't satisfied if it's an internal app. And a good example that I actually have seen recently is I don't know if anyone uses Zoom here, but if you go into Zoom and you go into the settings, it's just so complex and it's very hard to find what you're looking for. That sometimes can be unavoidable if you need every single feature that's in there and it's like, there's no way to, you have to have all those features because your clients want them and they need them.
But that's just a good example of what can happen if you have too large of a scope and, you know, everyone wants to add all these features and then, you know, only a small amount of the users actually use them. It can just be confusing and difficult for most users until they spend a very large amount of time in the app, actually learning where everything is. So that's one example.
Indeed, when I use Indeed sometimes in the past, I've felt like the way they've designed things is kind of difficult to find and also a lot of their features change quite a bit, which suggests to me that, you know, build an interface that they're happy with or that their customers are happy with. You know, if you want to look at an example of something that's well done, you know, you can look at, you know, Google products, a lot of Google products. I think Google Calendar is a good example of Gmail.
These are things that work very well, Amazon. Like if you go to Amazon, these are apps that may be complicated, but they were built in such a way to maximize the ease of use and to make sure that you have what you need. When you go into that app and you look for something, usually what you need is not going to be very far away and it's easy to find for the most part, right?
So that can happen with scope prep, just making the app too complicated, too many features that aren't needed. And it sucks because you paid for all of those features, right, and now your users don't like them. It's such a common thing.
Hey, we built this app, but our users don't like it because you didn't spend enough time testing like small pieces, like build a small feature, see if the users like it, see how they react to it, see, and if it's an internal business app, let's see, okay, can this new feature streamline our processes and solve our problem? Not enough time testing in an agile way and too much time, you know, writing documents of requirements and adding everything under the sun that you can think of to the app.
[David Guthrie] (32:34 - 32:49)
Yeah, makes sense. So if somebody is in the middle of a project and they realize that they've got a lot of scope creep going on, what should they do? How do you salvage scope creep?
How do you get back on track?
[Calvin Smith] (32:50 - 37:21)
So the first thing would be to basically do an exercise. It's like stop, start, continue. Is that the right way to phrase it?
So basically like, what are we going to stop right now? What are we gonna start doing? And then what are we gonna continue doing the same?
So there's some cost fallacy is something you gotta watch out for because if you've built some features, now you realize, man, like I thought this was just gonna be a small feature that we were gonna throw in there. We've been building this now for months and this feature is not done yet. What do we do?
If you fall victim to the sunk cost fallacy, you might say, well, we've already gone so far on it. We've already put so much money into it. Let's just keep going.
But you gotta ask yourself, are you actually gonna get the ROI you're looking for on the remainder that you're gonna have to spend building that feature? Forget about what you've already spent to build what you have so far. Ask yourself, how much more is it gonna cost to finish this feature and to get it working the way I want?
And if I was given a choice right now to pay that amount from the beginning, would it be worth it? And if it's not, just cut the feature and it doesn't mean the feature goes in the trash can forever. You can just put it on hold and that code is still there and you can come back to it.
Really, you're gonna have to cut scope. You're gonna have to ask yourself, what can we get rid of here or what can wait? That's the most important thing to do is just start cutting out features that either can wait or that you don't need at all.
And then likely if you're in this situation, you probably feel like your app is not up to par. Like you probably feel like what you have so far in your app is not doing what you want it to do for either your employees or clients. So then you gotta ask yourself, what exactly, what result would satisfy us?
What exactly does this app need to do to make us money basically, right? And you write down a list of things that if these, if this app can do these things, then it would be worth it for us and make sure that you cut everything off of that list that you can and only make sure it's only the very specific things that you need that you absolutely, that are absolutely essential. And then, hopefully your development team, hopefully you have someone that you can work with that's like a business analyst or product owner.
If you're just working directly with developers, it's gonna be very difficult because developers are not trained on how to design apps. Usually they're not trained on how to basically design features and manage scope, creep and all this stuff. Either someone internal to your company that's a business analyst or someone at an agency of some sort that you've hired to build this app for you.
You wanna sit down with them and talk about those few things that you put on the list and discuss with them how these could be designed in the most efficient and effective way. Making sure that they truly understand why you need those features, not just what the features are or like superficial things about the features. They need to really understand your business and why you need these built and what that result is gonna be.
And ideally they need to understand your business processes well as if they worked at your company basically so that they can think of different things that you may not have thought of. Like if this business analyst was an employee, let's say, and they were like head of product, like they're gonna know your business so well that they are going to be able to hopefully listen to the issues that you write out as your core pain points or needs. And then think of creative or novel ways to maybe build that into the app in the most efficient way because that's what they do.
They're product people, they design products. So that's what you need. Like if you have an agency, they should do the same thing.
Like they need to understand your business and design the solutions because there's many different ways to build any one solution. And maybe the way you thought of is not necessarily the best way to do it. There might be a cheaper, easier, and more effective way to do it.
So that business analyst needs to understand your business and then help you design those solutions that you're gonna then build.
[David Guthrie] (37:22 - 37:54)
So I guess to recap, if you're struggling with scope creep, you wanna do a start, stop, continue exercise, kind of decide where you need to be spending your time, reprioritize those things and redefine your MVP is basically what you're saying, right? Redefine what the minimum is that you need. Before then you can say, all right, let's keep going on developing those cool features or maybe automating part of this process further to maximize those gains, right?
So yeah, that makes sense.
[Calvin Smith] (37:55 - 38:53)
The whole concept of an MVP, minimum viable product is really designed to reduce scope creep, basically. Because it comes from startups, the startup world where they wanna get an app off the ground or a product off the ground, but they don't have a lot of money. They don't have a lot of time necessarily.
They have an idea. And so the question is, what is the minimum viable product? It's self-explanatory basically, but what is the minimum we can do to get the result?
And sometimes it's just a test. Like, can we just build something to test if this is gonna work? Other times they know they need it and they just need to ask, what is the minimum viable product to get this to market so that we can actually sell it?
That mindset is exactly what you need to overcome scope creep is knowing how to design a minimum viable product and knowing how to execute it so that you don't add these features onto it unnecessarily.
[David Guthrie] (38:55 - 40:08)
So I guess to recap my key takeaways from our whole conversation, scope creep is when the original plan that you have for your project, anything that falls outside of that original plan starts to happen in your project, right? So we talked about how you need some flexibility, but you should be able to plan and define your requirements well enough at the start to generally know what the scope of your application is, what it needs to do. So anything outside of that, you should try to avoid.
Some really good practical tips from you, Calvin, on what to do if you run into scope creep, how to manage it throughout the project. And I would just say to anybody listening, if you still have any questions or if you're thinking about starting a project and you wanna make sure that it's managed well, reach out to us. You can schedule a free consultation with us at ksenstech.com.
And we'll be happy to take a look at your workflow, talk about some of those pros and cons that Calvin mentioned, and be able to walk you through how to make your business more efficient, make sure it's scalable, and automate some of those manual processes. So this has been great. Thanks so much for joining me today, Calvin.
