Why Scope Creep Happens and What to Do About It

Scope creep is what happens when an unplanned for change or new request interferes with the progress of a project. In this post, you’ll explore seven reasons why scope creep happens and learn how to repair these gaps in your process before it’s too late.

For instance, you’re halfway through developing an app when the client emails your project manager about getting a new feature added. The PM eagerly agrees to add the request since it “shouldn’t take too long.” Whether or not that’s the case, the deviation from the original scope of work throws everything out of whack.

The developer continues working on the app, though often stops to check in on the rest of the team to try and anticipate what this new feature will do to the app. The designer steps away from their other projects in order to quickly mock up the new feature. And the project manager tries to figure out how to shorten the remaining deadlines in order to hit the promised delivery date.

Bottom line: scope creep affects everyone involved in a project. Not only that, it adversely affects project timelines and profit margins. And, if the changes are big enough, scope creep can even affect the work you’re doing for other clients.

Scope creep is, unfortunately, a common occupational hazard for designers and developers. But it doesn’t need to be. Here’s what you can do about it.

How to Prevent Scope Creep

It’s easy to blame clients for throwing your workflow into disarray or trying to add more to their app than the original scope called for. In reality, though, scope creep stems from a lack of control you have over your process.

Here are some of the ways that scope creep can affect your app development process and what you can do to prevent it:

Scenario #1: No Contract

You have no contract or scope of work to clearly define the project, deliverables, costs, etc.

In some cases, it might seem okay to take on a new client without a contract. Perhaps you worked with them before or they’re a friend of a friend. Regardless of your relationship with them, or what how easygoing they seem at first, you need a contract to protect both them and yourself.

You can easily create a contract with a tool like AND.CO:

AND CO’s software allows app design teams to create contracts from its premade templates. All you need to do is fill in the pertinent details about the project. 

By using AND.CO’s template (or creating your own), you’ll never have to worry about leaving out important details again.

You can also use AND.CO to attach an SOW to the contract:

An example of a scope of work created inside AND CO contract software. This can be attached to any contract to provide clearer details on what a project entails.


You can get even more granular by including a list that contains:

● An explanation of the project
● Things the client is accountable for (like providing logins, files, etc.)
● Project stages/phases
● App deliverables
● Deadline

Once you have your SOW nailed down, carefully walk the client through it before they sign the contract. This ensures that you accurately captured the goal of the project and that they agree with what you have planned for it.

With a contract and a scope of work (SOW), you get a chance to set the stage for what’s about to happen. This lets the client know what to expect in terms of costs, deliverables and timeline. This also provides a clear framework for your team to work with in terms of the app’s goals, features to be included and so on.

Scenario #2: Deadline or Budget Is Too Tight

The original project was scoped out, but with too tight of a deadline or too small of a budget, leaving no room for error.

When a client comes to you (or your account manager) and says they desperately need their app to be done in four weeks, of course you want to be able to say “yes.” But it’s a bad idea to commit to something that you and your team can’t reasonably deliver on. Or to commit to something where the margin for error is so low that you’re bound to lose money on the job.

Before sending a contract to your client, make sure someone has done a careful cost/profit analysis to determine how much time your team needs in order to create the app they desire and how much money the client should pay in order for the job to be profitable.

Then, be honest with the client if they try to push back on pricing or timeline. For instance: “We could do this in four weeks, but we’d have to remove Features A and B, and we wouldn’t have time for testing.”

If you show clients what their compromises will cost them, they won’t ask you to shrink the budget or deadline again.

Scenario #3: No Change Control

Your process lacks a proper change request workflow.
First and foremost, your contract needs to include a clause that anticipates feedback. Here’s an example of the terms your contract might lay out:

An example of the terms AND CO enables designers and developers to define in their contracts. This contract snippet explains the feedback limitations and info on how change requests will be handled.

“Feedback” limits how many times your client can provide feedback on what you’ve asked them to review. This forces them to really think about what kind of input they’re providing. This, in turn, will result in more useful and consolidated feedback instead of a never-ending barrage of vague or unhelpful feedback like, “Maybe the Analytics tab was better the way we had it before.”

“Changes” is a very basic statement regarding your change request process. I’d recommend bulking this section up, so you can make it perfectly clear when a change request is required and what it will do to the project. (This is why a scope of work should always be delivered alongside a contract.)

In other words, address things like:

● Will new feature requests or a design overhaul pause the project?
● Does the client owe any penalties for requesting a change?
● How will the timeline be affected?

Use your contract to provide details on your change request process. Then, be sure to remind your client throughout the project of how their requests will impact their ability to start making money from their app.

It’s not just your client’s understanding of how change requests work that can lead to scope creep. Change control can go off the rails by not having your own stringent process to manage it. An intuitive project management tool like Wrike would be useful, in this case.

What’s especially nice about Wrike is that it comes with a form builder tool (which you can learn about here). Use this to create a change management form that clients use to submit all change requests.

Scenario #4: The PM Always Says “Yes”

The project manager is unwilling to set or reinforce expectations with clients and instead says “yes” to everything without adjusting costs or timelines.
An iron-clad contract that your client has signed is a good place to start. But that doesn’t necessarily keep your project manager from being a pushover.

To prevent your PM's from allowing scope creep to happen, you’ll need to provide them with training on client management. Being able to say “no” or to explain how flip-flopping affects the project outcomes is an important skill for project managers. If they’re unable to control the client, no one else will either.

If that doesn’t work, you’ll need to find someone who understands the importance of setting boundaries with clients and following your processes.

Scenario #5: Too Many Cooks in the Kitchen

The client brings other decision-makers into the project, which holds things up and forces the project to go off the rails.
Clients pay you to build their apps because they don’t know the first thing about app development. That said, it’s that lack of knowledge that can cause problems with them down the line.

Unless you have their total trust, a nervous or insecure client may turn to others for input about the work you do. They don’t know anything about app development, so maybe their spouse who works in marketing does. Or their business partner who had an app developed last year wants to weigh in. It’s when they start turning away from you and bringing others into the feedback loop that things can get messy.

To get a handle on this, you need to take control of the project from the very get-go and demonstrate your authority. You are the app developer and know exactly what you’re doing. Put them at ease by showing them other apps you’ve created and be transparent about what it is you’re going to do for them. Basically, don’t give them any excuse to seek someone else’s input.

Scenario #6: Client Isn’t in the Loop

The client isn’t looped in for feedback until the very end of the project.
Clients can be difficult to work with, that’s for sure. However, it’s a bad idea to develop an app without their ongoing review and feedback.

For starters, when the client fails to hear anything on your progress, this is just cause for concern. And with concern comes distrust, which is going to make getting their buy-in very difficult.

Secondly, if you hold off on showing them anything until the end, you run the risk of having to deal with costly reworks when they decide they don’t like the direction you took the app in.

I know it can be annoying and stressful having clients weigh in on things like copy, design and functionality, but you’re more likely to get their approval if you keep them involved in the project.

Scenario #7: Inefficient (or No) Collaboration Between Team Members

Your app development workflow looks more like a rush to complete individual tasks than a collaborative effort to create an amazing product.
Speaking of communication, it’s not just isolating yourself from the client that can lead to scope creep. So, too, can team members isolating themselves from one another.

Great apps are not built by teams who deliver design, copy and code. They’re built by teams that work together to create a product.

So, the first thing to do is give your team a dedicated channel to talk to one another through. Slack is a good option, as it’s easy to organize based on projects, team members can chat in real time, and it integrates with your other business tools like Wrike.

Set up a dedicated channel in Slack so that your team can more effectively communicate and collaborate.

Another thing that improves team collaboration is hosting a kickoff call at the beginning of a job.

Zoom is a great tool to do this with as it allows you to share your screen during team calls:

Zoom gives users the ability to share their desktop, their browser, their mobile device screen, or draw on a whiteboard.

This way, everyone can review the information and materials in real time together and clear up any confusion there might be before starting. It also starts each project with the mindset that “we’re all in this together” instead of every man or woman for themselves.

One other thing you can use to prevent scope creep is to adopt handoff tools that make it easier for your team to collaborate.

Unite UX, for instance, is a tool your designers and developers can use to seamlessly translate an app from design into code. Not only does this simplify the handoff, but it shortens the time your team has to spend on building a product. That way, if change requests or issues do arise, they won’t have as much of an impact on the deadline.

Wrap-Up

As you can see, a lack of process and control over projects is ultimately what leads to scope creep. So, if you want to stop losing money on jobs, disappointing clients and frustrating your team, use the above tips to clean up your workflow.