Project Scope Management Knowledge Area is concerned with the work that is needed to achieve the project’s deliverables.
Project Scope Management Knowledge Area includes identifying the objectives and deliverables, converting objectives into action-oriented tasks, making sure that the project team does only the work agreed upon, and verifying that the completed work meets the requirements.
Project scope management processes are concerned with the work needed to meet the project’s objectives.
These processes start immediately after the project is initiated and continue until the project is closed.
Though they are easiest to follow in the logical order in which they’re presented, project scope management processes are iterative and will be revisited throughout the life of the project and may be performed several times in a multi-phased project.
The processes in Project Scope Management are:
- Collect Requirements (5.1)
Determines what objectives and deliverables the project needs to meet.
- Define Scope (5.2)
Converts the objectives and deliverables into action-oriented tasks in a narrative format.
- Create WBS (5.3)
Organizes the project scope into a graphical categorization of deliverables and activities.
- Verify Scope (5.4)
Ensures that the deliverables produce to fulfill the agreed upon requirements.
- Control Scope (5.5)
Makes sure that only the work agreed upon is performed by the project team.
There are four critical activities that should be completed before project scope management can begin:
- Since we can’t determine the work to be performed without a general understanding of the project, we’ll need the project charter (4.1 Develop Project Charter).
- In order to determine the explicit objectives and deliverables the project needs to produce, we’re going to have to talk to the customer and stakeholders, which means we need to know who all the stakeholders are.
The stakeholder register, created in section (10.1 Identify Stakeholders), provides us this list.
- The specific needs of the customer and stakeholders will drive the project work (and thus the project scope), so before we start collecting those requirements, we’ll need to know how we’ll approach gathering, organizing, prioritizing, and managing of the requirements.
All this is described in the requirements management plan, a subsidiary component of the project management plan. The requirements management plan is created in section (5.1 Collect Requirements Process)
- We’ll need to pre-plan our approach towards identifying, categorizing, and controlling the project scope.
Scope preplanning includes things like how the work will be organized, what approvals are required for the scope, and what kind of scope change control will be needed.
All this information is contained in the scope management plan, created as a subsidiary component of the project management plan in section (4.2 Develop Project Management Plan).
Product and Project Scopes
The two scopes are closely related yet serve distinct purposes, so understanding their differences will help us better grasp the project scope management processes.
The product scope describes the characteristics of the project’s final product, service, or result, and we can think of it as describing what we need to produce.
It’s a good project management practice to create a product scope if it doesn’t exist.
In generalized terms, the customer and stakeholders will be describing the product scope when describing what they need, so the project team can use that as a basis for authoring the product description.
Though it’ll depend on what the final product, service, or result is and whether it’s tangible or intangible, the product scope describes:
- What product, service or the result will do.
- How the product, service, or result will be used.
- How the product, service, or result will function.
- What the product will look like, what the service is, or what the result will be.
- What impact the product, service, or result will have on the organization, customer, stakeholders, and business processes.
- Describes any constraints, restrictions, standards, regulations, and other requirements related to the product.
The project management team should know the product in great detail, and that the project team needs at least a solid understanding of it, and this holds true even if the project is only creating a portion of the overall product.
The product scope should not be seen as a “need-to-know” item because the fact is that everyone –the entire team and the stakeholders—need to know what the project’s final product, service, or result is all about.
When everyone understands the product scope the team is more likely to come up with more efficient, innovative, and resilient project decisions.
The project scope textually describes the work the project team will perform to achieve all the project’s objectives.
We can think of it as describing how we’ll produce the project’s deliverables, which not only includes the final product but any other deliverables required, such as those for project management activities.
Because the project scope will drive what activities occur, it must describe in great detail and without any chance of misinterpretation how and in what steps the deliverables will be produced.
Without a well-defined project scope and the controlling processes to protect it from unmanaged changes, the project is likely to encounter scope creep –changes that have a way of working themselves into a project that blows its schedule and budget.
Requirements Management Plan Requirements are the constituent needs, objectives, and specifications the project’s deliverables must meet in order to be successful.
Preplanning is needed to determine how requirements from the customer, stakeholders, and the project team will be collected, organized, prioritized, tracked, and measured.
The completed preplanning is documented in the requirements management plan, created in the Collect Requirements process (section 5.1) though it’s a subsidiary component of the project management plan.
The main purposes of the requirements management plan are to help to ensure that nothing is missed while requirements are collected and that requirements and subsequent changes are properly linked to deliverables and scope.
For example, if one of the customer’s requirements is that the final product is biodegradable then that need will be linked to any component deliverables that go into the product’s final makeup.
How detailed the requirements management plan needs to depend upon the complexity of the project and the number of requirements that are expected surface, but in general the plan should cover:
- The kinds of interactions that will occur with the customer and stakeholders to collect requirements
- The categorization methods for requirements. The categories will be specific to the industry, product type, development life cycle, and application area of the project, but examples of classifications might include functional customer, design, quality, and testing.
- With the anticipation that there will be more requirements that can be met within the project’s schedule or budget, the requirements management plan should describe the prioritization, scoring, and approval methods that will be used to develop an approved requirements list.
- The configuration management activities that will ensure how changes to requirements will be evaluated, tracked, approved, and reported.
Scope Management Plan
Each knowledge area has at least one subsidiary plan focusing on a specific subject as part of the overall project management plan.
Preplanning is the purpose of these components, and these plans map out the specific requirements for the deliverables and project management processes that will take place in that knowledge area.
This preplanning may sound like a lot of work, but we can think of these subsidiary plans as being the scope statements for the knowledge area because they describe the who, what, where, why, and how of the project management work that will be performed for that section’s subject matter.
The scope management plan is a subsidiary component of the project management plan, created in the Develop Project Management Plan process (4.2), and it should be established before too much work begins in the scope processes because it describes:
- What activities, methods, and processes will be used for creating the project scope statement.
- How the scope will be approved by the stakeholders and project team.
- How the project work will be categorized and organized (the work breakdown structure).
- How likely scope changes are to occur on the project.
- What the procedure will be for the stakeholders to formally accept the project’s deliverables.
As with other subsidiary plans, templates can help provide the basis for the scope management plan.
The complexity of the project and how likely scope changes are to occur will be factors in deciding how detailed the scope management plan needs to be.