What is it called when the scope increases during the course of a project?

Project scope creep…the mere sound of the phrase is insidious and sneaky. And that’s how it happens, sneaking up suddenly and hitting you and your project where it hurts.

We all need to be careful about dealing with increasing or changing scope in order to avoid nasty surprises. In this article, I’m going to discuss:

I’ll be delving into real-world examples of scope creep in agile projects—where there isn’t even a fixed scope to begin with. Also important, I’ll talk about the positive aspects of a changing scope and arm you with a sound approach to embrace it. Because scope change can be good!

What Is Scope Creep?

So what is scope creep, exactly? Simply put, it occurs when the scope, deliverables, or features on a project expand from what was originally set—without being accounted for in additional time or budget. It can affect any fixed scope project. It’s a very common thing, as it can happen both intentionally and unintentionally, stemming from any number of the people involved in a project.

Unfortunately, scope creep can lead to project failure: maybe you don’t hit the deadline, you burn through the entire budget (and more), and all without delivering the right thing. And who wants that?!

How Does Scope Creep Undermine A Project?

Has it happened to me? Yes, plenty of times! Here’s a quick scope creep case study from my experience to illustrate how easily it happens—and how it doesn’t always come from a direct client request:

Case Study: My Experience With Scope Creep

I inherited a project with a more classic Waterfall setup: there were wireframes and a design phase, which then moved into the project development stage. I picked it up as it was entering development. It was straightforward enough: we were building the frontend on top of a white-labelled backend from another agency. We had signed off wireframes and designs and had run through everything with the client and agency…what could possibly go wrong?

Well! It turns out that the other agency was iterating on their backend build and frequently releasing new code. Funnily enough, they didn’t account for us building on top of the old code, so our code broke with every release… *deep sigh*.

This meant we had to go back through our code, updating it to work with the continuous changes from the other agency. This was unaccounted for—but it was work we had to do. At first, we did the odd, small fix on an ad hoc basis, but more and more problems started to occur. Although we raised this with client, we tried to fold the extra work into our project rather than flagging to the client that we needed to determine a solution together before proceeding with the build.

Oh, the benefit of hindsight! What happened? We fell deeper and deeper into redeveloping the existing code—timelines got extended, we missed our deadline, and we came under a lot of pressure towards the end of the project. The team was demotivated, the client wasn’t happy, and none of this was actually our fault! In the end, the project was delayed by two months, a huge amount of time, unaccounted for. In the end, all we wanted was to wash our hands of it and forget it ever happened.

So, what could we have done?

The People Involved: Who Actually Causes Scope Creep

It’s useful to take a look at your project and identify who could be causing scope creep. This can help you to identify it early and determine your approach to solving the issue. Hint: it’s not always the client causing these issues, as you can see in my example above.

Team Member

Scope creep can come from people in your internal project team for a number of reasons:

1. The project team member is unclear on what the scope of the project is.

Ensure that at the beginning of the project, any requirements or deliverables are already outlined in a scope statement or project plan, and that everyone working in the team is fully aware of these. If scope is being set, make sure conversations involve the team that will be working on the project as much as you can. If that’s not possible, at the very least run a kick-off meeting with the team and make sure everyone is fully aware of what has been agreed upon. Then, during the project, make sure you hold regular team check-ins to keep everyone on the same page.

2. The team member wants to develop what they want to develop, and not what’s in scope.

People have much more understanding when they are involved—when they feel like they own it. Involving your team in setting the scope is really useful in getting their buy-in for what they’ll design and build. Make sure everyone is working as a team. If someone goes away to produce something out of scope because they want to, others on the project won’t be as invested in what is happening, causing friction and differing ideas on what the scope is.

3. The team member makes decisions in a vacuum.

Sometimes, team member chooses a way to solve a problem that has an impact on scope, often without realizing. Even adding a half day of extra work to do something slightly different could impact the rest of your project. For example, if a designer or UX person decides to include some functionality on a site without discussing with the developer, who knows what this could do to your overall scope, without any investigation?

Make sure you set your team up from the beginning of a project to work together and understand each others’ decisions. When someone raises a query or issue with you directly, share it with everyone if there’s a bigger decision to be made. Get people working together to define and find solutions to problems. Make sure everyone is in contact (whether face-to-face or remote) regularly. Most successful projects are enabled by teams that work well together.

Internal Stakeholders

Your project scope can be influenced internally in your organisation from key stakeholders. They might have a vision for the organisation that involves delivering more for your project, or they might want to push a different agenda. For example, sometimes a client relationship is more important to an organisation than staying within scope in your particular project.

Make sure your internal stakeholders understand what you are trying to deliver and by when. If something would have a knock-on effect on your project, clearly lay out what impact this will have—whether it’s financial, perception-based, or otherwise.

Users

User testing should (hopefully) be part of your project or product set up. User feedback on a product can influence a course of events that ultimately increases scope. What happens if you get feedback from your users showing that something that you can’t ignore? Even if it might increase your scope, it needs to be addressed.

When you’ve collated results from testing, review with your team to identify the necessary changes to implement. Prioritize so you understand which changes would have the greatest impact to the users’ experience. Then, work out what level of changes you can comfortably incorporate without affecting scope. If any of the necessary changes would mean increased scope, speak to your client or stakeholder about it. Also important is to make sure you have an understanding of what impact not implementing the change would have.

3rd parties

As we saw in my personal case study, dependencies coming from other parties can affect your feed. Whether that’s an external company, third-party APIs, content providers—if you are relying on anyone else externally to complete the project, you need to be aware of the impact they can have.

Make sure you identify your project dependencies when you kick-off the project. Try to think about what impact they could have on your project, and how they could affect your scope. For example, what if your content provider sent you content that wasn’t in the format that was easiest to implement or upload within the website. Could this add extra time your side? Obviously, you’ll never cover every eventuality—but having this risk-planning frame of mind at the beginning means that you can raise these dependencies at the beginning of your project with the client or stakeholder and ensure they understand the potential impact.

You

The biggest issue when it comes to you, the project manager, causing scope creep stems from the temptation to try and make things work within your existing budget and timeline, without flagging to your client or stakeholder. Yes, it can be a difficult conversation when you have to say you can’t do something unless you raise a change request and go through the official change control process—but this conversation is a lot easier to have earlier on, rather than down the line when you’re over time and budget.

Make sure you’re raising issues as soon as they happen, rather than waiting. If you or your team identify an issue, work through possible scenarios for different solutions, and present them to the client or stakeholder. For example, if extra work is necessary, see what can be descoped instead—is there anything you are doing in your project that isn’t needed for the first release?

Client

And yes, we can’t conclude this section without mentioning the obvious: the client. This one is in fact easier to spot, as most PMs are already primed to do so! Be aware of clients adding in small requests that gradually build up, changing their mind on what was agreed, or suggesting new ways to do things that can affect the amount of effort needed. Make sure you’re honest and upfront with them if they are asking for something that will cause scope creep. Also, frame your responses so that you aren’t just saying “no” all the time. Try to phrase it so that you are suggesting an alternative, for example:

“This new request is going to have this specific impact on time/budget. We’ve taken a look at the priorities—how about replacing this with that instead? It achieves a similar outcome because…”

10 Common Causes Of Scope Creep (And How To Eliminate Them)

1. 1. Not having a clear scope

Clarity is extremely important on any project. If you don’t clearly define your scope at the beginning, it can cause big problems down the line.

How to eliminate it: make sure the scope is clear to everyone working on the project. Involve your team in setting the scope so that they are bought into what they are delivering.

2. Not having client agreement

If the client isn’t bought into the scope, they are likely to change their mind—and the deliverables—later on.

How to eliminate it: ensure the client understands what is—and isn’t—in scope. Don’t just send a document outlining the deliverables—speak to them and walk them through it properly. Be transparent: ask questions such as, “Are you clear on what this deliverable is and what you’ll get?”

3. Not involving the client throughout

Gone are the days where you do a month or two of work and then send the final results of this period to your client for feedback. This results in surprises, with finalized work having to be redone, and impacts the project timeline and budget.

How to eliminate it: collaborate closely with your client. Show them the work in progress, iterate, and proactively involve them throughout the journey.

4. Not raising issues proactively

Hiding behind issues and not being transparent with the client or stakeholder seems easier at first, but you’ll come to regret it later on.

How to eliminate it: raise issues right away, when they happen (just make sure you’ve had time to work through some solutions first!).

5. QA needing more time than estimated

Ah, the age-old issue of QA estimation. How can you accurately estimate how many bugs will be raised, how long they will take to fix, and what impact this will have?

How to eliminate it: estimate a percentage of the development work based on the complexity of build, then add contingency. Don’t just throw a percentage at this—speak to the QA Analyst and get them to review. Additionally, pre-define the browsers and devices you’ll test against, along with the types of issues. This will help you refine your QA estimate. Also, consider using automated testing to save time—the articles Pros and Cons of Manual and Automated Testing and Best Automation Tools provide background on automated testing.

6. Not prioritizing among features

In a Waterfall-style project, your product will likely be built step-by-step until you reach the whole, shiny, new thing. This could lead to thinking everything is a priority. If you don’t have clear priorities among features, it’s hard to understand what can be descoped when adjustments to requirements begin to surface.

Side note: this is not a Waterfall vs Agile debate—that can be saved for a rainy day! Or see my article here on it.

How to eliminate it: prioritize features by identifying what’s necessary for releasing a usable product. Consider a more Agile approach where you build the minimum for release as quickly as possible: identify which features are absolutely necessary for users, and build a working product that can be tested and used by a customer at each stage.

I love this diagram by Henrik Kniberg and the accompanying article to highlight the approach above.

7. Not agreeing on how to handle change

If you haven’t agreed on how to handle change at the beginning of a project, it only makes sense that it’s going to be difficult to work through changes in scope at a later date.

How to eliminate it: outline in your Statement of Work (or similar document) how you’ll handle change. If you’ll use Change Requests, ensure you detail what’s in scope, what’s out of scope, and how to raise a Change Request.

8. Estimating poorly

Estimation is very difficult to get right. It’s a challenge to be accurate at the beginning of a project when there are many unknowns. Certain things may not get accounted for, and you end up tied to this extra scope to be able to deliver your overall project.

How to eliminate it: involve your whole team in estimation. Don’t work in a silo and make guesses. Ensure you’ve explored and determined client and business requirements against user requirements before estimating. Instead of estimating based on deliverables, look at the following:

• Estimate for a discovery period to determine what you’ll be building—at the end of this you can provide a more accurate estimate for the rest of the project.
• Consider using a Time and Materials pricing model rather than Fixed Price. Since you are billing actual hours on the project, it can be much more flexible. This handy article here which discusses benefits and uses of each.
• Don’t specify exactly what features are being built and how within the scope—allow room for change.

9. Not interrogating new requests

It’s easy to take on new requests or ideas from clients or team members, believing that they are the right path forward (Well, they do know what they’re doing, right?). If you don’t interrogate these requests properly you could end up accepting new scope, duplicating work or building unnecessary features without noticing.

How to eliminate it: review all new requests with the full team. Create a clear understanding of what the request is, the impact of incorporating it, and its outcome for the user. Then, prioritize the new request and cross check to make sure it’s not already being delivered elsewhere.

10. Not involving users early enough

I’ve seen many a project go to the final stages (and even past that) before actually putting it in front of real users. It’s tempting to fool ourselves thinking that we (the clients, the business, the team) know the users well enough to avoid interacting with them. If you’re not incorporating user feedback early on, you can go far down a route that doesn’t test well with users. At that point, your scope can suddenly spiral.

How to eliminate it: get users using the product or service as early as possible. If the client or budget holder doesn’t want to pay for this, work through the benefits and also the negative impact it could have by not performing this early user validation. Have a plan to address user feedback wherever it comes within the project.

How To Manage Scope Creep In Agile

Scope creep generally applies to projects with a fixed scope. What if I’m using an Agile methodology? Well, Agile embraces change—and frankly, so should you, if you’re working within different processes or methodologies. Change should not be seen as the enemy.

As one of the core principles of Agile states:

“Welcome changing requirements, even late in

development. Agile processes harness change for

the customer’s competitive advantage.”

If you’re working to Scrum methodology for example, when a new requirement comes in, pull it into the Sprint planning meeting and get it in the backlog. Prioritize it with the Product Owner and team, and if it does go into the Sprint, something else will be deprioritized instead. Because details aren’t determined at the beginning of the project, change can be incorporated. Stories can be swapped quite easily for other stories if they require the same effort.

The very point of Agile is to iterate, which means designing, building, testing, learning and then repeating the cycle. Change is what leads to the best possible product in the time you have.

So what actually counts as scope creep in an Agile project? Since you should have the ability to change scope quite easily without throwing the whole project to the lions, scope creep in Agile doesn’t really affect you until later down the line.

Scope creep could come into play if your Product Owner doesn’t deprioritize features or tasks when pulling something in—i.e. if they want to add something into the current cycle without removing something else. Also, they might not weigh the effort needed between the new task and the deprioritized one, which could results in trying to cram extra effort into an already planned, too-tight cycle.

Make sure that, for any new features entering the backlog, you’re breaking these down into stories effectively and understanding effort against them to prioritize accordingly. If you have a Product Owner who understands this process, scope creep will be much less of a threat. In general, it’s a lot easier to mitigate scope creep in an Agile project, precisely because change is encouraged and factored into the structure of the methodology itself.

Five Core Best Practices For Managing Scope Creep

1. Be proactive. Determine and agree upon a change management process upfront.
2. Prioritize. Look at what can be descoped to accommodate new requests.
3. Be transparent. As soon as scope creep appears, bring it up with clients and project stakeholders.
4. Analyze impacts. Work out the impacts (both positive and negative) of changes, and present solutions to your client or stakeholder in order to move forward.
5. Embrace it. Work out what’s necessary for a testable, usable product—if that means changing scope, look at ways to incorporate the changes.

See Scope Creep As A Positive!

In my opinion, it’s time to change the way we look at scope creep. Rather than seeing it as the sneaky enemy, we need to think of it differently. It’s not scope creep—it’s change. How you manage that change is what affects the project—not the request to change it. You just need to be careful that you spot it when it happens, especially when it’s not obvious, and raise it before it progresses without any form of replanning.

Change can actually be hugely beneficial to the product you’re making. After all, we are all here to build the best products and services we can, and if that means requirements must change, then we, as project managers, need to lead the way for adapting to this.

What Do You Think?

Have you got any examples of scope creep? How did you tackle it? Or have you seen it positively affect a project where you’ve incorporated a change in requirements and ended up with a much better outcome? Let me know in the comments below!

By Suzanna Haworth

Suze Haworth is a freelance Digital Project Director in London. She has over 14 years’ experience working in agencies, moving through the ranks from her early days in account management before seeing the light, and realising her true calling for project management. She now leads teams on all sorts of digital and web builds, ranging from social campaigns and digital media to large and complex websites. Suze has managed projects for clients like the BBC, WaterAid, Channel 4, Esso, Lipton Tea, SEAT and Mozilla, to name just a few. She is a certified ScrumMaster, a regular conference speaker, and can also be found posting blogs online. When she’s not directing and talking about digital things (and creating numerous Google spreadsheets), she likes to fuel her obsessions with mountains and coffee.

What happens if the project scope is increased?

What is scope increase?

What is scope creep in a project?

What is scope creep and impact?