How to Control Project Scope and Avoid Scope Creep

You’ll get into the implementation phase of a project at some point. You need to start to control the project scope right away. Most of all, you need to focus your attention on scope creep. 

I’ve been managing software development projects for more than 11 years. Controlling the project scope is arguably the most challenging project management activity. So let me explain how to do it in the real world.

What is a Scope Creep?

Scope creep is a change in the initially planned amount of work. It can be an additional work package or deliverable. But likewise, it can be extra tasks that the team needs to do to finish a known deliverable. 

There are many root causes of scope creep. For example:

• Project owners want to add new features to the product. 
• You missed identifying a deliverable in the first place. 
• Project owners may wish to adjust requirements after seeing the product you created. 
• There might be a miscommunication about what is outside the project’s scope. 
• You misjudged the complexity of requirements or the impact of a change.

So, as you see, scope creep may come from project owners, from your side, or even from things that are not under your control. 

Scope creep happens on all projects to some extent. But when you lose control of it, you delay your project, and additional work requires more budget. 

As a result, project owners and your boss get frustrated. And they all start to micromanage you. 

What Does it Mean to Control Scope? 

Control Scope is a set of processes and tools that help you to ensure the scope of work doesn’t change much compared with the initial project plan. Also, these processes help you to include changes that you agreed with the project owners.

Here’s the biggest idea behind controlling project scope:

Whenever there’s a change in scope, you want to reserve the right to change the project timeline or budget. 

Pause here and think about it for a second. 

In practice, you need to have a soft agreement with project owners that if they want to add some work to the project’s scope, you’ll get an opportunity to estimate it and request the required time and money.

Many tools can help you control scope creep. Let me explain how they work and when to use each one. 

Use Project Charter as a Business Justification for a Change

So, the first line of defense is a Project Charter. 

The project charter is a document you create at the start of a project. It contains high-level information about the project. In essence, it sets goals and boundaries for the project. 

By the way, you don’t need a formal document. But you do want to collect information that a project charter contains. Moreover, you want to ensure that project owners see this information the same way.

As it relates to scope creep control, you are most interested in the project’s business case. And the idea here is simple:

Whenever there’s a need to change the scope, you should check whether this change aligns with the business case.

Moreover, does this change help us to reach the project objectives? 

If yes, we can negotiate the change in the project timeline and budget. However, if the business case doesn’t support the scope change – you should reject the change. 

Example of Using Project Charter to Control Project Scope

So, for example, a project’s business case is to quickly fix several defects in our product and release a new version. Users are complaining a lot and requesting refunds. We are losing money right now!

Then, a CTO of the company comes and requests that we have to add a technical feature to this release. It will help discover and fix defects faster. 

While this additional feature is valuable, we should reject it because it doesn’t align with our main business case. Nevertheless, it’s a great candidate for the next project. 

So, project charter and business case are your first filter. However, it’s a high-level filter to focus project owners on their own business objectives.

Use Project Scope Statement to Set Project Boundaries

After creating a project charter, you: 

1. Start collecting requirements.
2. Come up with a project life cycle.
3. Learn the best practices of your industry. 

So, in essence, you gain a better understanding of what you need to produce as the result of your project. At this point in project management, you should be able to describe the main deliverable of a project. 

A deliverable is a tangible and verifiable piece of a project that you must create to reach the project objectives. 

So, you need to describe all the project deliverables in a Project Scope Statement. The key here is to share your improved understanding of the project with other stakeholders. 

You need to capture several more pieces of information in the scope statement. But, again, it’s just a more detailed description of what you had in the project charter at the beginning. 

Nevertheless, once you show the project scope statement to the project owners and they accept it – you have an agreement not to change the project scope without negotiations.

https://youtube.com/watch?v=f2IdKUGl0zE%3Ffeature%3Doembed

Example of Avoiding Scope Creep

So, for example, you develop a software application. But, in the scope statement, you don’t have a PDF quick start guide. Or even better, you put it into the exclusion section. 

Now, if the project owners come to you and ask where the Quick Start Guide PDF is, you can point to the scope statement and say it’s not in the project’s scope. 

Again, it’s not a super detailed document. The scope statement describes only the main deliverables of the project.

Use Requirements Traceability Matrix to Triage Requirements

So we have an understanding of what our deliverables are. Now, we need requirements that describe all the features, capabilities, and the look and feel of those deliverables. 

In the real world, we’ve been collecting requirements all the time until this moment. You do it in parallel with other project management activities. 

Nevertheless, you want to connect all the requirements you gather with business objectives from the project charter. 

Here’s a critical thing:

You can create one and the same deliverable with different features and capabilities. Not every smartphone should be an iPhone. So, you must ensure that all these features pursue the project’s business objectives.

The requirements traceability matrix is the tool that helps you control scope creep on the requirements level. It will help you eliminate requirements you don’t need and can help scale down requirements to the desired level. 

It will also help you to build a case when not to include a change request.

Example of Avoiding Additional Scope of Work With RTM

The business case for the project looks like this:

Our company needs a web site that clients will find on the internet. That’s why we decided to invest resources in content marketing. It means we need a blog. 

To start appearing in search results, we need to start the blog as soon as possible. A simple blog with text and images is all we need right now because the content is more important than looks.

In essence, we can break it down into two business objectives:

1. Create a company’s website (blog). 
2. Do it as fast as possible. 

Now, when it comes to requirements, we’ll need to specify the following:

1. Hosting (it’s where the site physically sits).
   1. Expected number of visitors for the first year.
   2. Expected annual growth of visitors.
   3. Budget.
2. Theme (that’s what you see on your screen).
3. Content Management capabilities. 

Even though the business case says we need a “simple blog,” we still need to have specific requirements. Otherwise, no outcome will feel like “it’s what we expected.”

You can capture these requirements in the RTM. They can easily fall under the “Create a company’s website” objective.

Imagine that a newly hired editor for this blog comes to you one day. He says, “You know I want to include a popup on our blog to collect emails immediately. So please add it to the scope. And let me know the timeline for it.”

(Sooner or later, you’ll see what a “popup means.” It will appear on this page as well;) )

So, here’s the proper way to work out this situation: 

First of all, you do capture this requirement from the editor. It might be a great idea. It might fall under the business case. Project owners may see it as a critical point for the project’s success. 

Here, it’s important to mention who asked for this requirement. 

Second, you need to question it because it’s hard to connect this requirement with either business objective. 

Third, if you are already in the project’s execution phase, it’s a change request. So you need to treat it appropriately.

That’s why you need to communicate this requirement to the project owners. But your message should state your project management position. For example:

“I received a new requirement from our new editor. However, it needs to be aligned with our business objectives. Therefore, we should postpone this improvement until the next project.”

Let me know if you have other thoughts on this requirement. Then, we can discuss the impact on our project plan.

Other Critical Benefits of a Requirements Traceability Matrix

Later, you also want to connect requirements with deliverables. You want to know in what tangible and verifiable piece of the project you can test a given requirement. 

And you want to ensure that you don’t forget to capture some work you need to perform to implement each requirement. 

There are many other ways to leverage the requirements traceability matrix on a project. So, I do recommend learning more about it.

Control Project Scope with Work Breakdown Structure

OK, now we have requirements and major deliverables describing our project’s desired results. 

However, all of these are not suitable for project management purposes. 

So, we need to break it down into smaller, more manageable pieces. That’s where we want to create a work breakdown structure. 

In simple terms, a WBS is a tool that helps you to decompose your large deliverables into smaller pieces. It’s a huge topic in itself, so you may want to review this article too:

What is a Work Breakdown Structure and How to Create it?

You break the project into smaller pieces, and it becomes your baseline to control the project scope. If you notice that new pieces of work appear during execution, that’s a scope creep. 

In most cases, you’ll need to analyze this new scope and make a decision if you need to adjust the whole project plan.

Avoiding Scope Creep is all About Planning How to Manage Scope

I want you to pause now: Do notice that most of the activities and tools I described so far are from the project’s planning phase. 

It means that you need to think about how to control project scope and how to avoid scope creep right from the beginning.

If you don’t lay this foundation, you can use only the remaining third level to control the project scope.

Last Line of Defense: Task Tracking

The idea is that you break down the project into smaller pieces. Then, you break down these pieces into tasks. So now, you need to ensure that you identify all the tasks required to create this piece of the project. 

As I said, if you don’t have other measures, you can control the project scope only by ensuring that no new tasks appear.

So, for example, it looks like this. You ask your team member, “Hey, John, did you document the workflow?” And John says, “Oh, I didn’t know I needed to do that. It’ll take an extra day. I’ll create a new task.”

And suddenly, you realize, “Wait! We have 17 similar deliverables. All of them need a documented workflow. It means we’ll require 17 additional days!”

All these tools to control the project scope are connected to each other. But more important is that they are connected with many other project management tools.

Get My Scope Management Template

Unfortunately, this article was just one piece of a complex project scope management framework: Many other processes happen before and after this one.

If one part doesn’t work, the whole system breaks.

My Scope Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on scope management. 

Don’t put your projects and reputation at risk. Ensure you know how scope management works in the real world.

All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Scope Management Plan Template.