Scope Performance Domain: Defining and Managing Project Work

Scope and Value

Scope defines the work needed to deliver a project’s intended value. Value is realized only when the outcome aligns with the agreed scope. Quality is an inherent part of scope — it includes both functional and non‑functional requirements that meet stakeholder expectations. Effective scope management ensures all necessary work is included, unnecessary work is eliminated, and deliverables meet acceptance criteria.

Key Artifacts

• Business case — documents the economic feasibility, costs, benefits, and success criteria that justify the project.
• Project scope — the total work to deliver the product, service, or result with specified features and functions. It forms the core baseline for value.
• Scope baseline — the approved version of scope documentation (scope statement, WBS, WBS dictionary) used for comparison and change control in predictive environments. In adaptive projects, baselines are set per iteration and managed dynamically through the backlog.
• Work Breakdown Structure (WBS) — a hierarchical decomposition of the total scope into manageable work packages. In adaptive approaches, the product backlog serves a similar purpose.
• Value Breakdown Structure (VBS) — connects project scope to the value each deliverable is expected to generate, enabling prioritization and drag cost estimation.
• Product backlog — a prioritized, evolving list of features and work items used in adaptive environments to manage scope by value.
• Definition of Done (DoD) — a shared checklist of criteria that must be met before a deliverable is considered complete and ready for release.

Processes

The scope performance domain includes six processes that flow from planning through execution and closure:

• Plan Scope Management — creates the scope management plan, documenting how scope will be defined, validated, and controlled. The approach adapts to the project life cycle (predictive or adaptive).
• Elicit and Analyze Requirements — gathers and documents stakeholder needs. In adaptive projects, requirements are captured as user stories and prioritized in the backlog. Outputs include requirements documentation.
• Define Scope — develops a description of the project, product, and expected value. For predictive projects, this is done upfront and structured in the WBS. For adaptive projects, it is progressively refined per iteration. Also identifies quality requirements and standards.
• Develop Scope Structure — decomposes deliverables into smaller components. Predictive projects use a WBS (with a dictionary for complex items). Adaptive projects break down the product backlog into epics, features, and user stories.
• Monitor and Control Scope — tracks scope status, manages changes, and measures quality. Ensures deliverables meet quality standards and that scope remains aligned with the baseline. Outputs include verified deliverables, change requests, and quality reports.
• Validate Scope — formalizes acceptance of completed deliverables and checks that processes meet quality standards. Uses inspections, customer reviews, and decision‑making techniques. Outputs are accepted deliverables and lessons learned updates.

Tailoring Considerations

Scope processes should be adapted to the project’s context:

• External partners — align scope integration with contractual agreements and synchronize commitments across suppliers.
• Dynamic environments — use iterative feedback loops to adjust scope in response to market shifts or technology changes.
• Design‑heavy industries (e.g., pharma, construction) — invest heavily in early scope definition to avoid costly late changes.
• Hybrid life cycles — balance a fixed scope baseline with iterative backlogs. Subteams may work in sprints while overall baselines remain controlled.

Interactions with Other Domains

Scope directly affects and is affected by several performance domains:

• Governance — scope changes must navigate established approval processes; governance decisions determine the level of formality in scope control.
• Schedule and Finance — any scope change impacts time and cost baselines; trade‑offs must be evaluated.
• Risk — risk analysis can trigger rescoping to mitigate, avoid, or transfer threats. Conversely, scope changes may introduce new risks.
• Stakeholders — scope validation relies on stakeholder acceptance; early and ongoing engagement reduces rework.

Checking Outcomes

Use measurable indicators to confirm scope success:

• Change management effectiveness — predictive: change log with cross‑domain impact analysis. Adaptive: backlog shows velocity, new scope rate, and feedback integration.
• Requirements clarity — predictive: low change rate in initial requirements. Adaptive: each iteration yields clear short‑term requirements.
• Business alignment — business case and authorizing documents confirm deliverables match strategic objectives.
• Stakeholder satisfaction — interviews, feedback, and low complaint/return rates.
• Scope accuracy — (Planned Scope Items Correctly Delivered / Total Planned Scope Items) × 100
• Scope creep — (Total Deliverables / Unplanned Deliverables) × 100
• Requirements stability — (Total Requirements / Unchanged Requirements) × 100
• Sustainability — WBS or backlog includes activities for environmental impact (e.g., CO₂ management, biodiversity).