« Back to Planio Blog

Jory MacKay on December 20, 2022

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

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:

• What work needs to be completed?
• What outputs will be created?
• What outcomes will these outputs drive?
• What benefits will the business receive from this work?
• What is “out of scope” for this project and should be ignored or avoided?

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.

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.

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:

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:

• Gather your team and discuss the concept of scope change and create a culture that’s open to considering changes. Ideally, you’ll do this at the start of your project, but if you’re reading this mid-project, that’s not a problem.
• Save this article and our article on Scope Creep into your project management tool’s Wiki so that teams can refresh their knowledge as required.

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:

• There are a whole host of scope change request templates out there, but as a minimum, ensure yours includes:
  • Project name
  • Change name/ID
  • Requestor name and contact information
  • Description of the change
  • Reason for the change
  • What the change impacts (e.g., which outputs/deliverables)
  • The impact on the project if the change isn’t accepted
• Specify where and to whom requests are sent. Most likely, this will be you as the project manager, or a senior team member, such as a business analyst.

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.

How to do this:

• Again, there are many change log templates to choose from. But, as a rule of thumb, your log should include all of the fields from your change request template, plus:
  • Request submit date
  • Request status
  • Request approve/reject data
  • Any comments
• This is a key document that will form part of your wider project management plan. As such, it should be owned and controlled by the project manager or a project assistant.

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:

• First, decide how often and when you’ll host a change forum. If you’re expecting regular requests, it makes sense to schedule them monthly like any other project ceremony. If not, better to do them ad-hoc.
• Next, decide who needs to be part of the forum. Ideally, you need all the right people who can make a rounded recommendation on the request — this may include finance, technical, and business user stakeholders.
• Lastly, when evaluating a change, remember to consider the pros and cons against every angle of your project, including:
  • Goals and objectives
  • Outputs and outcomes
  • Benefits
  • Costs
  • Schedule
  • Quality
  • Risk

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:

• You’ll have a pretty good idea who has the power to approve change requests, but if not, ask your sponsor. Remember, depending on the change, you may need more budget, extra time, or additional resources, so make sure your approver has that authority.
• Project sponsors are usually very busy. To make the approval processes easier, create a Change Request Approval Template that clearly defines:
  • The project name
  • The background (why the change has been requested)
  • The change request
  • What the change would need (e.g., more budget, more time)
  • What the change would deliver (e.g., reduce risk, more benefits)
  • The impact of not making the change
  • Your recommendation.
• Keep an audit trail of the decision to approve or reject the request and store it in your project’s file management system.

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:

• Get the team together as part of your existing planning cycle and introduce the new scope change into your discussion.
• Remember to treat scope changes the same way you would any other scope, prioritizing it accordingly against the other work you have to complete.

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:

• As a project manager, you’ll get a feel for how well your scope change control is going. Check-in on your comfort levels — if changes are causing you anxiety or stress, your process isn’t strong enough.
• Don’t be shy of asking your team how they think the process is working, too, focusing on feedback from the requester and approver as a priority.

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.