What is Project Scope Management? Types, Challenges, Planning

What is Project Scope Management?

In the context of project management, the term ‘scope’ is used for defining the work boundaries and deliverables of a project. Project scope, a part of project planning, involves deciding and listing specific project goals, deliverables, features, functions, tasks, deadlines, and costs.

In other words, the project scope is all about determining what is to be achieved and what is to be done to achieve that. According to the PMBOK, the project scope is defined as “the work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.”

The success or failure of a project highly depends on whether the scope of the project is defined clearly in alignment with time, resources, and budget throughout the project. Project scope management is a methodology that involves a sequential order of steps performed to ensure that a project’s scope is defined and mapped accurately.

Stages in Scope Management	Description
Project scope initiation	Involves ensuring that resources and authority are dedicated to creating a scope management plan.
Scope planning	Involves defining the work needed to be done to accomplish project objectives. Therefore, the main activity performed under the scope planning stage is the development of the Work Breakdown Structure (WBS). A WBS is a framework that splits complex project tasks and activities into smaller activities and represents them in a simple and easy-to-understand manner.
Scope definition	Involves identifying and listing product and project deliverables that support the MOV of the project.
Scope verification	Involves ensuring that the project scope is precise and in alignment with the overall goal of the project.
Scope change control	Involves ensuring that controls are available for managing modifications required to be made in the project scope once it is set. Modifications are generally made after taking the approval of the client.

---

Types of Project Scope Management

Depending on the need and requirements of an IT project, the project scope is defined based on various parameters. These parameters of the project scope are explained as follows:

• Business Model of Organisation
  
• Interfaces of the Project
  
• Government Policies

Business Model of Organisation

A business model refers to a conceptual structure that supports the feasibility of an organization’s business, its purpose, goals, and objectives, and its business plan for achieving them. Project scope is defined as per the business model of the organization under which a project is to be executed. For example, if the project is to be executed under the Lab on Hire business model, the scope of the client gets limited to managing the team.

Interfaces of the Project

Project scope is defined as per the number of interfaces, that is, the entities with which a project manager is required to interact during project execution. For example, an organization may need to procure resources from an external vendor to carry out a project. In such a case, the project scope must clearly state the constraints that the organization may face during the entire project life cycle.

Government Policies

Project scope is defined after taking into consideration the policies of various government agencies such as income tax authorities, sales tax authorities, etc. Sudden changes can occur in the government policies of a country.

For example, in India, demonetization in November 2016 affected many ongoing IT projects of organizations to a large extent. Therefore, the project scope should be defined after considering the risks that may erupt in the government policies of the country where the project is to be carried out.

---

Challenges in Project Scope Management

Project scope management is not always easy for a project manager. Scope creep is the major challenge faced by organizations while determining project scope. It refers to sudden changes that may occur at any point after the project initiates and deviate the project from its original goals. According to Software Productivity Research (SPR), a consulting firm, requirements in an internal development project grow each month by about 2% of the original list.

But as time passes, accommodating requests becomes more expensive, with new requirements at the coding or testing stages costing an order of magnitude more than those added during the first three months. Scope creep, if not timely managed, can lead to complex results. To manage scope creep, it is important to understand the reasons for scope creep. The following are some main reasons for scope creep:

• Poor Work Breakdown Structure (WBS)
  
• Lack of Focus on the Changing Dynamics
  
• Presence of Several Interfaces

Poor Work Breakdown Structure (WBS)

This is one of the major reasons for scope creep. Sometimes people involved in a project do not have a clear idea of what they have to do, which may lead to extra, unplanned resources and further increased costs, and lengthened duration of the project. For example, in an IT project, a software developer is also able to perform database administration work.

If his roles and responsibilities are not defined and new database administrators are hired, this will unnecessarily result in increased project costs. Therefore, a thorough WBS must be created which should mention the roles and responsibilities of all project stakeholders.

Lack of Focus on the Changing Dynamics

Generally, the project scope is defined based on the existing conditions of a business. However, during the project execution process, the project environment is subject to change, which creates a mismatch between the project scope and prevailing business conditions. As a result, it may cause the project to be over budget and often late. Therefore, it is necessary to define a contingency plan while determining the project scope.

Presence of Several Interfaces

This is another reason for scope creep in IT projects. IT projects necessarily need the help of several interfaces (such as the project manager, team members, and the client); thus, any delay in the execution of a task by any interface forces the project manager to extend the boundaries of the scope.

In other words, he/she is forced to ensure that the job gets completed anyhow to meet project deadlines, and the only way to get this done is to go beyond the defined boundaries of the scope. To resolve this issue, the roles and expectations of all project interfaces or stakeholders must be clearly defined.

---

Project Scope Initiation

Project scope is generally initiated when a business need arises. For example, a customer may approach a consulting organization to redesign its website. As and when that need arises, the project scope is initiated to evaluate that need and find out an acceptable solution. At this stage, a project manager is assigned to the potential IT project.

After that, a feasibility analysis is performed wherein technical, economic, and financial aspects of the project are assessed. Technical aspects cover whether the technological expertise to carry out the project is available. Economic aspects cover cost-benefit ratios of different technological alternatives available and the rate of return of the project.

Financial aspects deal with all possible costs related to the project. In this way, project scope initiation provides a green signal for the project to proceed. In addition to feasibility analysis, a business case is developed which provides insight into why the project was proposed and how it aligns with the overall business strategy of the organization.

---

Project Scope Planning

Project scope planning is an important stage of project scope management wherein tasks, deliverables, and constraints associated with the project are defined. For this, an elaborate scope statement is prepared; project boundaries are defined; and a thorough Work Breakdown Structure (WBS) is developed.

Let us discuss these three main activities of project scope planning in the next sections.

• Scope Boundary
  
• Scope Statement
  
• Work Breakdown Structure (WBS)

Scope Boundary

Project boundaries refer to measurable characteristics that explain what belongs and what does not belong to a project. For example, an IT administrator of an organization needs to install a new software application on computer workstations of marketing and human resources departments. In such a case, the boundaries of this project for installing the software application extend to these two departments only. All other departments of the organization are out of scope.

It should be noted that project boundaries are closely linked to project objectives. Moreover, project boundaries provide a holistic view of project work and the expected results. A clear boundary statement helps the project manager and the project team to make efforts in specific project areas within the project scope.

Scope Statement

A scope statement is an essential part of scope planning as it serves as a written confirmation for a project manager of the results a project will deliver. Moreover, it defines constraints and assumptions under which project team members have to work. A scope statement also mentions the terms and conditions of the project. All project stakeholders must agree upon those terms and conditions before the actual project work begins.

An ideal scope statement provides the following information:

• Description of Product Scope: It states the features of products, services, or results in a project is intended to produce.
  
  
• Acceptance Criteria: It covers conditions that must be fulfilled before project deliverables are accepted.
  
  
• Deliverables: They state the products, services, or results from the project are intended to produce the following project objectives.
  
  
• Project Exclusions: These are what the project is not intended to produce.
  
  
• Constraints: These are restrictions that limit what can be achieved.
  
  
• Assumptions: These are statements related to how uncertain information will be addressed in the project.

Work Breakdown Structure (WBS)

While planning project scope, project activities are divided into achievable and smaller tasks. These tasks are arranged in a framework called Work Breakdown Structure (WBS), which is the hierarchical, graphical representation of large, complex projects into smaller tasks. The structure helps in the efficient planning and allocation of resources.

As mentioned earlier WBS represents major project deliverables into smaller, more specific, and manageable components. This also helps in:

• Facilitating an accurate calculation of actual costs of deliverables
  
  
• Ensuring accurate performance measurement and control Extracting information on important and risky work efforts
  
  
• Mapping requirements, plans, and outcomes of the project
  
  
• Providing clarity on ownership to managers and task leaders

---

Project Scope Definition

Defining project scope is the most crucial stage of project scope management because until it is not defined what is supposed to be delivered at the end and what the boundaries of the project are, the project cannot be executed. The scope of the project can be defined in terms of deliverables that must be provided at the project completion. These deliverables can be split into two parts which are the project-oriented scope and product-oriented scope.

Such division of deliverables provides a clear insight into activities to be performed; thereby facilitating the efficient allocation of resources and making accurate time and cost forecasts. Project scope is dependent on the product scope; therefore without a clear understanding of product scope, one cannot define the project scope.

Let us discuss the product scope and project scope in detail.

• Product-oriented Scope
  
• Project-oriented Scope

Product-oriented Scope

Product scope indicates the features and functions of a product. In other words, product scope explains how the product will look, how will it work, its features, etc. For instance, if a product is a software, the product scope will include its features, quality, reliability, design, license, patents, etc. The product scope is developed by the project manager and the project team as per the information provided by the client in the project initiation phase.

Defining a product scope is generally not a difficult task. If a project is taken by an organization through a contract, the product scope is mentioned in the contract document. On the other hand, if the project is initiated by the organization, the product scope is to be defined by the organization by taking into consideration the requirements and expectations of all stakeholders regarding the final product.

Context-level Data Flow Diagram (DFD) is a commonly used tool to define the product scope. It displays a high-level presentation of the system that has a single process that is represented by a circle or rounded rectangle displaying the system as a whole and representing all the incoming and outgoing information between the system and its external entities.

External entities are generally depicted by a square and can be personnel, departments, or other systems that are providing or receiving the flow of information. Arrows display the direction of the flow of data between external entities and the system. Each arrow and entity must be written properly. Lower-level DFDs can be created later for modeling the processes and flows of data in more detail. An instance of a context-level DFD of a banking e-commerce system.

Another useful tool used to define the product scope is the use case diagram. This kind of diagram is used in object-oriented scenarios as part of the Unified Modeling Language (UML). The use case diagram was introduced as a tool for software development, but can also provide a high-level model to define, verify and reach an agreement related to the product scope.

Creating a use case diagram is simple in the context of using symbols and syntax; however, it is a powerful tool for determining the main functions or characteristics of the system and various users or external systems that communicate with the system.

In the initial phase of the project, a high-level diagram is provided by the use case diagram which can be later refined and detailed while performing requirements analysis in the project. In the use case diagram, actors are people who can be users, customers, managers, etc., or external systems that can communicate or use the system.

While creating a use case diagram, actors can be determined using stick figures, while use cases are displayed using ovals. Displays an example of a use case diagram for a bank:

A use case diagram allows you to provide a simple and effective outline of the functionality and interactivity between the use cases and the actors. You can see, the box separates the use cases from the actors and also creates a system boundary that is used to define the scope boundary. Use cases defined in the boundary are considered inside the project’s scope, while anything defined outside of the boundary is considered outside the project’s scope.

Enlisting the actors allows you to determine various stakeholders and understand the overall requirement of the organization. The use case diagram is also used to identify security issues. Creating the use case diagram refers to an iterative process that can be developed while having a Joint Application Development (JAD ) session.

In the JAD session, the users and systems analysts mutually illustrate the system requirements or design the system. Later in project development, the use case diagram is used for defining the product scope to refine the level of detail and functionality.

But the question arises, what is the suitable level of detail required to define the product scope? The right level helps the project manager in estimating the time required to develop the application system accurately. Estimating the time and effort for developing the application system deliverable relies on the size of the application, the number of features that need to be included, and their complexity level. Proper estimation depends upon the level of understanding of the information system that needs to be delivered.

The time and resources allocated to develop the project charter and plan may reduce the amount of time and energy required to define the information system in detail. Therefore, the aim during the planning phase of the project should be to secure sufficient detail about the information system for estimating the time and effort required to obtain this deliverable.

During the analysis and design phases, more time and resources can be committed to increasing understanding and documenting the level of detail required for creating and delivering the system.

Project-oriented Scope

Project scope is concerned with activities that must be performed to create a product. For example, the procurement of raw materials for developing software as specified by the client comes under the project scope. Project scope defines the results a project is intended to deliver, associated constraints, and assumptions. It also provides tangible evidence of the progress of the project.

Deliverable Definition Table (DDT) is a tool used to define project scope. In the table, all project deliverables to be attained by the project team are defined. Each deliverable must have a clear objective. The table shows DDT:

Deliverable	Structure	Standards	Approval Needed By	Resources Required
Business case	Document	As defined in the project methodology	Project sponsor	Business case team and office automation (OA ) tools
Project charter and project plan	Document	As defined in the project methodology	Project sponsor	Project manager, Project sponsor, & OA tools
Technology and organizational assessment	Document	As defined in the project methodology	Project manager/ project sponsor	Bank’s systems analysts, users, case tool, and OA tools
Requirements definition	Document	As defined in the project methodology	Project manager	System analysts, users, case tools, and OA tools
User interface	Document	As defined in the user interface guidelines	Project sponsor	System analyst, programmer, users, and integrated development environment (IDE)
Physical & technical design	Document	As defined in the project methodology	Project manager/ project sponsor	System analyst, programmer, and case tool
Application system	Files & Database	As defined in the project methodology	Project sponsor	Programmers, System analysts, network specialists, program development tools, and relational database management system
Testing plan	Document	As defined in the project methodology	Project manager	System analysts and OA tools
Testing results	Document	As defined in the project methodology	Project manager	Programmers, Files system analysts, and OA tools
Change management and implementation plan	Document	As defined in the project methodology	Project manager	Systems analysts and OA tools
Training program	Document	As defined in the project methodology	Project manager/ project sponsor	Trainers, documentation writers, and OA tools
Final report and presentation	Document	As defined in the project methodology	Project sponsor	Project Sponsor, project manager, and OA tools
Project evaluations and lessons learned	Document	As defined in the project methodology	Project manager/ project sponsor	Project team, knowledge management system

After defining the deliverables in the DDT, a Deliverable Structure Chart (DSC) can be created as an interim step for defining detailed work packages that will be required for estimating the project schedule and cost. Later on, these work packages can be utilized for creating a Work Breakdown Structure (WBS).

---

IT Project Scope Verification

After defining the project’s scope, it must be verified. Scope verification is all about getting a formalized acceptance of completed project deliverables from project stakeholders. The table shows the inputs, tools and techniques, and output of the scope verification process:

Input	Tool and Technique	Output
Work results: What deliverables are fully or partially completed; what costs are incurred or anticipated, etc.	Inspection: Reviews, product reviews, audits, and walk-throughs with the help of checklists (which contain deliverables, quality standards, milestones, review, and acceptance.)	Formal acceptance: Documentation stating that the client has accepted the product of the project.
Product documentation: The project’s products (plans, specifications, technical documentation, drawings, etc.)

---

Scope Change Control

Scope change control is the final stage of project scope management. At this stage, an organization tries to restrict unapproved changes in the project scope. In other words, at this stage, an organization tries to ensure that only those changes, which are approved by the client, are made in the project. Any unauthorized change in the scope of a project leads to the following situations:

• Scope Grope
  
• Scope Creep
  
• Scope Leap

Scope Grope

It refers to the inability of a project team to define the project scope. This situation occurs early in the project when the project team and sponsor face problems in understanding the functionality of the project.

Scope Creep

It describes the situation in which additional features need to be included in a project for meeting the need of the client. The inclusion of additional features consumes a lot of time and resources after the approval of the project’s scope.

For example, a project sponsor may also add some changes in the later stages of the project. Not only this, but the project team members can also come up with novel ideas during the progress of the project. The situation of scope creep must be determined and controlled during the project because it might affect the project schedule and thus, increase the cost of the project.

Scope Leap

It refers to a situation that suggests fundamental alterations in the scope of the project. Scope leap often leads to drastic changes in the entire scope and focus of the project. It occurs due to changes in the environment, the business, and the competitive nature of the industry.

Scope leap emphasizes modifying the overall goal of the project; therefore, requires the re-estimation of the value of the current project. If the changes required to be done on the project are critical, it is always better for an organization should close the current project and start with a new project.

---

Scope Change Control Procedures

A scope change procedure must be there before the commencement of the project. It must be part of or referenced in the project charter so that it can be conveyed to all project stakeholders. This procedure must cover all requested modifications to be made in the project scope.

The requests made for the scope change must be assessed to know the impact on the project. Then, a decision can be made whether to accept or reject the change in the scope.

The first step in the scope change procedure is to fill out a scope change request form. This form can be filled by the individual or group making the scope change request. A scope change request form contains some basic information, which is as follows:

• Description of the change request so that the project manager and project team should be able to understand the nature and cause of the scope change.
  
  
• Alternatives for assessing the impact on scope, schedule, resource, and cost.

These alternatives can include an extension in the deadline of the project or the addition of more resources in terms of employees, overtime, or technology. Finally, all changes required in the scope must be approved so that the allocation of additional resources can be done in the project. It must be noted that the scope change request must be approved only if the scope change can bring the project closer to achieving its overall goal.

Benefits of Scope Change Control

Generally, a project manager has to be attentive and careful while managing the project scope. If the project’s scope alters in the middle of the project, it can lead to additional costs, greater risks, and longer time duration. Many projects get failed because of poor scope management.

It is often seen that small scope changes in large numbers lead to the failure of the project. An ideal project manager knows that rigorous scope control is essential for delivering projects within the allocated time and budget.

The main focus for the project manager should not only provide the agreed scope within time and budget but also optimize the benefit that is provided by the project. If there are benefits from the project, then allowing the scope to change is a good move.

It is not necessary that all scope changes must be resisted rather it should be ensured that the impact of change must be fully reflected in the project scope.

---

Tracking and Monitoring Scope During Project Execution

Execution is the crucial stage of project management as in this stage work defined in the project management plan is put into practice to meet project objectives. It involves coordinating with people, allocating resources, addressing stakeholder expectations, and performing project activities in alignment with the project management plan.

However, during the execution phase, there is a high possibility of changes in scope in terms of alterations in expected activity duration, resource productivity and availability, and unanticipated risks. These variances can have a major impact on the project management plan.

Therefore, it is of utmost importance for a project manager to constantly track and monitor any changes in the scope during the project execution phase. Changes in scope during the execution phase can be tracked and monitored by:

• adopting a well-defined and documented process-based approach wherein the scope is defined for project activity.
  
  
• reviewing the status of the project at defined intervals and taking corrective actions if required.
  
  
• using the checklist that serves as a guide to the project manager in ensuring that the scope of the project and several of its components are managed properly without instances of scope creep
  
  
• conducting an external audit of the project. Since the external audit is done by the client or any external agency, any scope creep is glaringly pointed out by the auditors.