Jory MacKay
Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.
December 20, 2022 · 9 min read

How to change your project’s scope (the right way)

🎁 Bonus Material: Free Scope Change Request Template

How to change your project’s scope (the right way)

While there’s no such thing as the “perfect” project plan — studies show that mid-project scope changes are still one of the leading causes for project failure. But in a profession where change is inevitable, often the real reason for failure isn’t the scope change itself, but instead, it’s poorly managed scope changes.

While it’s important to define your scope clearly, it’s equally important to have a plan for unplanned changes.

In this guide, we’ll show you how to analyze a scope change and decide if it’s valid (or just scope creep in disguise) and then give you a seven-step process for successfully changing your project’s scope.

What are scope changes? When are they valid?

Before we can discuss scope changes, we need to be clear on what we mean when we talk about a project’s scope.

A project’s scope refers to the combined set of outputs, outcomes, and benefits of the project and the work required to deliver them.

Put even more simply, scope answers the “what?” questions for your project:

Answering these questions is how you build a scope of work and is an essential part of defining your overall project plan. However, even the best laid plans can come crashing down if you’re not prepared to deal with changes.

Scope changes are any deviation from your original scope. This could include adding new features, changing functionality, moving your go-to-market date, or even removing work from your scope.

Yet, while there’s a common belief that all scope change is bad, this isn’t the case. As your project progresses, you’ll learn new things about your audience and features, witness changes to the market, or shift your priorities. All of these changes move your project’s goalposts and are valid reasons to adjust your scope.

What causes scope change?

But how do you know if a scope change request is coming from a valid place? Typically, there are five different ways to qualify a scope change as legitimate:

  1. Information-driven changes. As more information becomes available, you may learn that your scope is too aggressive or won’t go far enough to deliver the right outcomes.
  2. Budget-driven changes. As your project progresses, you may learn that you need more budget to hit your goals or might even have your budget taken away. To adapt, you may need to change your scope.
  3. Schedule-driven changes. Your project sponsor may decide you need to deliver faster to not block other work. This will lead to you having to adjust your scope accordingly.
  4. Resource-driven changes. If resources change on your project, it may enable or inhibit you from delivering more or less scope.
  5. Quality-driven changes. Especially after delivering prototypes or proof of concepts, you may realize quality needs improving, and thus your scope will need to increase.
In a profession where change is inevitable, the real reason for failure isn’t a scope change, but a poorly managed scope change.

How scope changes can kill projects (without a process in place)

While scope change isn’t inherently bad, it can kill projects (even Agile ones) if it isn’t managed effectively.

Get your scope change wrong, and you could face any of these consequences:

  1. Project rework. If you don’t anticipate and plan for scope changes, it can cause layers of rework. Rework slows you down, causing you to go over schedule and likely over budget too.
  2. Damaged stakeholder relationships. As the project manager, you need to know when to accept and decline scope changes. Get this balance wrong, and you’ll create tension with impatient stakeholders.
  3. A demoralized project team. Too many scope changes can cause your team to become frustrated, leading to a lack of motivation and momentum. After all, it’s hard to operate effectively when the goalposts keep changing.
  4. Additional risk. Poorly managed scope changes create risks for the entire project. Decide to take a new direction on a whim, and you risk further complications, delays, and expenses for your project.
  5. Reduced benefits. Scope changes should only be agreed upon if they add additional benefits or if they lessen the risk of benefits being lost. Let a rogue scope change in, and it can destroy your benefits, either by taking you over budget or by negatively impacting your outputs.

Traditional project management techniques (sometimes called waterfall) taught people to define their scope upfront and not accept changes as projects progressed.

As we now know, that approach isn’t always practical and causes many projects to fail. That’s why, in the last 20 years, agile project management has become more popular as it enables project teams more flexibility to change and adapt as they progress.

Are scope changes and scope creep the same thing?

When talking about scope changes, many project managers and developers automatically think of scope creep. Yet there are massive differences between scope changes and scope creep that mean they shouldn’t be used interchangeably.

Scope creep is defined as any uncontrolled changes in a project’s scope during its lifecycle.

Scope Creep is Bad for Everyone!

While scope changes are planned, vetted, and properly included into your upcoming sprints, scope creep is forced on your team with no recognition or understanding of the rest of your scope.

Here are a few more ways that scope creep and scope changes are different:

Scope change Scope creep
Definition: Scope change is when you decide to change your scope from the original baseline at any point during the project. Scope creep refers to any uncontrolled changes in a project's scope, at any time during the project’s life, away from the original baseline.
Why it happens: Scope change happens for a reason that’s agreed upon by the entire project team and is backed by data or context. Scope creep doesn’t necessarily have a reason, it just happens (usually without noticing).
Who’s involved: Well-managed scope change requires involvement from project stakeholders, team members, and sponsors. Scope creep is either imposed by an outside stakeholder or naturally “creeps” into your project.
Impact: Proper scope changes can positively impact the project’s budget, timeline, or quality. Scope creep is almost always bad. It causes delays, rework, misalignment, and additional costs.

The crucial difference between scope change and scope creep is management and control. Scope change is an intentional decision, taken as a team, that’s planned for. On the other hand, scope creep happens when project managers lose control and don’t set strong boundaries.

When it comes to scope, projects fail for two reasons. They either fail to effectively change their scope when needed (change) or their scope changes when it wasn’t supposed to (creep.)

An easy scope change management process (7-steps)

The key to delivering excellent scope change is to manage the process effectively.

Here’s an easy seven-step process to guide you through scope change management.

Step 1: Educate your team on the concept of scope change

Knowledge is power. Start by educating your project team on the importance of scope change management. This will help your team understand that scope change is allowed and give them the confidence to identify and discuss it in the right way.

How to do this:

Step 2: Create a scope change template and process for any requests

Now that the team is on board, you need to define how scope changes will be raised and considered. The best way to do this is to create a consistent scope change template for any stakeholder to put forward a change request.

How to do this:

Step 3: Record all scope change requests (even ones that don’t happen)

Another pillar of good scope change management is to create a central change log in a project management tool like Planio.

This helps you keep a record of all requests and provide a valuable audit trail for project closure. It also shows that all ideas are considered equally and documents where you decided not to proceed.

Change Request for building project to prevent delay of deadline

How to do this:

Step 4: Create a scope change forum for evaluating requests against your project’s goals

Once a request is submitted and logged, you will need to evaluate it as a team. Many projects have a change control forum, made up of key stakeholders, to review requests and their effect on the project’s goals.

How to do this:

Step 5: Know who needs to approve any changes to your scope

Everyone has a boss, and your project is no different. To arrive at a final decision on the scope change request, make sure you know who has the authority to approve a scope change.

In most circumstances, it will be your project sponsor, but for larger projects or programs, it may be an entire project board.

How to do this:

Change is inevitable. It’s how you deal with it that matters.

Step 6: Add approved requests to your backlog or next sprint planning session

If a scope change is approved, it’s time to get it baked into your project schedule. Naturally, you need to do this in a considered way, so it makes sense to factor it into your next project planning round, such as a backlog review or sprint planning session.

How to do this:

Step 7: Test, learn, and review your scope change process

Managing scope change in the right way is super important for the success of your project. You’re unlikely to get it entirely right the first time, so take the time to reflect on the process after every new request has gone through the system. Update the steps, templates, and forums to ensure they work for you.

How to do this:

How to integrate scope changes and keep your team happy

Scope change doesn’t happen in isolation — it’s part of your wider project ecosystem. To keep your entire team happy, ensure you integrate and socialize scope changes in these three ways:

  1. Project status reports. Call scope changes out in your project status reports to ensure all project team members and stakeholders are in the loop.
  2. Use project management tools. Keep your change logs and a record of all changes in your project management tool so everyone has visibility. Planio can help you and your team do this seamlessly with modules for task management, knowledge management, file storage, and team chat all in one place.
  3. Promote a change-positive culture. As the project leader, make sure you continually promote a change-positive culture within your project. Remember, scope change isn’t inherently a bad thing, and in many cases, it’s actually the right thing to do to get the best results.

Change is inevitable. It’s how you deal with it that matters.

For many years scope change was seen as a surefire road to project failure. But in a profession full of uncertainty, the only thing you can truly guarantee through your project life is that something will change.

To succeed, it’s how you deal with scope change that matters. The best project teams implement a robust scope change process built on a consistent process, thorough evaluation, and careful change integration.

If you want to do the same, we recommend putting Planio at the heart of your scope change framework. After all, there’s no better way to manage change than through a centralized, easy-to-use platform that’s tailored for agile project management teams.