Skip to content
PM Certification
Generic filters
Exact matches only

Change Project Scoping and Scope Creep Control

Scope management is one of the critical tasks of the Project Manager, and the most difficult knowledge area in PMBoK to define and control.

This difficulty is intrinsic to the projects because we cannot ignore the human side of such projects. The project objectives are defined by people, assailed by doubts and indecision, and who depend on processes in their organizations that hinder the definition of Scope (different departments, poor communication within the organization, etc.) Although we think of projects as a rationally established process, the decision-making by people and the selection criteria people employ, are heavily influenced by human nature. This whole process is complicated when, as always, there are several stakeholders involved in the project, who will try to impose their views on the project objective.

Moreover, the circumstances in which they implement projects will change over time, especially in sectors where market, competition and customers change rapidly.

If we consider the Scope as a component within the triple constraint, then it is affected by the changes we make in the other two: time and costs, and even quality as a central part of the three. Any change in the other restrictions will affect Scope, for better or worse. So, there are many circumstances in which changes within Scope will happen. We won’t avoid these changes, but we will control them.

Therefore, from this whole process in which many people with different criteria and motivations are involved, we can expect the appearance of changes to the original Project Scope definition.

Controlling the Scope of projects is one of the main concerns of managers, CEOs and stakeholders of projects. It makes us feel that we lack control!

Are Project Managers Control Freaks?

The attitude of the Project Manager is usually that of a maniacally controlling professional, who avoids changes at all costs. This attitude is understandable because once we have taken charge of our project and have our project plan under control, we do not want to change it just because a last-minute suggestion for the project dawned on someone.

Do we want to have all the aspects of our project fully controlled?

Yes, it would be desirable. However, as we have seen, we can’t prevent changes in the project. “Control” does not mean avoiding change or becoming an obstacle to change. Changes in our wonderful Scope Baseline will occur, and we cannot avoid them. It is not our goal. So, keep the first rule in mind:


…and we are not in the best position to oppose the strategic decisions of management or customers.

Our task then is to control, check, test, verify, regulate, monitor and when Scope has been derailed, to set it back on track.

We can group the following items related to the Change Project Scoping into three fundamental ideas to control Scope Creep:

  • PLANNING the Project Scope
  • PRIORITIZE the resources and essential requirements of the project in relation to changes
  • CONTROL AND MONITORING of Scope and its changes, creating a continuous communication with stakeholders and the project team


The Scope should be defined in the planning phase with the participation of stakeholders.

This seems obvious because we have read countless literature, but it is not always done in sufficient detail.

The main reason projects fail is cursory, unrealistic planning or directly, the lack of planning. At this point, the restriction posed by the Scope of the project is closely related to the other two components: time and costs. So, the unrealistic planning of any of the above will affect the Scope, forcing us to incorporate elements we hadn’t originally planned into the Scope.

It is important to check the requirements and the Scope of the project with the stakeholders, so that we make sure that we are aligned with what stakeholders understand the Scope of the project to be. The Scope must fit what stakeholders expect and have in mind. Hence, it is important to involve all stakeholders in the project in the earlier phases, so that we can reflect the interest of stakeholders in the project planning.

Work Breakdown Structure (WBS) is a tool of communication with all the stakeholders, so we should use it as such and discuss it with those agents who can provide information, and talk about their criteria. In view of our planning, stakeholders can visualize if we interpreted their needs well, or, if not, communicate how they would like the planning to be changed. In any case, it is better to change the project planning before we start to implement it, than have to discuss this change during the Scope validation process.

These meetings to establish requirements verification also serve to explain the procedure we establish to manage change, which makes us all think: for our part, if we understood well all the requirements of the stakeholders, confronting them with the requirements of all the other stakeholders, etc.; and on the other hand, stakeholders, who are made to think that the changes made later will be more expensive, and must be inserted into a management process approved by all. Therefore, they must be very careful to define correctly their requirements to avoid costly changes.

Define Change Control Processes

As we have seen, change happens, and what we want is to control and monitor the project so that these changes will not derail the project.

What we need to establish this control is a process by which each change can be documented, analyzed, studying its potential impact on the project, approving it if appropriate, communicating it and monitoring its outcome.

During the planning process, we’ll reach an agreement with the stakeholders on this procedure that allows us all to manage and be informed about the changes that may be introduced later. The procedure will establish who can request the changes, when they’ll be approved, and by whom.

These meetings should also serve to establish a Change Control Board, which will be responsible for approving or leaving pending the changes requested according to the procedure specified above. The PM, by itself, cannot make decisions that affect the priorities that have been taken between the requirements of the project. Therefore, it will be the Change Control Board, on which all convenient stakeholders (such as the customer, the sponsor, etc.) will be represented, that will judge the suitability or unsuitability of each change.

Most often, changes are approved according to priority, interest or business criteria, rather than in terms of the impact they may have on the Project Baseline, its Scope, time or cost overrun.

Use tools such as the PPM Program and Project Management 2.0

Project planning can be documented and displayed in many different ways and through different tools, but it is always a difficult job for the PM and their team.

Traditionally, templates, spreadsheets or non-specialist software have been used to manage projects and each company adapted the tools they needed for the way they worked. But when projects become more complex and changes occur that force us to reschedule during execution, the management of all this documentation, and the Project Plan, determines the speed with which we apply the necessary changes to the project.

Bureaucracy and paperwork cannot be an excuse to delay the re-planning and to apply changes to the project. If we do not use specialist project management software and PPM programs, this work can be very cumbersome.

Current technology, software and collaborative PM2.0 work environments, in which data collection is done with any device in real time, greatly facilitates the task of updating information and re-planning the project.

Any of the PPM software programs that are on the market enter the dependencies of each of the tasks connected with each other, which enables us to analyze any change introduced in the project and see its impact on future prospects in seconds.

PRIORITIZATION resources in relation to changes

During planning, we’ll find that the interests of the different agents will be competing: different departments within the organization, several projects that share resources, external stakeholders with conflicting motivations, etc. Each party will try to exert their influence and seek their interests through changes in Project Scope.

To avoid confrontations and have a useful criterion to determine the orientation of the changes, we should set priorities in planning. In setting requirements, we should establish some priorities in terms of the Project Scope. For example, what is a priority for the project, which objectives are essential and what other requirements add value to some of the stakeholders but are not essential to the business.

What is the aim of the project? Which ones are priority requirements for business needs and which are requirements or wishes that respond to the individual discretion of a stakeholder? These priorities will be set in the Requirements Management Plan. It is a document that should have the agreement of the stakeholders.

With these priority criteria, the change control board will have a tool to decide subsequently to approve the proposed changes if they are aligned to the objectives of the project and the business. Those requests for changes that are not based on project priorities, and have a negative impact on its Scope, should be rejected.


In most cases involving Scope Creep, requests for changes made during the project implementation were not documented because many stakeholders preferred not to record requests for changes they would like, and that are not a priority for the project. This is a typical example of the customer who comes to a team member and “comments” on the possibility of introducing an “unimportant” change.

If change requests are not recorded, it is impossible to track them; and if these “undocumented” changes are implemented, we will be unable to monitor the project, it will go off-track.

Documenting change requests helps the monitoring process, by assessing their impact and approving such changes if appropriate. Even if change requests are not approved, the documentation and analysis we have made of their impact will help us to establish acceptance criteria in the future.

If we established a Change Control Process, change requests are recorded, either internally by the project team, or externally by the external client or stakeholder, and they will be documented for the record and will allow us to track them. The PM and his team will study the impact the change might have on the project, consider whether there are alternatives and provide these documents to the Change Control Board, which will approve or reject the change request. If the changes are approved, they must be incorporated into the plan, but also, we’ll have to communicate this new scenario to the affected stakeholders, starting with the project team itself.

The process of studying the impact and rescheduling includes allocating the resources and budget necessary to carry out the changes in the project. This is the time when it becomes clear whether the change requests are justified and are aligned with the priorities of the project, in which case we’ll allocate more resources and extra time to implement the changes. By contrast, if the change does not justify the need for more resources, it will be an objective criterion to reject the request.

During this process we must be able to communicate the need for more resources to implement the changes, which directly influences the perception that the sponsor and the customer will have about the changes.

Change Control Board

As we see, the PM cannot make decisions that affect priorities in the project requirements. You must count on the client and key stakeholders who could be part of the Change Control Board. They will approve the changes based on the priorities we set and how they affect the project constraints.

The PM provides the information and analysis of the impact on the project, but avoids the pressure to make a decision to approve or reject changes.

What happens in those projects where there is no Change Control Board?

In this case, more pressure is exerted on the PM to approve the changes requested and this pressure can affect decision-making and the work of PM. We must be cautious and agree on decision-making by involving and informing the stakeholders, mainly the sponsor and client, so they are aware of the changes and approve them.

Approving changes entails incorporating them into the project and therefore re-planning and updating the Project Plan, which as we have seen, will be easier if we use the right tools.

Of those projects that fail, most do so at this point (75%). The implemented changes are not updated and control over them is lost. And more importantly, this documentation is not updated, so that stakeholders, the client, etc., do not receive the information about these changes, giving rise to potential conflicts.

If you are working with outdated documentation, communications will fail, or the tracking we do of an outdated Project Baseline will be useless.


The project team members are in direct contact to the field, with the project. They are the ones who have more information about small changes and see the concerns of stakeholders before a request for change happens. A practical way of avoiding Scope Creep is to collect feedback from the team that is in contact with the project environment, where numbers are measured and which has firsthand information.

Communicate that process to the team

Moreover, the work team is the one most affected by changes, because the work is done by people, our team.

How do you feel when your work is constantly changing and you have to redo what was already finished?

We must be aware of the psychological component of this process. Members of the project team must be motivated and constantly redoing their work without understanding the reasons and without being informed of the criteria that drive these changes affects the work climate.

Everyone in the company wants to change the project, departments, business units, vendor partners, users, etc., and the last ones to get to know about it are the project team.

The best way to motivate the team, to make them feel part of the changes and to see these as theirs is by involving them in decision-making. We can give them the freedom to interact with stakeholders, considering in this way their views on the changes. Through this contact, ideas and alternatives to changes will certainly arise, which can save us time and resources. But most importantly, the changes will be valued and understood by the people who have to implement them.

In contrast, this direct contact of the project team with the source/origin of the changes must also enable them to say NO when they’re faced with changes outside the established channels.

EMPOWER THE TEAM or COACH them to say NO, to have the capacity and the option of saying NO to the members of the organization, departments, etc., when they get comments with this kind of informal phrases in the office:

“While you are doing that, could you do this too?”

“All you have to do is…”

“It will not take that long”

These situations are typical in project offices. They are a clear example of Scope Creep, where seemingly minor changes are introduced in the Project Scope, without assessing or estimating the impact they may have on the final result. And they are made in an informal, undocumented way and without relying on any criteria or previous experience.

Therefore it is very important that the project team is informed of the change management process, and is empowered to avoid these pitfalls.

Engage the project team to have the ability to prevent these types of informal changes that may lead to Scope Creep on projects. 


We are being unrealistic if we think that we can avoid changes in our project.

Change Happens!

My recommendation:

  • Establish change management processes and have clear priorities and criteria for project success.
  • Be disciplined in the management and documentation of change requests and project re-planning.
  • Communicate with and empower the project team

Do not become a control freak. Controlling the Scope does not mean avoiding changes but to manage, analyze and monitor the implemented changes to ensure that they follow priorities established by everyone, and do not affect the main objectives of the project.

error: Content is protected !!