Skip to main content
Get a FREE
BVOP® Certified Project Manager mock exam
Join the modern BVOP® Agile teaching $ 0.00 mock exam fee. Free self-study Get a FREE Trial
Get Certified

Scope change management

Scope Change Management in Agile BVOP projects

Share on Linkedin Facebook
Scope Change Management in Agile BVOP projects

The following article is part of the self-preparation for the modern BVOP® Project Management Certification program.

This chapter explains the concept of Scope change management in the context of BVOP.

  1. What is Scope change management?
  2. What is Scope? Reminder
  3. Who manages the scope of the project?
  4. How is the scope of the project managed?
  5. How is scope managed in Scrum (an Agile framework)?
  6. Agile Scope Change Management
  7.  Assessing the requesting party
  8. Assessing the importance of the change request
  9. Assessing the impact on the project
  10. Documenting the change request
  11. Approval or denial of the change request
  12. Planning for implementation
  13. Communicating the plan with the requesting party
  14. Implementation
  15. Validation

What is Scope change management?

In the previous chapter, we explained what Scope Management is and stated that it is the management of incoming wishes for project changes. Most often, the desire for change comes from the stakeholders.

What is Scope? Reminder

The scope is simply a description of a project or product that needs to be developed or created. The overall vision and description of the end result are regulated in the early stages of the project. When work on the project starts and in the later stages clients or different participants in the project require changes, the scope of the project serves as a reference and a reminder of the contracted work.

Who manages the scope of the project?

The project scope is most often managed by project managers, but often program managers, project directors, and project sponsors have the final say. In Scrum practices, the scope of the project concerns only one sprint. The Scrum Master role and the Development team should protect the scope of the sprint by avoiding adding new product backlog items to their work for the period.

How is the scope of the project managed?

In the previous chapter, we described the change management process and the scope of the project. This model applies to classic waterfall project management and development practices.

How is scope managed in Scrum (an Agile framework)?

Scrum sprints involve some planned work. The Development Team and the Product Owner role have defined the work that can be produced during the sprint. After the start of the sprint, Scrum expresses the rule not to add more work for the current period. Because the Development Team can't always stop the stakeholders and the Product Owner role from wanting extra work to be developed, the Scrum Master role reminds the rules and opposes adding more work to the Sprint Backlog.

BVOP has created a new Agile role in the face of the Agile Director who is a senior management representative. As the Agile Director is a senior management representative of the participants in the project, he/she has the authority to defend the scope with greater force.

Agile Scope Change Management

In the previous chapter, we mentioned that BVOP changed the understanding of the scope of the project and recommended that the scope should not be considered a static and fixed contractual form. In this section, we explain this idea in more detail and explain how to manage flexible scope in Agile projects.

About this chapter

This chapter is part of the BVOP Project and Program Management Certification program guide.

Fast and on-time realization of projects depends on the stable and non-variable scope. Classic project management understandings teach that the scope of the projects should not be changed once it is defined, or the scope should accept minimum modifications. Changes in scope are often related to causing delays, re-work, and a waste of resources.

Under real-world conditions, the scope of projects usually changes after its initial definition and approval. The frequency of modifications may depend on factors such as changes in user and business needs, technical feasibility, and other topics described in the Business Value-Oriented Program Management section.

Changes in the scope of the project are generally considered to be important, especially in dynamic, innovative, and complex products where real users and stakeholders provide frequent feedback on early versions of the product.

The following practices may be applied to minimize the damage of future scope changes:

  • Initial detailing of needs
  • Creating and evaluating sketches, diagrams, prototypes and other materials that may represent the expected product clearly
  • Assessing the emerging changes of the scope, so project teams are focused on the high-prioritized change
  • Ignoring changes if they are not critical for the project

The low frequency of the project’s scope change may depend on factors such as:

  • Defined clear goals
  • Understanding and applying prioritization practices
  • Understanding of Minimum viable product principles
  • Dedicated stakeholders
  • Competencies and skills
  • Mature management roles

Changes in project scope should not always be considered as negative events. When an early version of a product is released to real users, valuable feedback about the business value of the released version may be provided by the users. 

The current version may not cover usability and accessibility levels or it might have gaps in important functionalities, which could have been developed in a way different from the users' expectations. The current version of the product can be a source of new ideas and needs for the users.

Any requested changes to the scope of the project may be processed by following the steps below:

  • Assessing the requesting party
  • Assessing the importance of the change request
  • Assessing the impact on the project
  • Documenting the change request
  • Approval or denial of the change request
  • Planning for implementation
  • Communicating the plan with the requesting party
  • Implementation
  • Validation

 Assessing the requesting party

The requesting parties may be from different departments, stakeholders representatives, or organizations. 

Assessing the importance of the change request

Understanding the importance of the request is a needed step in order to process the change request. If it is not assessed as important, its processing may be delayed.

Answering basic questions at this stage may be helpful for assessing the importance of the change request such as:

  • Who needs this change?
  • Will this change affect the product or project positively?
  • When does this change need to be fulfilled?
  • What are the expected results if this change is not implemented in the project?
  • Have the project participants been informed of this change request and its expected results?

Assessing the impact on the project

If the change is expected to impact general project parameters negatively, although it is important, the request for change can be discussed with program managers, project sponsors, and eventually rejected. If the impact is assessed as positive, the change may be approved as usual.

Problems that may occur after a change in the project parameters:

  • Technical or development complication
  • Negatively affecting other unexpected parameters as usability, product features, marketing, and sales strategies
  • Negative feedback from other customers, users, and parties
  • Increased cost and project completion time

The competence, experience, and skills of the project management roles may affect the needed time for assessing the change request.

Documenting the change request

Documenting the change request may be formal or informal practice based on organizational needs.

Maintaining a register of all requests may be a valuable source of information, needs, and requirements at later stages or for other and future projects of the organization.

Each registered request item may contain:

  • The requested party (Name, team or department)
  • Contact details for future communication
  • Answers to the questions introduced in “Assessing the importance of the change request” step

Approval or denial of the change request

Actual formal approval or denial of the change request may be needed based on the organizational practices.

The BVOP suggests that if the organization has formal approval or denial process, the time needed for the decision need to be minimized.

Planning for implementation

Planning may include when exactly the change can be integrated, by which team and with what resources. Other change requests, project tasks already planned, and resources are considered. Adaptation of the current project plans may be needed.

Communicating the plan with the requesting party

Communicating the plan back to the requesting party may be needed, and feedback to be expected.

Implementation

The actual implementation of the change.

Validation

The outcome of the implemented change needs to be validated and agreed upon as satisfactory.

Stakeholders, project team members, and other parties may participate together in prioritization, estimation, and planning of the changes.

The following issues related to chapter "Scope change management" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of November 9, 2024, 11:07 pm

ID Issue Time Category
0 Approval or denial of the change request 60 sec PM, PDM
1 Validation 60 sec PM, PDM
2 Implementation 60 sec PM, PDM
3 Communicating the plan with the requesting party 60 sec PM, PDM
4 What is Scope change management? 60 sec PM, PDM
5 Agile Scope Change Management 60 sec PM, PDM
6 Who manages the scope of the project? 60 sec PM, PDM
7 Documenting the change request 60 sec PM, PDM
8  Assessing the requesting party 60 sec PM, PDM
9 How is the scope of the project managed? 60 sec PM, PDM
10 Planning for implementation 60 sec PM, PDM
11 Assessing the importance of the change request 60 sec PM, PDM
12 How is scope managed in Scrum (an Agile framework)? 60 sec PM, PDM
13 Assessing the impact on the project 60 sec PM, PDM
14 What is Scope? Reminder 60 sec PM, PDM

Comments from the BVOP™ community on “Scope change management”

Summary

Scope change management is the management of project changes requested by stakeholders. The scope is the description of the project or product that needs to be developed, and serves as a reference for the contracted work when changes are requested during the project.

Project scope is usually managed by project managers, but program managers, project directors, and project sponsors may also have a say. In Scrum, the scope is limited to one sprint and the Scrum Master and Development team should avoid adding new items to their work. This applies to classic waterfall project management and development practices.

Scrum manages scope by defining the work that can be done in a sprint and not allowing additional work to be added. The Scrum Master enforces this rule. BVOP introduced the Agile Director role, who has the authority to defend the scope. BVOP also recommends managing scope flexibly in Agile projects.

Stable and unchanging scope

Projects need a stable and unchanging scope to be completed quickly and on time. Changing the scope can cause delays, re-work, and waste resources. However, in real-world situations, project scope often changes due to user and business needs, technical feasibility, and other factors. In dynamic and complex products, changes in scope are important, especially when real users and stakeholders provide feedback on early versions of the product.

To minimize damage from scope changes, it's important to detail needs and create clear representations of the expected product. Project teams should focus on high-priority changes and ignore non-critical ones. Factors like clear goals, prioritization practices, and competent stakeholders can reduce the frequency of scope changes. Changes shouldn't always be seen as negative; user feedback on early versions of a product can reveal valuable insights and inspire new ideas.

To make changes to the project scope, follow these steps:

1. Assess the requester

2. Evaluate the importance of the change

3. Determine the impact on the project

4. Document the change request

5. Approve or deny the request

6. Plan for implementation

7. Communicate the plan to the requester

8. Implement the change

9. Validate the change.

Assess the requesting party, who may be from various departments or organizations. It's important to determine the significance of the change request to avoid delays in processing. Basic questions can help assess its importance, such as who needs it, its impact on the project, when it's needed, expected results if not implemented, and if project participants are informed.

Assess the impact of a change request

To assess the impact of a change request on a project, program managers and project sponsors may discuss it and reject it if it negatively affects project parameters. If the impact is positive, the change can be approved. Changes may cause technical complications, affect other parameters like usability and marketing, receive negative feedback, and increase costs and project completion time. The time needed to assess change requests depends on the project management team's competence, experience, and skills. Organizational needs determine whether change request documentation is formal or informal. Maintaining a register of all requests can be useful for future projects and may include the requested party's contact details and answers to questions from the previous step.

Approve or deny change request

Formal approval or denial may be required based on organizational practices. Minimize decision time if a formal process exists. Plan implementation including team, resources, and adaptation of existing plans. Communicate the plan and expect feedback. Implement change and validate the outcome. Involve stakeholders, team members, and other parties in prioritization, estimation, and planning of changes.

Comments on “Scope Change Management in Agile BVOP projects”

  1. Laurence Mcdonald

    Hi everyone, Is the Scope change management applicable in both Agile and Waterfall practices. As far as I know, in Scrum, there is no such thing as change management at all. In what cases should we apply it? Thanks

Author
Web site
What is the profession that many of the readers of this site have or want? Specify one word in lowercase letters (Anti-spam protection)
Your Comment
 

The BVOP Certificates

Certified Chief Executive

The BVOP Chief Executive is the core driver of the Business Value-Oriented Principles and the most advanced figure who has the organization’s best interest.

Get Certificate $1290   $270

Certified Program Director

The BVOP Program Director manages the entire Program Management Office and possesses exceptional expertise and applies strategies.

Get Certificate $720   $190

Certified Agile Director

The BVOP Director is the most advanced and important role inside Agile products and services-based organizations. Take it to the next level.

Get Certificate $440   $180

Certified Project Manager

The BVOP Project Manager is an advanced and competent business, product, and technical role and a key factor for the success of the projects.

Get Certificate $280   $130

Certified Product Manager

With the advancing design, development, technical, and business knowledge, the BVOP Product Manager is a master role and decision-maker for the products.

Get Certificate $280   $130

Certified Product Owner

Responsible and skilled BVOP Product Owners balance both business and technical needs using Agile approaches and provide business value for products.

Get Certificate $180   $90

Senior Scrum Master Certification

The BVOP Scrum Master role combines skills, Agile thinking, and project management practices to enchant processes, teams, and stakeholders.

Get Certificate $140   $70

Certified Human Resources Manager

People are the greatest assets of any organization. It is important to find a balance between people and organization’s needs. Start the change today.

Get Certificate $140   $70
×
Become a Certified Project Manager
$280   $130
FREE Online Mock Exam