Project Scope Management Tutorial

5.1 Lesson 05 - Project Scope Management

Hello and welcome to PMP Certification Course offered by Simplilearn! In this lesson, we will focus on project scope management. Let us begin with the objectives of this lesson.

5.2 Objectives

After completing this lesson, you will be able to: ?Define Project Scope Management ?Differentiate between project scope and product scope ?Identify the key terms used in project scope management ?Explain work breakdown structure ?Describe the Project Scope Management processes In the next screen, let us take a look at project management process map.

5.3 Project Management Process Map

There are 47 processes in project management grouped into ten Knowledge Areas, and mapped to five Process Groups. In this lesson, we will look at the second knowledge area, i.e., (Pronounce that is) Project Scope Management and its processes. Let us begin with the first topic of this lesson, project scope management.

5.4 Project Scope Management

Project scope management includes the processes required to ensure that a project comprises all and only the work required to complete the project successfully. The project scope management is concerned about the scope; what is not there in the scope is also clearly identified. In the next screen, let us look at the key activities performed under project scope management.

5.5 Project Scope Management Activities

Let us look at few of the typical activities that happen as part of the project scope management. Constant monitoring is essential to make sure that all the project work is being completed. The gradual, uncontrolled increase in scope of the project is referred as scope creep. It is necessary to define the project scope boundaries and not let people randomly add to the project scope. Gold plating is doing more than what is required as part of the project scope. This has to be avoided in projects. As per the published statistics about projects done globally, less than 40 percent projects can be considered successful. Therefore, the focus should be on what is required rather than squandering around with what is not required. 40 percent might be considered less, but a project is classified as successful only if it meets all its objectives and is done within time and cost budgets. In the next screen, let us understand the difference between product scope and project scope.

5.6 Product Scope vs. Project Scope

Project scope management deals with managing both the product scope as well as the project scope. Product scope refers to the features and functions that characterize a product, service, or result. The word “product” may also include creation of a service. For example, in the banking industry, each of their services is called as product. Likewise, savings account is one of their products; mutual fund is another. On the other hand, project scope is the work that needs to be accomplished to deliver the output of the project, which could be a product, service, or result with the specified features and functions. For instance, to deliver a product, you may also need to produce a requirements document or a design document. These are not part of the product scope, but it may very well be part of the project scope. In the next screen, let us discuss a few key terms used in the project scope management.

5.7 Key Terms

WBS (Pronounce as W-B-S) stands for work breakdown structure. It means breaking the project deliverables into smaller and more manageable components called work packages. The last level of work in such subdivision is called “work packages” and the whole structure is called “WBS.” For example, a typical software development project would have various activities, like finalizing requirements, designing the new system, coding, testing, and going live with the new system. Each of these translates into high level deliverables, which can be further subdivided into smaller activities which are more predictable. WBS dictionary, like any dictionary contains the explanation of the terms used in WBS. A typical WBS dictionary has details like the control account, name of the work package, description of the work package, resource assigned, if there are any assumptions or dependencies to complete the work package, the due date to finish the work package, technical dependencies, and so on. WBS dictionary is useful for the person or group working on the work package as it further elaborates the decomposed work package. Control account is a level within WBS at which management wishes to exercise control, for example, perform earned value analysis, track performance, etc. In the next screen, let us cover Work Breakdown Structure in detail.

5.8 Work Breakdown Structure

Along with the scope statement and the WBS dictionary, the work breakdown structure forms the scope baseline of the project, i.e., it should reflect the entire scope of the project. Any deliverables that are not reflected in WBS are not part of the project. The creation of the WBS should involve the whole team. The creation of WBS creates common understanding about the scope and therefore leads to team buy-in. During decomposing the deliverables, you must ensure that each level is complete i.e., it includes all the work in the project, before you start to decompose further. Decomposition continues until the lowest level deliverable cannot be logically sub-divided further or they can be estimated with reasonable accuracy. WBS is a “deliverable-oriented” decomposition. It should only contain deliverables and not activities. While developing the schedule, converting the deliverables into activities is one of the problems as WBS does not contain activity level details. Concept based questions on Work Breakdown Structure can be expected in the exam. So it is essential to have a clear understanding of the concept of WBS. In the next screen, let us look into an example, which shows how WBS is derived.

5.9 Work Breakdown Structure - Example

Work breakdown structure of a core banking software development project is given on the screen. The scope of project has been divided into WBS elements, like requirements documentation, design and architecture, code, test, and go live. Further, these elements are decomposed into work package level to make it easier to manage the deliverables in terms of scope, cost, time. It also helps to estimate or assign the specific work packages to team members or groups. The design and architecture has been decomposed to model and prototype. Similarly, code is decomposed into work package 3.1 and 3.2, test into work package 4.1 and 4.2, and go live into product installer and warranty sheet. WP 3.1 can be represented as module 1 and WP 3.2 as module 2. Similarly, WP 4.1 may be test strategy document and WP 4.2 a test plan document. The number here indicates work breakdown code. In the next screen, let us discuss how project scope management is actually accomplished.

5.10 Project Scope Management Processes

There are six project management processes, which are part of project scope management knowledge area. These processes are: plan scope management; collect requirements; define scope; create WBS; validate scope; and control scope. The first four processes, i.e., plan scope management, collect requirements, define scope, and create WBS are part of the planning process group; and the remaining two processes, validate scope and control scope, are executed as part of the monitoring and controlling process group. In the next few screens, we will look at each of these processes in detail. Let’s begin with plan scope management.

5.11 Plan Scope Management

Plan scope management process creates a scope management plan that documents how the project scope will be defined, validated, and controlled. It is usually the starting point of the planning processes on a project. Understanding the scope and how it will be managed is fundamental to planning the other aspects of the project. Let us review the list of inputs to this process. The project management plan provides other subsidiary plans and will help guide the scope planning activities on the project. The project charter provides an overall context and the high-level product and project description, which may help determining the approach for scope management. Enterprise environmental factors provide the organizational context to the project, including the culture of the organization, the infrastructure, key personnel, and so on. Organizational process assets provide inputs such as policies and procedures, historical information, and knowledge base. Now, let us look at the tools and techniques employed in this process. Expert judgment refers to input received from knowledgeable and experienced resources. Meetings may be organized to determine the scope management plan. Everyone responsible for the project scope management, such as the project manager, sponsor, customer, and other stakeholders must attend these meetings. Now, let us look at the outputs of this process. The scope management plan describes how the project’s scope will be defined, like who will be involved in the process, whose inputs will be sought, what techniques may be used to get those inputs, etc., developed, i.e., in what form will the scope be elaborated and documented, monitored and controlled, and verified. The plan may also describe how WBS will be created from the scope statement, how changes to the scope will be managed, how deliverables will receive formal acceptance, etc. The requirements management plan is a subsidiary of the project management plan that describes how requirements will be analyzed, documented, and managed. A requirement is voiced by a customer or a stakeholder, whereas scope represents what the project team will do or deliver to meet that need. The requirement management plan may also describe how the configuration management of the requirements will be carried out, how they will be prioritized, how the metrics will be used to rationalize these choices and how the traceability of the requirements will be maintained throughout the project. You may get questions in the PMP exam, based on the inputs, tools and techniques, and outputs of plan scope management. So understanding of these topics will help you to answer concept based questions correctly. In the next screen, let us look at the second process, Collect Requirements.

5.12 Collect Requirements

Collect requirements is the second of the six project scope management processes. It is the process of defining and documenting stakeholder’s needs to meet the project objectives. Let us look at the inputs to this process. Scope management and the requirements management plan provide clarity on how the team should go about collecting and documenting the requirements for the project. The stakeholder management plan provides insights into the stakeholder’s communication requirements and the level of stakeholder engagement needed. The stakeholder register may provide useful guidance about which of the stakeholders could provide the requirements for the project. It is very important that all the stakeholder’s expectations are captured adequately and represented in the requirements documentation. The project charter provides high-level requirements and expectations and may be used to detail out the requirements. Now, let us look at the tools and techniques that can be employed to collect the requirements. It is important for the project team to use a combination of techniques that will give them maximum clarity about the requirements. Some of the techniques may include direct interaction like interviewing, forming focus groups, conducting workshops, and using group creativity techniques, like brainstorming, and group decision making techniques. It may also include some offline activities like conducting surveys via questionnaires, etc. Observation can be a very powerful way to capture requirements that may be difficult to state or articulate. Prototyping is a powerful technique where the team comes up with a model or sample artifact that helps the users visualize and gain more clarity about what is being developed. Benchmarking is useful for understanding and learning from the industry and organizational benchmarks about the bare minimum expectations. Use of context diagrams and analyzing the documentation provided can also help in collecting requirements. Requirements documentation is one of the most important output. The second output of this process is requirements traceability matrix. This table helps trace whether the work has happened on the requirements, whether all requirements are reflected in the final product of the project, etc. In the next screen, let us look into a business scenario to understand this concept better. After reading the problem statement, click the solution button to look at a possible answer.

5.13 Business Scenario—Problem Statement

In the next screen, let us discuss group creativity techniques.

5.14 Group Creativity Techniques

Group creativity techniques are used to channelize a group’s combined brainpower to solve a problem, identify requirements or risks, or make a decision. Some of the popular group creativity techniques are brainstorming, nominal group technique, idea or mind mapping, affinity diagram, multi-criteria decision analysis. Click each tab to learn about group creativity techniques. Brainstorming is used to generate many ideas in a short span of time. It does not involve critique, analysis, or prioritization. The idea is to stimulate lateral thinking by promoting free, unfettered thinking among a group. Nominal group technique is used to select from a set of ideas combines brainstorming with a voting process to identify the select ideas for further thought or prioritization. Idea or mind mapping combines ideas from individual brainstorming for identifying commonality and differences in thinking. Affinity diagram is useful for categorizing ideas into groups for review and further analysis. Multi-criteria decision analysis utilizes a decision matrix to provide a systematic approach for decision-making based on multiple criteria. In the next screen, let us discuss the group decision-making techniques.

5.15 Group Decision-Making Techniques

Group decision-making techniques are used to arrive at decisions when many people are involved in the decision making process. The commonly used methods are unanimity, majority, plurality, and dictatorship. Click each tab to learn about group decision-making techniques. Group Decision-Making Techniques Everyone agreeing on a single course of action may take extensive discussions prior to reaching this stage. It may be preceded by a technique such as the Delphi technique where people answer questionnaires and reconcile differences with group thinking in a sequential process. In a majority system, decisions are taken based on the choice of 50 percent or more of the group. In a system of plurality, there are typically multiple options available and decision is taken by a single group or block even if they are not in majority. In dictatorship, one individual makes the decision on behalf of the group. In the next screen, let us discuss requirements traceability matrix.

5.16 Requirements Traceability Matrix

Given on the screen is an example of the requirements traceability matrix. It lists all the requirements recorded in the requirements documentation in the first column. In the subsequent columns, it traces how the requirement is being met by specific sections or objects in the subsequent stages. In case of a software development project, the requirement about enabling multi-user access may require changes in multiple places. These are specifically called out in the columns titled design, coding, testing, etc. This ensures each requirement is specifically addressed through all the stages of the life cycle and also provides a backwards traceability by clarifying why a particular change is made at each stage (i.e., which requirement is driving these changes). A typical question in the PMP exam can be one related to the creation of WBS. So understanding the requirements traceability matrix will help you to answer concept based questions. In the next screen, let us look at the third project scope management process, define scope.

5.17 Define Scope

The next process in the project scope management is “define scope.” Define scope is the process of developing a detailed description of the project and product. Collect requirements lists for all the different requirements or needs expressed by the stakeholders. Define scope deals with detailing these requirements and determining what will be in the scope of the project and what will not be. It belongs to the planning process group. Let us look at the inputs to this process. The scope management plan provides the details about the process of capturing and documenting the scope of the project. Project charter, which describes the business need of the project, and the requirements documentation developed as part of the collect requirement process also form inputs to this process. Organizational process assets are also a part of the define scope process. Organization template may be used to write the project scope or refer to the lessons learned from previous, similar projects. For projects, which have product instead of a service as an output, product analysis is a commonly used technique. This defines what is required in a project’s product. Alternatives generation is a technique used to see if the project requirements can be completed in a different way, similar to lateral thinking. Expert judgment is a technique using an expert, may be an external consultant to look at various requirements and come up with the project scope statement. In order to define the scope, you may also conduct specific workshops that are facilitated to generate ideas around the project scope. The output of this process is the project scope statement, which describes in detail the project’s deliverables and the work required to create those deliverables. Therefore, the project scope statement has project’s product scope description, product acceptance criteria, project deliverables, and project constraints. This process also results in updating the requirements documentation and requirement traceability matrix developed earlier. Let us look at the next process, Create WBS.

5.18 Create WBS

The final planning process within scope management is Create WBS. Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. It belongs to the planning process group. The WBS is created with project scope statement and the requirements document as input. The scope management plan provides the details about the process of capturing and documenting the scope of the project, and how the deliverables should be decomposed in the form of a WBS and how it should be maintained. The templates and standards related to the industry and the specific enterprise may be useful in creating WBS. If there is an organization’s template for writing down WBS, that is also used. The other two inputs are organizational process assets and enterprise environmental factors. Decomposition is an important technique used in this process. In decomposition, the project deliverables are subdivided into smaller, more manageable components until the work and deliverables are defined at the work package level. The work package level is the lowest level in the WBS and is the point at which the cost and activity duration of the work can be reliably estimated and managed. The level of detail for work packages vary as per the size and complexity of the project. Another technique used is expert judgment. The output of this process is scope baseline. The project scope statement, WBS and WBS dictionary are collectively referred as scope baseline. Scope baseline is part of project management plan. This process also results in project document updates. Implementing WBS may result in getting more clarity about the requirements itself. The requirement document or the project scope statement developed earlier should be updated. In the next screen, let us look at the validate scope process.

5.19 Validate Scope

Validate scope is the process of formalizing acceptance of the completed project deliverables. Validating scope includes reviewing deliverables with the customer or sponsor to ensure they are completed satisfactorily and obtain formal acceptance. Validate scope is closely related to quality control as well. However, scope validation is primarily concerned with acceptance of the deliverables; whereas, quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables. Quality control is generally performed before scope validation, but these two processes can be performed in parallel as well. Let us look at the inputs to this process. The project management plan provides information about how the deliverables will be validated and accepted by the customer and other stakeholders. The requirements documentation acts as the basis on which the validation activity is to be carried out. The requirements traceability matrix documents how each of the requirements has been implemented and how it can be validated. The fourth input is verified deliverables and implies that the verification activity is first carried out by the team under the control quality process, and only then, the deliverable enters the validation process. Work performance data gives more inputs on the deliverables that may be useful in validating and getting acceptance. The technique used to validate scope is inspection and group decision making. Some of the typical activities that are done as part of inspection are measuring, examining, and validating to determine whether the work and deliverables meet requirements and product acceptance criteria. Group decision-making techniques may be employed if a team is working on the process of validating the deliverables. It helps in arriving at a decision by either consensus or majority or any other method. The output of this process is the accepted deliverable. Sometimes deliverable might be acceptable and that results in another output, i.e., change request. Due to the validation process, the information about the deliverables, which have been accepted, and any observations during the validation process may be recorded. Some documents, like report on status of the project’s product, is updated as result of this process, and listed as one of the outputs. In the next screen, let us look at the control scope process.

5.20 Control Scope

Control scope is the process of monitoring the status of the project and product scope and changes to the scope baseline. Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the “perform integrated change control process.” The inputs project management plan, requirements documentation, and work performance data are the same as the inputs for control scope and validate scope. Work performance data has information about progress of work on the different deliverables. The other input is requirements traceability matrix, which lists the requirements included in the requirements document. Organization process assets also influence control scope in a sense where an organization would have standard templates for monitoring and reporting scope related updates. Scope control is performed using variance analysis. The variation is measured from the original scope baseline, which decides whether any corrective or preventive action is required. The key output of the control scope is work performance information, which is planned versus actual technical scope performance. If any part of the scope performance does not meet the acceptance criteria, it may result in change requests, which is the other major output of this process. All of these may result in updates to the project plan as well as other project and organizational process documents. Business scenario based questions on scope control can be expected in the PMP exam. So understanding the concept of scope control is essential. In the next screen, let us look into a business scenario to understand this concept better. After reading the problem statement, click the solution button to look at a possible answer.

5.21 Business Scenario-Problem Statement

Let us now check your understanding of the topics covered in this lesson.

5.22 Quiz

A few questions will be presented in the following screens. Select the correct option and click submit to see the feedback.

5.23 Summary

Here is a quick recap of what was covered in this lesson: Project Scope Management includes the processes required to ensure that a project includes all and only the work essential to complete the project successfully. Product scope refers to the features and functions that characterize a product, service, or result, while project scope refers to the work that must be performed to deliver a product, service, or result with the specified features and functions. Work Breakdown Structure breaks the project scope into smaller and more manageable pieces called work packages which are easy to manage. WBS dictionary contains the explanation of the terms used in WBS. The six Project Scope Management processes are Plan Scope Management, Collect Requirements, Define Scope, Create WBS, Validate Scope, and Control Scope.

5.24 Conclusion

With this, we have come to the end of this lesson. In the next lesson, we will cover project time management.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Phone Number*
Job Title*