What is Scope Creep?

Broadly, scope creep is when a project’s requirements expand beyond the original vision for the project throughout the lifecycle of the project. This is a concept that can be seen with almost all projects and especially with software development. The issue with scope creep is it can bloat timelines for a launch, it can increase application cost, and it can lead to indecisiveness and an unclear vision for the application.

We’ll discuss how to proactively protect your project against scope creep and also how to react to its manifestation mid-project. Note that we’ll mainly be discussing scoping and how it effects the MVP development of software products by drawing on previous experiences that we have had with our own applications and in our service work for others.

Prevention of Scope Creep.

The easiest way to “defend” against scope creep is too prevent it before you even start the development of your application. Commonly referred to as a requirements gathering phase or a discovery phase, there should be a concentrated period of time in which you determine what exact features and requirements you need to have in your application.

You can even take this one step further by designing mockups of your application, gathering assets like your logo and your branding strategy, and putting together a non-functional prototype.

Regardless, the outcome of this phase of project development is to determine essentially two things: what your application is going to do and what it is going to look like. If you can nail these two things down, you essentially have a great “roadmap” or, as we like to call it, a “blueprint” that you can refer back to when it is time to start writing code.

How we Utilize this in our Process.

At Benmore, a main focal point is our commitment and concentration on the discovery phase when we work with our clients. Discovery phases typically take between 4-6 weeks and include weekly calls with our team. We believe that if we are able to work with our clients to get them to a point, as stated above, where they know what their app is going to do and what it’s going to look like; we are then in a great position to move into development.

Specifically, we use Figma to design the core views or screens in your application, research and technically vet your application idea, and work with you to create a list of requirements. Once you are comfortable with the discovery phase, then we discuss development and timelines; knowing exactly what we’re going to build and what it’s going to look like.

Managing Scope Creep During Development.

So, we’ve developed a great blueprint, we know exactly what the application is going to do, should be smooth sailing from here, right?

Well, sometimes yes, most of the time no - but that’s not a bad thing. For example, let’s say you made an AI app that, let’s see, creates a yoga routine for users. However, halfway through the development of the application, you realize that users also want meditation sessions generated as well. So, you add this to the requirements list and expand timelines. That’s scope creep!

However, that’s not necessarily a bad thing, especially if it helps out your application. Your blueprint should never be too rigid and should allow for mobility as it is typically going to arise throughout development. However, how can you manage this so it doesn’t get out of control?

The key thing that you need to determine if you have an idea during development for expanding scope is: is it necessary? We think that there’s a pretty straightforward way to simplify this. If a potential customer has mentioned it, then it might be. However, when you are building an application, it’s important to understand that you are viewing it through your eyes, not your users!

When you think that a feature should be added, you should always do so cautiously. Specifically, you should understand that adding a feature will probably increase the timelines for your application and the cost as well. It’s also important to understand that if you haven’t asked essentially over a hundred potential users, you’re pretty much assuming that’s it is something that most users would deem as needed.

So, it’s important to weigh all of these factors in before making a call on a feature expansion and determine if it actually makes sense to develop.

How we Utilize this in our Process.

We set up our development structure to be as accommodating as possible when it comes to feature expansion. Specifically, we bill, during the development phase, on a set monthly schedule. This means if you request a feature to be added to the project, we don’t have to revisit a discovery phase; we simply give you a timeline for the additional feature and inform you on the increased timelines and cost.

Furthermore, any developer that you are dealing with from our team is the owner of the project, meaning you have the actual person building your application making the timeline extension estimations and calling the shots. This, in our opinion, is most effective because the developer, who is building your application, is going to be most in-tune with the codebase and ramifications of a feature request - making them most qualified to inform you on the extended timelines and impact of a new feature.

Furthermore, all of our developers are full stack, meaning that, unless necessary, we don’t pull back in the design team or the product lead to reopen the discovery phase. Our developers have the skillset necessary to make design decisions on the fly and stand as independent developers who don’t need to fallback on other team members to move development forward. All of our developers are briefed in our “forward deployed developer” methodology which puts the developer at the forefront of the project and in direct communication with you throughout the entirety of the project’s lifecycle.

We took inspiration for this model of development from Palantir’s delta developers. You can read more about the methodology here:

If you want to learn more about our process or have an idea for an application that you’re ready to get started on - book a call with us!

Let’s get started! Book a free consulting call: