Locked lesson.
About this lesson
The project scope is the sum of all the work that must be done on the project. Scope management is focused on defining and controlling what must be done on the project and what does not need to be done.
Exercise files
Download this lesson’s related exercise files.
Project Scope Management.docx65.6 KB Project Scope Management - Solution.docx
75.6 KB
Quick reference
Project Scope Management
The project scope is the sum of all the work that must be done on the project. Scope management is focused on defining and controlling what must be done on the project and what does not need to be done.
When to use
Scope management processes are used throughout the project lifecycle. As soon as the Project Charter is set, the project manager will begin to manage the project scope. And the final steps of the project are to turn over the product, service, or result of the project to the customer or stakeholders. It is to deliver the scope.
Instructions
Project Scope Management
"Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.” PMBOK® Guide
Scope management answers the question, “What must be done?” Because projects often start with a cloud of uncertainty around them, the scope must be managed closely to avoid “Scope Creep;” which is the expansion of project scope without a corresponding change in the cost and schedule. Project scope consists of two components, both are managed by these processes.
- Product Scope: “The features and functions that characterize a product, service, or result.” PMBOK® Guide
- Project Scope: “The work performed to deliver a product, service, or result with the specified features and functions.” PMBOK® Guide
Much of the work of these processes involves defining and controlling requirements. Then ensuring that the work done on the project conforms to those requirements.
Project Scope Management Processes
There are six Project Scope Management Processes. They relate to each other as shown in the diagram below. All six rely on the project management plan as an input, in addition, scope management plan and requirements management plan become incorporated into the project management plan and provide specific guidance to the other scope management processes. The six processes are:
-
5.1 Plan Scope Management: “The process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled.” PMBOK® Guide
-
5.2 Collect Requirements: “The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.” PMBOK® Guide
-
5.3 Define Scope: “The process of developing a detailed description of the project and product.” PMBOK® Guide
-
5.4 Create WBS: “The process of subdividing project deliverables and project work into smaller, more manageable components.” PMBOK® Guide
-
5.5 Validate Scope: “The process of formalizing acceptance of the completed project deliverables.” PMBOK® Guide
-
5.6 Control Scope: “The process of monitoring the status of the project and product scope and managing changes to the scope baseline.” PMBOK® Guide
.
Scope Statement, Requirements Traceability Matrix, and Work Breakdown Structure
The Scope Statement, Requirements Traceability Matrix and Work Breakdown Structure are the three primary outputs of the scope management processes that actually set the project scope. Each of these provide important information about the project scope.
The scope statement is a description of the project deliverables along with appropriate assumptions and constraints about those deliverables. It is sometimes referred to as the “Definition of Done” for the project. There are virtually an infinite number of formats, use what works for your organization.
The requirements traceability matrix is often used to document the requirements. It provides a visual display of how customer and stakeholder needs are translated into specific project tasks and deliverables. On a complex technical project it is invaluable, but unfortunately often overlooked or used as documentation exercise at the close of the project instead of managing scope throughout. This matrix is normally created in a spreadsheet or table. While there is no industry standard for the format, it generally flows from left to right showing greater definition of a requirement and then documenting the testing and validation activities.
The third output is the Work Breakdown Structure (WBS). This is a document that identifies each of the tasks, activities or work packages that must be done on the project. It should contain entries showing the work to complete the product deliverables and the project deliverables. This can be organized in many different manners. It can be organized by project phase, by major deliverables, by organization or department leading the effort, by geography or by virtually any other way you want to do it. I recommend that you organize the WBS in the manner in which you will be managing and controlling the project and the WBS will then make those tasks easier. When the WBS is documented within a spreadsheet or table, additional columns or fields of project planning information can be included with the task description such as estimates, schedules, risks, resources, or status. When this information is added, the document is now referred to as a WBS Dictionary. Again, organize it the way you want to manage the project. The WBS is normally considered to be the project scope baseline.
Definitions are taken from the Glossary of the Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017, Pages 701, 703, 704, 713 and 725.
Login to downloadLesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.