The Ultimate Guide to Controlling the Project Scope

Up to this article, we have discussed several aspects of planning and executing projects. We have touched upon how to build a complete project charter, how to estimate costs and schedule, and how to handle risk by planning in advance against unforeseen events. From now on, we will dive into another fundamental part of running a project: monitoring and controlling the planned processes.

But why is monitoring and controlling as important as (if not more than) planning and executing a project? The answer is fairly intuitive. When you plan a project, you lay down idealistic scenarios (hopefully) based on your past experience and (hopefully) adjusted for the specific characteristics and requirements of your project. These scenarios, however, hardly ever reflect the unknown future of the project execution. When you start to execute each task, you will inevitably run into unforeseen events that will require adjustments in your task descriptions, goals, deadlines and cost estimations. This is where control and monitoring play a major role: they are the tools you will use to correct your course of action whenever necessary.

The process group defined as monitoring and controlling by the PMBOK guide is composed, among others, by the following five fundamental processes:

• Control Scope
• Control Schedule
• Control Costs
• Control Quality
• Control Risks

This is not new for us. Remember our discussion on how to create a complete project charter? From the eight sections that make up the project charter, the five most important ones from the controlling and monitoring perspective are:

• Project Scope Statement
• Project Deliverables
• Costs and Estimates
• Objectives
• Project Constraints and Risks

They are closely related to the five main processes defined by the PMBOK guide! To keep this course consistent with the book, this and the next four articles will discuss each of these five sections in detail.

1. Revisiting the definition of project scope

Before we start discussing the actual tools to control the scope of your project, let’s invest some time in understanding what the scope really is.

“Project scope” is a somewhat vague term. It includes several areas of the project, and it defines its boundaries in terms of costs, schedule, tasks, outcomes, and quality standards. In other words, the project scope defines the general direction of the project.

Despite being the most fundamental definition in a project, it’s very easy to forget the project scope when planning and executing more specific parts of the project. It happened more than once to projects we’ve supervised, and it happens more or less this way. Your client (be it external to your company or another department of the same organization) comes with an idea of the product or service they want to develop. They have a fair description of what they want, and they explain it to you in details, leaving to you the task of understanding both the business requirements and defining the macro layers of the WBS. After some thought and discussion with your team, you define the project scope by establishing the main features of the project, as well as schedule, cost, and quality requirements. So far, so good.

But as your project is executed, and as the time passes, new features and ideas start to pop up. You clients start to ask for new functionalities that weren’t initially included in the project plan. You start analyzing the ideas and, from a micro perspective, they are actually attractive. Feature by feature, task by task, your project starts to take a different shape from the initially defined. Instead of revisiting the project scope to check whether the new features or changes are relevant from the perspective of the initial goal, you and your client agree to simply include them in the project execution plan because they seem relevant.

Let me give you a real personal example. Some time ago, I’ve supervised a project to develop a website for a real estate company. The project was targeted at providing a better user experience for finding, acquiring, renting, and selling properties. It was almost routine, during the conferences with our clients, to have them propose ideas such as “adding a communication functionality specific to hotels so hotel managers can quickly communicate with hosts in the case of an emergency”. This falls completely out of the original motivation of the project, and we had to constantly remind our customers that the product under development was focused on the real estate industry. This doesn’t mean we have to discard every single idea that diverges from the original goal; instead, we can propose a way of implementing them in a separate project. Section 3.4 of this article will discuss how to handle unreasonable customer requests and present a suitable course of action.

It’s your job, as the project manager, to impose limits and stop your clients from wandering too far from their initial request. It’s your responsibility to alert them if their requests are not relevant and to remind them of their initial goals.

This is the bottom line of scope controlling and monitoring: to avoid that the natural changes that come with the execution of the project end up directing it to a completely different outcome.

Creating a well-defined project scope control process will help you benchmark every change request against the original targets of the project and decide whether it should be included or not in the project WBS. It will also help you define an action plan for handling requests that don’t fit well with the project scope. Should you propose a new project to execute them? Propose hiring a third-party that already offers the product/service? Entirely avoid implementing them?

The following sections will present the different inputs, tools, and outputs of the Scope Monitoring and Controlling process. Let’s start by revising which documents you should gather to have more information and better handle scope issues and variations.

2. Required inputs for project scope control

Remember what we discussed about the scope defining the general direction and the macro constraints of your project? Scope monitoring and controlling is about benchmarking your actual performance against these initial definitions to check whether you are being consistent with what was initially established. Here is a comprehensive list, based on the PMBOK guide, of documents you should have available during the scope control.

2.1 Project Management Plan

The project management plan presents the different phases of the project and binds together all the specific documents into a cohesive whole. It contains information such as the project lifecycle, the macro processes relevant for each phase, how each phase contributes to accomplishing the final goal of the project, an overview of the change management plan, as well as other sections. Ultimately, the project management plan should contain a summary of all information related to the project. Avoid, however, putting the entire documents in the project management plan: this will lead to a huge document that no one will fully read. Instead, summarize the information and present the main points for each section, together with the link to the specific plan.

We recommend having the following five sections of this document when performing the scope control.

2.1.1 Scope baseline

The scope baseline is formed by the scope statement and the WBS of the project. It’s the document against which you should benchmark the actual developments of the project to verify whether there are any necessary changes or adjustments.

The scope statement should contain two main sections: the product/service scope, containing all relevant features and functionalities, and the project scope, containing a description of the work that needs to be done in order to successfully deliver the project.

2.1.2 Scope management plan

The scope management plan defines the guidelines that must be followed when implementing changes to the scope of the project. Basically, you don’t want to leave all the areas of your project open to change. Some of the initial definitions should be kept constant because they form the very essence of the project, and changing them would ultimately result in a brand new project.

To give you a concrete example, think of an architecture project. Once the project team has started constructing the building, it’s not possible to change every single aspect of the blueprint: you have several restrictions imposed by the foundational structure and other aspects of the construction. The reasoning is analogous: before your project start (when you are still discussing requirements, product specifications, and other matters with your client), everything is subject to change. Once you start to execute the project, there will be areas that cannot be changed without resulting in a whole new project. These areas should be clearly defined in the scope management plan.

To help you with creating the scope management plan, here are some ideas of specific procedures you might define (this is not an extensive list, so feel free to add your own questions to it):

• Which areas of the product/project scope and the WBS are subject to change upon approval?
• Which departments or stakeholders should be consulted before implementing the changes?
• Which requirements do you have to keep in mind when changing the scope of the project?
• Which deliverables can be discarded or updated, and which ones shouldn’t be touched?
• What is the ultimate goal of the project (the final destination where you want to arrive)?
• What are the main project phases and their requirements?
• How onerous is to change a completed project phase, and what is the resulting impact on the project?

Our article about calculating the project schedule offers a great visual algorithm for identifying sequence constraints in a project. This, in turn, will help you understand how each project phase influences and is influenced by other tasks in the WBS.

2.1.3 Change management plan

The change management plan is the document that summarizes how changes will be handled in the project. In our article about managing communications, we have extensively discussed how to manage change in a project, as well as several tips on how to approach different stakeholders during change periods.

Having the change management plan in hands is essential for knowing how to proceed when implementing the required changes in the project scope. It will help you answer questions such as who should be included in the decision-making process, who should be notified once the decisions are made, and what are the practical steps you have to take considering each different change category.

2.1.4 Configuration management plan

The configuration management plan defines which features of the final product or service are subject to change, and how the change will be tracked and analyzed. It also defines which items require a more formal approval process, and which ones are open to the project team discretion during the project execution process.

2.2 Requirements documentation

The documentation on project requirements defines which needs or demands from different stakeholders must be fulfilled by the project. In other words, it establishes the “requirements” that the stakeholders want to meet through the project outcome. While a business executive might require an acceptable profit margin from the project, a future buyer might focus on quality, cost, and compatibility concerns.

Different stakeholders will have different requirements, and some of them might be conflicting (for example, business managers require high profits, but the client’s concern with quality might force you to procure more expensive raw material). Controlling the scope of the project is also about ensuring the thorough delivery of requirements while updating the scope as needed during the project execution.

In addition to that, you should consider the link between product configuration and product requirements. A different product configuration requires different inputs, so changing the physical or intangible aspects of your project outcome will demand updates to its procurement plan.

2.3 Actual work performance

The documents listed above form 50% of the required inputs for project scope controlling. The other 50% is given by the data on actual work performance. That’s because the essence of project controlling is to compare actual with forecasted performance.

For scope monitoring, you are interested in data about the description of the tasks being actually performed. You are not as interested in detailed costs or schedule: we will cover them when we talk about cost and schedule controlling. For the scope area, your focus is on knowing which tasks are being executed and whether their outcomes will take the project closer to its successful end. Naturally, you want to have a general overview of costs and schedule to ensure that the project is being executed within its financial and time boundaries, but meticulously inspecting cost and schedule is not a scope management concern.

In the article about defining the schedule of your project, we’ve offered a detailed project tracker. The tab “task tracker” gives you a complete overview of which tasks are being performed, their progress, and their actual cost. If you use any project management tool, you can generate multiple reports based on the information your team adds to the project.

Another important implication of generating the reports and revising the trackers on actual performance is to ensure that they are updated with the latest valid information. It might be the case that your team is providing unreasonable information about task progress and cost, and checking the discrepancies between informed and real progress is also a task related to project controlling.

3. Tools and techniques for controlling the project scope

Once you have collected most of the necessary documentation (maybe you can forego a few documents depending on the structure of your project), it’s time to move to the actual scope controlling and monitoring process.

3.1 How often should you monitor and revise your project scope

One recurrent question made by project managers is how often the monitoring and revision of the scope should be made. The answer, unfortunately, is not a standardized one: it’s deeply dependent on the project nature. Let us give you two examples to illustrate our point.

First, think of a software development company which deals in a very fast-moving world. For them, scope monitoring might have to be done once or twice a week. The number of ideas, the implementation speed, and the speed with which competitors update their own products make the technology industry extremely volatile. Therefore, you must be able to quickly respond by revising the overall structure of the project at least on a weekly basis. Another aspect of technology companies that makes them suitable for constant scope analysis is the ability to change virtually every part of the project with minimal impact on related processes. While a construction industry cannot easily change the foundation of a house without affecting the entire construction, a technology business can change their server structure and still be able to quickly connect their product with the new database. The process is not as fast as other updates, but it can be done with little impact on the final product (apart from the layer that connects the frontend product to the backend server storage service).

On the other extreme, we have industries such as architecture and construction. In these industries, once a project phase is completed and the next one starts, it’s extremely hard to undo changes. When the foundation of a building is done and the construction of the first floor begins, the part of the scope regarding the foundation is considered as unchangeable. The same reasoning applies to each project phase that depends on the previous ones. In these industries, therefore, scope revisions happen much less often than in technology industries. On the other hand, each of these monitoring sessions is much more detailed and usually takes much longer than one 30-minute meeting.

Defining how often you will carry scope control sessions depends on your industry, your team, and the priority of the project. It’s important to discuss these issues with all the relevant stakeholders and define beforehand when scope revisions will take place.

3.2 Using variance analysis to compare actual and expected results

Variance analysis focuses on studying whether the natural variation that happens during the project execution is big enough to require an active correction or adaption. Your project will very likely diverge from the initial WBS in several moments, and it’s your job to judge whether these variations need to be corrected or not.

From what we’ve discussed so far, it’s fair to assume that scope controlling is more descriptive than numeric. We can have general cost and schedule figures, but it’s better to leave the calculations to the specific cost and schedule controlling processes. For the scope, we are interested in comparing whether the task descriptions and structure meet our initially planned WBS and scope statement.

Therefore, variance analysis takes a step away from pure statistics. For the scope management, you should focus on comparing the very structure of the project instead of focusing on numbers.

3.3 Using what-if scenario analysis to propose adjustments

What-if scenario analysis is a simple yet solid approach to analyze the impact of different events on your project. While this is normally used to forecast the consequences of unexpected events, its principles are also valid for scope management.

The basic question the What-if scenario tries to answer is: “How is my project affected if event X happens?” You can use the same reasoning for analyzing how your project is affected if change X or correction Y is implemented in your project scope. What are the consequences in terms of work structure and task descriptions? Will it require a new set of skills that is not available in your current team? What are your recommendations to solve the issues that result from the change?

One effective way of analyzing whether the proposed changes are valid and should be implemented is to compare the forecasted outcome of the project under the current situation (without change) and under the proposed scenario (with change). Are the forecasts very different? Is it worth to undergo a stressful adaptation period? Is the payoff of the change high enough to compensate its costs?

Since the project scope lays the foundation for your entire project, changes to it are harder to undo. Therefore, such questions should be a matter of serious discussion between you and the relevant stakeholders, and the consequences of each change should be considered extensively.

3.4 How to avoid scope creep and handle unreasonable client requests

Scope creep is the formal term for what we’ve been discussing regarding the uncontrolled growth of the project scope. The PMBOK is clear on their definition:

[Scope creep is the act of] adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval.

Scope creep can happen due to a variety of reasons, among which the most important are:

• Inability to handle customer requests: when receiving unsuitable client requests, many managers lack the ability to refuse them fearing that their actions will lead to customer dissatisfaction. However, this couldn’t be further from the truth: by showing that the request doesn’t fit in the current project and by presenting alternative courses of action, you are showing your interest in your customer’s success.
• Lack of proper scope control: avoiding scope control and monitoring can very easily lead to scope creep because there isn’t a regular check on the tasks being included in the project scope.
• Poor internal and external communication: not communicating project changes properly or foregoing the necessary formal approval when modifying the project may lead to scope creep and loss of control over the project scope.
• Not having a well-defined product: if there are no clear features and boundaries to the product or service being developed, it’s much harder to control the scope of the project and to fall into the scope creep trap.

These are just a few examples of what can go wrong in the project scope area of a project. To counteract them, let’s revise a few techniques and recommendations provided directly by the PMI.

3.4.1 - Have each interested stakeholder develop their own project charters

A project charter contains all the major sections involved in planning, executing and controlling a project. Having different stakeholders design their own project charters will give you different perspectives on important characteristics of the project. This, in turn, will help you craft a well-defined project scope and avoid scope creep due to poor project definition.

3.4.2 - Define the change management plan before changes happen

Project managers often fall into the trap of dedicating resources to create a change management plan only when adjustments are mandatory to the project survival. This, however, leads to poor and incomplete change processes, which don’t cover all the necessary aspects of properly implementing changes in the project.

By developing the change management plan early enough, you create predefined routines that prevent scope creep by standardizing your decision-making process.

3.4.3 - Consider the WBS from both macro and micro perspectives

Scope creep is also caused by analyzing the project scope only from on the micro level and including product features that seem acceptable without asking yourself how they fit in the project’s macro context. If you consider both macro and micro perspectives, you have a better perspective of whether the change requests will contribute to a better project outcome or they shouldn’t be included in the project scope.

3.4.4 - How to handle unreasonable customer requests

Remember the earlier example about the real estate website and the app functionality for hotel managers? From the client’s perspective, it makes sense: the functionality is related to the lodging industry, and they want a product with as many features as possible so people from different target markets will use the same product and increase their market share. From a manager’s perspective, that’s ridiculous: it’s better to have two distinct products that focus on the implementation of one single service. This leads to both better products and more targeted marketing efforts, increasing the chances of being successful in the market. In addition to that, if one product fails, there is still another promising one to focus on.

This is a classic case of scope creep (including features that don’t fit well in the overall project goal). But how should you handle such requests? How do you tell your client that the change they requested is not suitable for the current project?

The first step is to understand your client’s motivation. Why did they request such features? Which market needs do they want to fulfill? This will give you important information to discuss the appropriate course of action without hurting your client’s idea or expectations.

Once you have an idea of what your client wants to achieve, put together a broad implementation plan for a separate project. Broadly discuss all the main areas involved in business planning: cost analysis, revenue forecasts, market share, marketing plans, product features, among others you might judge relevant.

With this document ready, sit down with your client and explain your suggestions. Tell them that you believe the idea is good and should be definitely implemented, but that it falls too far from the scope of the current project. For that, remember them of the project scope and the initial features of the product they requested.

Show them your business plan and the analysis you carried, and show your interest in developing the product as a new project. In the meantime, you can discuss the benefits of having two separate products, each focused on one main functionality: better branding, better marketing, better market targeting, and better functionalities.

While this course of action is considerably more effective and honest with customers, many project managers opt to postpone the decision or the discussion with the clients. Avoid that. If you already know that the incoming request is not fit for the project, save yourself some headache and propose alternative courses of action so that both you and your client are better off.

4. Outputs of project scope control

Controlling and monitoring the project scope will inevitably lead to changes in the whole project structure. Let’s cover the three most important knowledge areas affected by scope control.

4.1 Updates to organizational processes

Updates to organizational processes are an immediate consequence of good scope control because flawed processes are normally the cause of divergence between the expected and actual project task structure.

What we mean is: if the planning of your project didn’t properly materialize during execution, it’s because, at some point, there were organizational issues that led to inconsistencies. Here are some examples:

• Bad project planning: not spending enough time to plan properly and account for a sufficient amount of variables that might affect your project.
• Bad communication: not communicating with stakeholders properly and not defining the project characteristics precisely enough for your team.
• Bad execution: not delivering what was first requested by your clients, or underperforming due to bad management practices.

Notice that these examples are all defined as organizational processes. There is an established process to plan a project, to communicate with your stakeholders, and to interpret and execute tasks.

In other words, updating these processes is the task of incorporating the lessons you learn from project scope control. They will help you identify which processes were the cause of the variation between expected and actual performance, and which actions must be taken to correct these issues.

4.2 Updates to the project management plan

The two most important sections of the project management plan that will be updated as a result of the scope control process are (1) the scope statement and (2) the WBS. Make sure to properly communicate the updates to all stakeholders, as well as their consequences in the work being executed at the moment.

In addition to the scope statement and the WBS, you might have to update other sections of the project management plan, as well as the corresponding detailed documentation. If, as we already discussed, changing the scope leads to requirement or procurement changes, the respective documents should be updated.

4.3 Change requests to the project execution

Your project will very likely be under execution when scope revisions take place. Your job as the project manager is to translate such changes to actionable instructions and inform your team about them.

We have extensively discussed how changes should be managed in your project. The best course of action is to document everything to avoid future misunderstandings. Use the change log to register the scope changes, as well as their consequences in the actual work of your team. This will ensure that all team members have access to the latest information and will prevent loss of work due to outdated tasks.

5. Final words

Scope management is essential for the health and success of your project. Nonetheless, many project managers consider it unimportant and postpone its implementation until there are visible signs that the project is heading in the wrong direction. When that happens, corrections consume much more resources than if they were identified earlier in the project.

Our final suggestion is for you to be proactive rather than reactive. Don’t wait for bad signs to pop up; instead, proactively check if your project is on the right track. If it is, you’ll have wasted no more than a few minutes; if it’s not, you’ll save yourself a lot of headaches by fixing the issues early enough.