Skip to main content

Scope change management

The following article is a sample from the full BVOP™ Ultimate Guide and is part of the preparation for the BVOP™'s modern Agile Project Management Certification Program.

Fast and on-time realization of projects depends on the stable and non-changeable scope. Classical project management understandings teach that the scope of the projects should not be changed once it is defined or the scope should accept minimum changes. Changes in scope are often related to causing delays, re-work, and a waste of resources. The motivation level of the teams working on the projects may drop if they are focused on fast and strictly predicted realizations.

Under real-world conditions, the scope of projects usually changes after its initial definition and consent. The frequency of changes 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 future product clearly
  • Prioritizing 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 change in the scope of the project 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 projects scope should not be always 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 them. 

The current version may not cover usability and accessibility levels or have gaps in important functionalities or functionalities have been developed in a way different from user expectations. The current version of the product can be a source of new ideas and needs for 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 needed step in processing the change request. If it is not assessed as important its processing may be delayed. 

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

  • Who needs this change?
  • How this change will affect positively the product or project?
  • When does this change need to be fulfilled?
  • What are the expected results if this change is not implemented in the project?
  • Are most of the involved in the project parties aware of this change request and its expected results?

Assessing the impact on the project

If the change is expected to negatively impact general project parameters, 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 normally approved.

Project parameters that may be negatively affected by a change:

  • Technical or development complication
  • Negatively affecting other unexpected parameters as usability, product features, marketing, and sales strategies
  • Negative acceptance 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 of 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 needed 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

An actual implementation of the change.

Validation

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

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

Scope Change Management in Project Management Practices
Comments of our guests
Author

Web site
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 and leads the interest of the organization.

Get Certificate $1290   $720

Certified Program Director

The BVOP Program Director manages the entire business value oriented program management office and have exceptional expertise and applies strategies.

Get Certificate $720   $490

Certified Agile Director

The BVOP Director is the most advanced and important role inside Agile products and services-based organizations.

Get Certificate $440   $220

Certified Project Manager

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

Get Certificate $280   $130

Certified Product Manager

With 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

Certified Scrum Master

The BVOP Scrum Master role combine 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. Balancing the people and organization needs

Get Certificate $140   $70