Scope Domain
ECO Domain: Process Domain — Task 2: Develop and manage project scope Related principles: Focus on Value, Embed Quality Into Processes and Deliverables, Integrate Sustainability Within All Project Areas
Definition
Scope carries a unique and central place in project management, as the value of a project derives from the outcome delivered in alignment with its scope. The Scope performance domain includes the processes required to ensure that the project encompasses all of the work required to complete the project successfully and that only the required work is mapped and no unnecessary work is performed, thus helping to optimize costs and schedule in order to maximize the project’s value.
In addition to defining and managing the scope, the Scope performance domain also focuses on project quality. Quality is defined by meeting stakeholder expectations and fulfilling the project and product requirements. This performance domain helps ensure that deliverables meet the specified acceptance criteria and that the processes used to produce them are effective and efficient. The domain emphasizes continuous process improvement, helping to ensure that both scope and quality are aligned and consistently meet the project’s objectives and standards.
Key Concepts
Business Case
The business case is a documented economic feasibility study used to establish validity of the benefits to be delivered by a portfolio component, program, or project. Projects are initiated through a business case that outlines costs, benefits, and how value will be created, together with project success criteria. See Business Case.
Project Scope
Project scope encompasses the work performed to deliver a product, service, or result with the specified features and functions. The project scope helps ensure that the expected value is achieved. Scope encapsulates a project’s expected value, so it is the most important component of any project’s baseline. The delivery of any project’s scope should generate expected value that is not only worth the time and resources invested, but also ideally maximized.
Requirement
A requirement is a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need. See Requirements Documentation.
Scope Baseline
In predictive environments, the scope baseline is the approved version of formal scope documents (project scope statement + Work Breakdown Structure (WBS) + WBS dictionary) that can be changed using formal change control procedures and is used as the basis for comparison to actual results. The scope baseline forms part of the performance measurement baseline (PMB), which also includes the schedule baseline and the cost baseline. For adaptive approaches, the baseline is defined at the beginning of each iteration and aligned with the prioritized requirements; a product owner dynamically approves changes in a more flexible environment.
Work Breakdown Structure (WBS)
In predictive or hybrid projects, the Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work into smaller, manageable work packages that can be easily assigned, tracked, and measured. The WBS together with the project scope statement and WBS dictionary constitutes the scope baseline. A WBS dictionary may provide additional details about each WBS component: scope descriptions, milestones, responsible parties, resource needs, and acceptance criteria.
Quality as a Feature
Quality is an integral attribute of scope and can include both functional and nonfunctional requirements of the product, service, or result. For example, a bridge-construction project scope would include the bridge but also incorporate target thresholds for how sturdy, long-lasting, and easy to maintain it should be. These quality features are the same as any consideration of scope, including cost and schedule trade-offs that yield the highest possible expected lifetime value per unit of investment.
Product Scope
The product scope is a description of the features, functions, and characteristics of the product, service, or result the project is intended to deliver. It is what the end result should look like and what it should do. The focus is on the deliverables themselves, including their quality and performance specifications.
Value Breakdown Structure (VBS)
A VBS is a hierarchical structure that connects the project scope and its intended value to the product scope that will generate that value. The top level includes the major deliverables with value-based estimates (dollars of revenue, lives saved, or percentage of expected total project value). These value-added estimates can be used to prioritize deliverables and activities, and to estimate the drag cost of each critical path item. Each VBS item is then decomposed through a Work Breakdown Structure (WBS) into project scope and activities.
Product Backlog
The product backlog is a dynamic, prioritized list of work items and features. In adaptive environments, the product backlog provides a framework for managing scope by focusing on value-driven outcomes, enabling continuous prioritization, and maintaining alignment with stakeholder expectations. See Backlog Management.
Definition of Done (DoD)
The Definition of Done (DoD) is a checklist of all criteria required to be met so that a deliverable can be considered ready for customer use. In adaptive approaches, the DoD is a shared understanding of the specific criteria that should be met before a piece of work (user story, feature, or increment) is considered complete and ready for release.
Processes
Plan Scope Management
Creates a scope management plan that documents how the project and product scope will be defined, validated, and controlled throughout the project life cycle.
| Field | Detail |
|---|---|
| Key inputs | Project charter, project management plan, project documents (requirements documentation, risk register, stakeholder register), EEFs, OPAs |
| Key tools | Expert judgment, data gathering (interviews, focus groups, questionnaires and surveys), data analysis, test and inspection planning |
| Key outputs | Project management plan updates (scope management plan, requirements management plan) |
Elicit and Analyze Requirements
Determines, documents, and manages stakeholder needs and requirements to meet project objectives. In adaptive environments, requirements are collected as user stories prioritized in a backlog.
| Field | Detail |
|---|---|
| Key inputs | Project charter, agreements, business case, project documents (assumption log, lessons learned register, stakeholder register), requirements management plan, EEFs, OPAs |
| Key tools | Expert judgment, decision-making, data gathering (benchmarking, brainstorming, focus groups, interviews, questionnaires and surveys), document analysis, data representation, interpersonal & team skills (nominal group), design thinking, prioritization/ranking, meetings |
| Key outputs | Requirements Documentation |
Define Scope
Develops a detailed or high-level description of the project, product, and value expected to be delivered, as well as a quality management plan. Done at project start (predictive) or at the beginning of each iteration (adaptive/hybrid). Also identifies quality requirements and standards, and determines how the project will demonstrate compliance.
| Field | Detail |
|---|---|
| Key inputs | Project charter, assumption log, project management plan, requirements documentation, EEFs, OPAs |
| Key tools | Expert judgment, decision-making, data analysis, decomposition, interpersonal & team skills (facilitation), product analysis |
| Key outputs | Project scope statement, requirements documentation updates |
Develop Scope Structure
Subdivides project deliverables and project work into smaller, more manageable components. In predictive projects: creates the Work Breakdown Structure (WBS) and WBS dictionary. In agile projects: corresponds to product backlog breakdown into epics, features, and user stories.
| Field | Detail |
|---|---|
| Key inputs | Project management plan, project scope statement, requirements documentation, approved changes, EEFs, OPAs |
| Key tools | Expert judgment, brainstorming, decomposition |
| Key outputs | Scope baseline, Work Breakdown Structure (WBS), WBS dictionary, user stories, product backlog |
Monitor and Control Scope
Monitors and manages changes to the project scope — and measures the quality and value of deliverables to fulfill quality standards. Controls how requests for changes to the detailed project scope statement will be processed while ensuring deliverables meet specified quality requirements and scope is aligned to the scope baseline.
| Field | Detail |
|---|---|
| Key inputs | Project management plan (scope management plan, quality management plan), requirements documentation, performance measurement baseline (Integrated Baseline), quality test and evaluation documents, quality metrics, approved change requests, deliverables, EEFs, OPAs |
| Key tools | Data analysis (variance analysis, trend analysis, root cause analysis), performance reviews, audits and inspections, testing/product evaluations, data representations, process automations |
| Key outputs | Quality reports, verified deliverables, change requests, quality control measurements, project management plan updates, project document updates (requirements documentation, lessons learned register), work performance information |
Validate Scope
Formalizes acceptance of completed project deliverables. Two main objectives: checking processes against quality standards AND formalizing acceptance of deliverables. Increases the probability of acceptance of the product, service, or result delivered.
| Field | Detail |
|---|---|
| Key inputs | Project documents (requirements documentation, scope baseline, quality reports, work performance data, quality control measurements), verified deliverables, EEFs, OPAs |
| Key tools | Data gathering, data analysis, inspection, decision-making, customer talks and tests, process analysis, review meetings |
| Key outputs | Accepted deliverables, change requests, project document updates (quality reports, work performance information, requirements documentation), lessons learned updates |
Tailoring Considerations
- Dependency on external partners — Projects involving external partnerships require early alignment on scope integration into contractual agreements, setting expectations and defining boundaries. Managing scope with third-party suppliers or subcontractors requires harmonization of contractual obligations.
- Environmental dynamics — In high-dynamism environments (market volatility, rapid technology change, evolving customer preferences), scope management should be flexible with iterative feedback mechanisms that allow real-time scope adjustments.
- Design phase — Some industries (pharmaceutical, construction) rely heavily on the design phase. Investing considerable effort in early stages of scope definition prevents costly changes in later stages — strategic rescoping during design allows comprehensive evaluation before substantial resources are committed.
- Adaptive and hybrid life cycles — Adaptive scope is refined throughout iterations. Hybrid projects face added complexity: overall expectations are set with scope/schedule/cost baselines, while subteams work iteratively on user stories in the backlog. Greater need for tailored approaches that accommodate varied ways of working.
Worked examples from PMBOK8:
Example 1 — New product with backlog: Rather than delivering all user stories on the backlog, the team focuses on the main product goals to satisfy customer expectations; scope is refined through different iterations.
Example 2 — Mobile app for new market: An iterative approach with a clear MVP created with the minimum features collected in a backlog provides rapid feedback and better adaptation to changes where little information is available about customer preferences.
Example 3 — City park with tight timeline: With multiple stakeholders providing requirements and feedback, the project manager invests more time in the design phase, creating multiple mock-ups to evaluate before beginning construction.
Domain Interactions
Scope does not exist in isolation — it is deeply interconnected with other performance domains that collectively determine a project’s success.
| Direction | Domain | Nature of interaction |
|---|---|---|
| Scope ↔ | Schedule Domain | Directly impacted by any scope change; scope defines the work that drives schedule activities |
| Scope ↔ | Finance Domain | Directly impacted by any scope change; scope determines resource requirements and thus cost |
| Scope ↔ | Governance Domain | Changes to project scope are navigated within governance structures; scope modifications require review and approval to ensure alignment with strategic objectives |
| Scope ↔ | Stakeholders Domain | Stakeholder requirements drive scope definition; stakeholder acceptance validates scope delivery |
| Scope ↔ | Risk Domain | Managing risk is intrinsic to managing scope; comprehensive risk analysis is crucial to understanding potential impacts; rescoping may be employed to mitigate, avoid, or transfer risks |
Check Outcomes
Table 2-6 from PMBOK8 §2.2.5:
| Outcome | How to check |
|---|---|
| The project employs effective change management | Predictive: change log demonstrates changes with impact on all six performance domains. Adaptive: backlog shows rate of accomplishing scope, rate of adding new scope, and prioritization/inclusion of stakeholder feedback |
| There is a clear understanding of requirements | Predictive: fewer changes in initial requirements may reflect understanding. Adaptive: each iteration provides clear and well-defined short-term requirements, enabling a rolling wave approach to uncovering and refining longer-term requirements |
| The project is aligned with business objectives and strategy | Business Case and organizational strategic plan demonstrate that project deliverables and business objectives are aligned |
| Stakeholders accept and are satisfied with deliverables | Interviews, observation, and end-user feedback indicate satisfaction; levels of complaints and returns may also indicate satisfaction |
| Scope items are clearly defined (Scope Definition Accuracy) | Scope Definition Accuracy (%) = (Planned Scope Items Correctly Delivered / Total Planned Scope Items) × 100 |
| Scope creep is measured | Scope Creep (%) = (Total Deliverables / Unplanned Deliverables) × 100 |
| Requirements stability is measured | Requirements Stability (%) = (Total Requirements / Unchanged Requirements) × 100 |
| Sustainability is considered in the project scope | Work Breakdown Structure (WBS) or backlog includes activities to manage sustainability (e.g., assess/manage CO2 emissions, manage impact on local biodiversity) |
Exam angle
- Project scope vs. product scope trap: Project scope = work performed to deliver the product; product scope = features and functions of the product itself — exam scenarios test whether you identify which is changing when a change request is submitted
- Validate Scope vs. quality control: Validate Scope = formal acceptance by stakeholders (external focus, customer signs off); quality control = checking deliverable meets specifications (internal focus, team checks) — wrong answers confuse these or say they’re the same
- WBS vs. product backlog: WBS = predictive/hybrid hierarchical decomposition; product backlog = adaptive prioritized list — wrong answers apply WBS logic (sequential decomposition, formal baseline) to agile contexts
- Scope baseline composition: Scope baseline = project scope statement + WBS + WBS dictionary together — exam traps omit the WBS dictionary or include the cost baseline in the scope baseline definition
- VBS distinction: VBS connects project scope to value; the top level includes major deliverables with value-based estimates — this is not the same as a WBS; VBS is used for value-based prioritization, not just decomposition
- Hybrid life cycle complexity: Hybrid projects have an overall scope/schedule/cost baseline AND subteam backlogs — wrong answers treat hybrid as purely predictive or purely adaptive; correct answers acknowledge the dual governance structure