What is Scope Management (7 critical processes and tools)

Here’s a career development tip for you!

No matter the industry or size of a project, scope management is the most crucial aspect – you must become a professional scope manager first of all. 

Scope management is a combination of processes and tools that help to identify tangible and intangible project outcomes. After that, these integrated processes help to describe, control, and validate the work to be done by the project team in order to create those outcomes.

The scope of a project is all the work that’s needed to achieve its objectives. On a high level, you need to identify big tangible pieces that will comprise the final product, service, or result. On the lowest level, you need to identify individual tasks that team members will perform.  

Why Scope Management is Important?

Just think about it:

• Poorly specified requirements are the number one reason for project failure. 
• To create an accurate project budget or schedule, you must identify 100% of the project scope. Otherwise, you need to guesstimate.
• Risk management depends on the clarity of the requirements and scope of work. Ambiguity in scope leads to rework and unexpected expenses.
• Quality management is simply a part of the scope.
• The Work Breakdown Structure (WBS), Requirements Traceability Matrix (RTM), and project scope statement are the central pillars of project integration.

You got the point: Scope is king.

If you want to start delivering projects on time and within budget, you need to become an expert in scope management. You need to master the RTM, project scope statement, WBS, and WBS dictionary in addition to a structured scope management approach.

In this article, we’ll discuss the overall scope management approach. Then, you can dive deeper into each process and tool.

Requirements vs. Project Scope

Just to be sure we are on the same page, let’s clarify the difference between requirements and scope. Here are their definitions from the PMBOK Guide:

“Requirement is a condition or capability that is required to be present in a product, service or result to satisfy an agreement or other formally imposed specification.”

And:

“Project scope is the work performed to deliver a product, service, or result with the specified features and functions.”

What does that mean? 

A requirement is what a product should look like, what it should be capable of, its characteristics, behavior, performance, etc., while the project scope describes what work we should perform to create the results that meet those requirements.

There’s one more important definition: “Quality is the degree to which a product complies with the requirements.”

You need to clarify the quality level for your project. It’ll significantly impact the scope.

You see, the zero-defects approach is too costly. It requires a lot of effort to test and fix all defects. In addition, you need robust processes, workflows, and audits to achieve 100% compliance with all requirements. 

Therefore, in the real world, you need to reach an “acceptable” level of quality. Nevertheless, you need to include the efforts to achieve that quality level in your project scope.

How to Create a Scope Management Plan That Works

Your ultimate goal is to deliver what your customers believe they asked for.

Read that again!

Customers think that they clearly explained what they wanted from the project. You believe that you understood them correctly. However, that’s seldom the truth.

Before you start defining the scope of the project, you need to imagine the project’s end. How will you hand off the final deliverable to the project owners and make them accept it? Looks easy, doesn’t it? But, in the real world, it’s not easy at all! 

What will you do if a project owner says that it’s not what he expected? Of course, you can try and prove that you implemented all the requirements correctly. But it doesn’t matter because your clients are unhappy and will never do business with you again. 

So, you need to do more than just identifying and implementing 100% of the project scope. You need a scope management plan that helps you meet project owners’ expectations.

Moreover, I believe that you need to have a written scope management plan. But I won’t retype the whole template here:

Feel free to use it on your projects as a starting point.

Below is a structure for all your scope management efforts. You need to describe these processes in your plan.

Process #1: Collect Project Requirements

By this time, you already need to have a project charter. Or at least you need to collect the information that I suggest. You are looking for two things at this moment. 

First, you need a business case and any high-level requirements that you captured in the project charter.

Second, you need to identify relevant stakeholders who can consider the high-level requirements. 

In short, you need to communicate with all of the relevant stakeholders in order to elaborate on high-level requirements. In the process, some will also help you to identify the overall solution and any additional requirements that you might have missed initially. 

If you find it hard to visualize this process check out this article: Requirements Gathering Example (Real Software Project).

And if you want to learn how to collect requirements in a systematic way, read this article next: How to Collect Requirements (as a Project Manager)

Keep in mind that you may need a separate specialist trained to collect and describe business requirements by this time (a business analyst).

Likewise, you need to select appropriate tools and techniques to capture all project requirements. For bigger projects, I recommend creating a Requirements Traceability Matrix (RTM).

Process #2: Identify Major and Minor Deliverables

You need to get creative with this step. There’s no straightforward way to transform requirements into tangible results. 

Next, you link requirements to these deliverables. Some requirements will require a separate deliverable. For example, project owners may require that you create a risk register and share it with them. This is a requirement of your project management approach. Therefore, this document becomes a separate deliverable. 

Most of the requirements will be for the end product or service. You can create several deliverables as separate modules of the final product. Or you can create interim versions of the product that incrementally includes more and more implemented requirements.

So, a deliverable can be an interim part of the product or service that stakeholders can test, play with, or inspect. Or it can be a project document that stakeholders need. In any case, it is something important that we need to create to finish our project. 

To describe major deliverables, we’ll create a project scope statement. This will ensure that we are on the same page with all key stakeholders on what needs to be produced.

4 Main Types of Deliverables

There are several types of deliverables that we usually need on a project. For example, to track our progress, set checkpoints, and adhere to dependencies, you’ll need to identify internal deliverables. You create them for internal use. You don’t usually hand off internal deliverables to project owners. On the other hand, to demonstrate your progress, get feedback on your work, and manage expectations, you’ll create external deliverables. 

All deliverables can be interim or final. You want to get feedback from project owners continuously. That’s why you provide an interim version of the final product or service. 

In addition, to make your project more manageable, you may want to break down major deliverables into smaller pieces, like minor deliverables and work packages.

To identify and track all these deliverables, we’ll need to create a Work Breakdown Structure and WBS dictionary.

Process #3: Create a Scope Baseline

Here’s a situation I want you to avoid at all costs!

Usually, when a project starts, you receive requirements in different forms, such as emails, PDFs, meetings, mock-ups, bug reports, etc. But you don’t have a reliable system to manage those requirements. You discuss different details with project owners, stakeholders, and the project team – although project owners usually don’t have enough time to review all the documentation and participate in all discussions. 

Then, you create a WBS. However, you use it internally and never show it to the project owners. After that, you break down the work into tasks and estimate the project. Again, this is all behind the scenes for project owners.

Now you present estimates for the project. Can you see there’s already a lack of transparency here? Project owners don’t know what work you actually estimated. If the estimate is close to the sponsor’s expectations, he’ll not dig into the details because he’s ready to spend that amount of money and time. He doesn’t want to waste his precious time. 

So, project owners blindly approve the estimates and the work behind them. But they all assume that you read their minds somehow – that you had ultimate knowledge of their business and pain points.

Now, here comes a problem. You start project execution and create the first deliverable. You show it to the stakeholders and they are shocked. It’s not what they expected at all! 

In the process, you also learn that they forgot about some requirements that need to be added to the project scope. Your whole project management plan is useless now. You need to make lots of changes right at the start of the project. 

Check out this video. It provides a great example of how I identify project deliverables:

3 Components of Scope Baseline

Why did things unravel in this way? Because you didn’t walk the stakeholders through the work you had planned. Instead, you assumed that you were on the same page. 

That’s why you need to involve project owners as much as possible when defining requirements. Likewise, you need to talk through all the high-level deliverables. Then, if they approve it, you’ll create a plan to produce those deliverables. 

To get this approval on the project scope, we need to set the scope baseline. This is the approved version of the project scope statement, WBS, and WBS dictionary. 

Setting a baseline is critical to protecting your plan during execution. Sometimes project owners will tell you they thought something was part of a project when it wasn’t. When that happens, you can refer to the baseline they approved. As a result, you can properly integrate this additional scope into the project by requesting extra time and money.

Process #3: Breakdown Deliverables into Tasks

Take work packages (groups of tasks) one by one for each separate deliverable and break them down into tasks.

If you use modern project management software, you’ll end up with the following structure:

Project Result:

– Deliverable 1

– – Work Package 1.1

– – – Task #1

– – – Task #2

– – – Task #3

– – Work Package 1.2

– – – Task #1

– – – Task #2

– – – Task #3

– – Work Package 1.3 (to put everything together into a deliverable)

– – – Task #1 (to integrate all work packages)

– – – Task #2 (to test the deliverable)

– – Deliverable 2

– – Work Package 2.1

– – – Task #1

– – – Task #2

– – – Task #3

– – Work Package 2.2

– – – Task #1

– – – Task #2

– – – Task #3

– – Work Package 2.3 (to put everything together into a deliverable)

– – – Task #1 (to integrate all work packages)

– – – Task #2 (to test the deliverable)

It’s a time-consuming process. You need to work with your project team and SMEs to identify all the work that the team needs to perform. 

Here you can review a real example of the decomposition process: How to Decompose a Project into Tasks (Real Example)

However, you should always keep in mind one critical concept:

You need to identify every task needed to fully complete a work package. Likewise, all the work in all work packages should produce the parent deliverable. Finally, when a team completes all the tasks, the deliverable should be in a state where you can hand it off to project owners.

Tasks should never float outside of a work package!

Process #4: How to Control Project Scope

It is not enough to identify 100% of the project scope in the beginning because it will change during the project’s lifetime. For example:

• A requirement was not fully clear, and you needed to add new tasks.  
• You didn’t identify all the tasks required to finish the work package in the first place.
• You missed a requirement completely.
• The team implemented a requirement, but there are a lot of defects.
• Project owners clarify the requirements, and it’s not how you understood it during planning.

The list can go on and on here. In all of these cases, you’ll need to add some work to the plan. When a deliverable does not meet expectations, there will be changes. It is your responsibility to prove whether the change warrants a formal change request. If so, it should be appropriately integrated. Otherwise, it is a defect and you must make amends – sometimes at the team’s own expense.

So, you need a way to monitor, control, and make changes to the scope.

The WBS helps you a lot here. First, you’ll control the actual work on the work packages level. Then, you’ll sum up the actual performed tasks, costs, and time. Finally, you’ll compare it to the initial baseline. 

Likewise, you need an efficient change management process to integrate new requirements and scope into your project plan.

Process #5: Validate Implemented Scope Continuously

Once in a while, you need to get a formal sign-off that a deliverable meets stakeholders’ expectations. It’s crucial to do this continuously throughout the project. Even if you are leading a plan-driven project, nothing should stop you from providing product increments for review.

Why do you need this? 

You don’t want to get all the change requests, feedback, defects, and “minor changes to the project” at the end of the project. Why? 

You have spent all the budget by the end of the project, and the deadline is around the corner. There’s no room for negotiations and corrections. Project owners will not want to move the deadline. Therefore, they’ll put more pressure on the team to get what they need. So, instead, you want to use their feedback as you implement each deliverable.

How do you actually validate scope with project owners? 

Just prepare a short demonstration of the deliverable. First, explain the current project status and progress. Also, point out known defects and which parts are a work in progress. After that, collect feedback from the project owners. Later, you can provide any supporting documentation and reports required by your policies.

You need to collect feedback from stakeholders continuously. But always keep in mind the project’s objectives and deadlines. You need to remind stakeholders that every addition to the scope is a trade-off against deadlines and budget.

A great project manager knows that changes and corrections are inevitable. To accommodate project owners’ requests and keep them happy, you need to include some reserves of time and budget to allow for an adequate number of changes. Help them understand that this is the right way to run a project.

Get My Scope Management Plan Template

Most project managers don’t have formal education. That’s why you have to google all the bits and pieces of project management.

I know how frustrating it is to search answer for each step of a project.

That’s why I recommend you get this Scope Management Plan template. It will provide you with access to all my Scope management materials: