Define Scope in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Define Scope in PMBOK 8 — Complete Guide

Formerly known as: Define Scope (PMBOK 6)

In the spring of 2023, a mid-sized financial services firm embarked on a $2.1 million digital transformation project. The project manager had led dozens of projects and was widely respected. Yet nine months in, the project stalled — not because of technical failures or budget overruns, but because no one agreed on what the project was actually supposed to deliver. The development team had built one thing; the business stakeholders expected another. The quality assurance team was testing against a third set of criteria. Three different interpretations of the product had been quietly developing in parallel, burning resources and destroying confidence.

The root cause? The team had skipped a thorough Define Scope process. They had documented high-level requirements, yes — but they had never produced a precise, shared, formally approved description of what the project would and would not deliver. Without a project scope statement that all parties had reviewed and accepted, each group filled the gaps with their own assumptions. The cost of that omission was $680,000 in rework and a four-month delay.

The define scope PMBOK 8 process exists precisely to prevent this scenario. It is the process of developing a detailed or high-level description of the project, product, and the value expected to be delivered — along with the quality requirements that deliverables must meet. Whether you are managing a predictive waterfall initiative or an adaptive agile program, Define Scope is the moment when ambiguity ends and clarity begins.

• 1. What Is the Define Scope Process
• 2. Why Use the Define Scope Process
• 3. Inputs, Tools & Techniques, and Outputs (ITTO)
• 4. Step-by-Step Application Guide
• 5. When to Apply This Process
• 6. Real-World Examples
• 7. Templates and Downloads
• 8. Five Common Errors
• 9. Tailoring This Process
• 10. Process Interactions
• 11. Quick-Application Checklist

1. What Is the Define Scope Process

According to the PMBOK® Guide — Eighth Edition, the objective of the Define Scope process is to develop a detailed or high-level description of the project, product, and value expected to be delivered, as well as a quality management plan. This description may be produced at the beginning of the project for predictive approaches, or at the beginning of each iteration for adaptive and hybrid approaches.

In predictive (waterfall) projects, deliverables are structured in a Work Breakdown Structure (WBS). In adaptive (agile) projects, deliverables are progressively defined through a backlog, with user stories capturing individual requirements. PMBOK 8 explicitly recognizes both paths as valid and instructs practitioners to apply Define Scope in the manner appropriate to their development approach.

The process also identifies quality requirements and standards for the deliverables, and determines how the project will demonstrate that those quality requirements are met. This dual focus — scope definition and quality criteria — distinguishes PMBOK 8’s treatment from earlier editions.

The key benefit of this process, as stated in PMBOK 8, is that it helps ensure the stakeholders and project team understand the value that will be delivered through a product, service, or result.

PMBOK 6 vs. PMBOK 8: How Define Scope Changed

2. Why Use the Define Scope Process

The define scope PMBOK 8 process is one of the highest-leverage investments a project manager can make in the early stages of a project. Here is why skipping or shortcutting it causes disproportionate harm:

Scope creep is the silent project killer. When the boundaries of the project are not clearly documented and agreed upon, every small request becomes a negotiation with no clear reference point. Stakeholders add features, developers implement interpretations, and the project slowly balloons beyond its original intent. Research consistently shows that projects without a documented scope statement experience scope creep rates of 30–50% on average.

Ambiguity multiplies cost over time. A misunderstood requirement caught during Define Scope costs virtually nothing to fix — it is just a conversation and a revised document. The same misunderstanding caught during development costs 10× more to fix. Caught during testing, 100× more. Caught after delivery by the client, the cost is not just financial: it includes reputation damage and lost trust.

Quality failures originate in scope failures. PMBOK 8 wisely integrates quality standards into the Define Scope process. Without explicit acceptance criteria tied to each deliverable, “done” becomes subjective. Teams deliver what they think is done; clients reject what they expected to be different. The project scope statement created in this process, combined with quality criteria, creates an objective, shared standard for completion.

Team alignment drives velocity. A well-defined scope statement is not just a governance document — it is a navigation tool for the entire project team. When everyone understands exactly what is in scope and what is out, decisions become faster, misalignments surface sooner, and productivity increases.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO for the Define Scope process as documented in the PMBOK® Guide — Eighth Edition (Figure 2-16).

Inputs Explained

Project charter: The charter authorizes the project and provides a high-level description of the project, product, or service. During Define Scope, the charter serves as the baseline understanding of what the project is meant to achieve. Any definitions of project boundaries, key deliverables, or strategic objectives stated in the charter become starting points for the detailed scope statement.

Assumption log: Assumptions are facts accepted as true without proof. They have a significant impact on scope definition because scope boundaries often depend on assumptions about what is feasible, what the client will provide, or what technology is available. The assumption log makes these beliefs explicit so that scope decisions are made transparently.

Project management plan: At this stage, the scope management plan (if developed through Plan Scope Management) is particularly relevant, as it defines how scope will be defined, validated, and controlled throughout the project lifecycle.

Requirements documentation: The requirements documentation, produced in the Elicit and Analyze Requirements process, contains the documented stakeholder needs, constraints, and expectations. Define Scope selects which requirements fall within the project boundary and translates them into a formal scope statement.

Enterprise environmental factors (EEFs) and organizational process assets (OPAs): These include organizational standards, historical project data from similar projects, existing templates for scope statements, and regulatory requirements relevant to the industry.

Tools and Techniques Explained

Expert judgment: Senior project managers, subject matter experts, and domain specialists contribute insights about what scope boundaries are realistic, what risks arise from including or excluding specific features, and how quality standards have been applied in similar projects.

Decision-making: Multiple options may exist for how to define the project scope. Decision-making techniques — including multi-criteria decision analysis, voting, and group decision methods — help the team select the most appropriate scope boundaries.

Data analysis: Reviewing requirements documentation and constraint logs through structured analysis ensures that all stakeholder needs are accurately captured and that nothing critical is omitted from the scope statement.

Decomposition: Complex deliverables may be decomposed into sub-deliverables during scope definition to improve clarity, though the full WBS is created in the subsequent Develop Scope Structure (Create WBS) process.

Interpersonal and team skills — Facilitation: Effective facilitation of scope definition workshops ensures that stakeholder input is gathered systematically and that consensus is reached on what the project will and will not deliver.

Product analysis: For projects delivering a product, product analysis techniques — such as product breakdown, systems analysis, requirements analysis, and value engineering — help translate high-level product objectives into specific deliverable descriptions.

Outputs Explained

Project scope statement: The primary output, the project scope statement, provides a detailed description of the project and product scope, including: major deliverables, assumptions, constraints, exclusions from scope, acceptance criteria, and any specific quality requirements. It is the definitive reference document for what the project will and will not produce.

Requirements documentation updates: The process of formally defining scope may reveal gaps, contradictions, or missing details in the existing requirements documentation, necessitating updates.

4. Step-by-Step Application Guide

Applying the define scope PMBOK 8 process effectively requires following a structured sequence of activities. Here is a practical guide:

Step 1 — Assemble the right stakeholders. Define Scope is not a document-writing exercise performed in isolation. Convene a scope definition workshop that includes the project sponsor, key client representatives, subject matter experts, and lead team members. Diverse perspectives prevent blind spots and increase the accuracy of the scope statement.

Step 2 — Review and internalize the project charter. Before attempting to define scope in detail, ensure all participants have a shared understanding of the project charter. Pay particular attention to: the project objectives, high-level deliverables, key constraints, any preexisting assumptions, and the business case that justifies the project.

Step 3 — Review requirements documentation. Working from the requirements documentation produced during Elicit and Analyze Requirements, categorize requirements by: in-scope deliverables, out-of-scope items (explicitly excluded), and open items requiring further clarification.

Step 4 — Draft the project scope statement. Using the template appropriate to your organization, draft the project scope statement with the following components:

• Project and product description
• Acceptance criteria (per deliverable)
• Deliverables list (major outputs)
• Project exclusions (explicit out-of-scope items)
• Constraints (time, budget, resources, regulatory, technical)
• Assumptions
• Quality standards and measurement approach

Step 5 — Apply product analysis (if applicable). For product-oriented projects, conduct a thorough product analysis to ensure that the scope statement correctly translates business requirements into clear, measurable, testable product specifications.

Step 6 — Facilitate stakeholder review. Present the draft scope statement to all key stakeholders. Use structured facilitation techniques to gather feedback, resolve disagreements, and build consensus. Document all decisions and the rationale behind scope boundaries.

Step 7 — Obtain formal approval. The scope statement must be formally approved by the project sponsor and key stakeholders before it can serve as the scope baseline. In predictive projects, this approval gates the subsequent planning processes. In adaptive projects, scope definitions are approved per iteration.

Step 8 — Update the assumption log. Document any new assumptions surfaced during scope definition. These become inputs to risk management and subsequent planning processes.

Step 9 — Communicate to the project team. Ensure the entire project team has access to and understands the approved scope statement. Conduct a team review session to answer questions and address ambiguities before development begins.

5. When to Apply This Process

The timing and frequency of the Define Scope process depends on the development approach selected for the project.

Predictive (waterfall) projects: Define Scope is performed once, early in the planning phase, after requirements have been gathered and before the WBS is created. The scope statement, once approved, serves as the scope baseline for the entire project. Changes require formal change control through the Assess and Implement Changes process.

Adaptive (agile) projects: Define Scope is performed at the beginning of each iteration or sprint. At the iteration level, scope definition focuses on the user stories selected for the sprint backlog and the specific acceptance criteria for each story. The product backlog represents the overall project scope, which is progressively elaborated throughout the project.

Hybrid projects: In hybrid approaches, Define Scope is applied at multiple levels. A high-level predictive scope statement establishes the project boundaries, while iteration-level scope definition happens within agile workstreams. The challenge in hybrid projects is maintaining alignment between the predictive scope baseline and the adaptive backlog.

Phase-gated projects: In phase-gated projects, Define Scope is often repeated or refined at each phase gate. As more information becomes available and design decisions are made, the scope statement is progressively elaborated to increase precision.

6. Real-World Examples

Example 1: Project Phoenix — Website Launch

Alex Morgan, PMP, was managing Project Phoenix for TechCorp, a corporate website redesign with e-commerce integration. The project had a $72,250 budget and a 90-day timeline. CEO Sarah Chen had approved the project charter with high-level objectives but left scope details for the project team to define.

During the Define Scope workshop, Alex convened the marketing director, IT lead, e-commerce manager, and two customer experience specialists. Starting from the requirements documentation, they identified three major deliverable categories: (1) a redesigned public-facing website, (2) an integrated e-commerce module supporting up to 500 SKUs, and (3) a content management system allowing non-technical staff to update content.

Critical scope decisions were documented in the exclusions section: the project would not include mobile app development, third-party marketplace integration, or customer loyalty programs — all of which had been raised by stakeholders but were deferred to a future phase. These explicit exclusions prevented scope creep throughout the project.

Acceptance criteria were defined for each deliverable: the website must load within 2 seconds on broadband connections, the e-commerce checkout must support Visa, Mastercard, and PayPal, and the CMS must be operable without developer assistance. These criteria became the test plan foundation.

The approved project scope statement was distributed to all team members before development began. When the marketing director later requested a chatbot feature, Alex referenced the scope statement to demonstrate it was explicitly excluded and initiated a formal change request — which was ultimately approved as a separate micro-project. Scope was protected, and Project Phoenix was delivered on time and within budget.

Example 2: Project ProjectAdm — SaaS PM Platform

Eduardo was leading the development of a cloud-based project management SaaS platform for mid-market companies. The team of 8 developers, 2 designers, and 1 QA engineer was working on an 18-month product roadmap. The adaptive nature of the work required Define Scope to be applied at both the product level and the sprint level.

At the product level, the team produced a product scope statement describing the platform’s three core capability areas: project planning (Gantt charts, WBS builder, milestone tracking), team collaboration (task assignment, messaging, document sharing), and reporting (dashboard, earned value metrics, risk reports). This high-level scope was reviewed and approved by the product owner and the founding team.

At the sprint level, each sprint planning session began with a Define Scope activity: the product owner selected the highest-priority user stories from the backlog, and the team collaboratively defined the acceptance criteria for each story using the INVEST framework (Independent, Negotiable, Valuable, Estimable, Small, Testable). Each sprint scope statement was documented as a sprint goal with explicit done criteria.

This dual-level scope definition practice prevented two common agile pathologies: feature drift (the product scope drifted away from the strategic roadmap) and done ambiguity (stories were accepted without meeting quality criteria). Sprint velocity increased 22% in the third sprint cycle after the practice was formalized, because developers spent less time in “is this done?” discussions and more time building.

7. Templates and Downloads

To apply the Define Scope process effectively, you need the right documentation tools. The following templates are available for download:

• Project Scope Statement Template — Complete scope statement template with sections for deliverables, exclusions, constraints, assumptions, and acceptance criteria. Covers both predictive and adaptive formats.
• Scope Management Plan Template — Defines how scope will be developed, validated, and controlled throughout the project. Essential companion to the scope statement.
• Requirements Documentation Template — Structured template for capturing, categorizing, and tracing requirements from elicitation through scope definition.
• Scope Baseline Template — Combines the scope statement, WBS, and WBS dictionary into a complete scope baseline package ready for formal approval.

8. Five Common Errors

Error 1: Writing scope in vague, unmeasurable language. Scope statements that describe deliverables in terms like “improved user experience” or “faster system” are not definitions — they are aspirations. Every deliverable in the scope statement must be described with enough specificity to support testing and acceptance. “The homepage load time must not exceed 2 seconds on a 10 Mbps connection” is a scope definition. “The website must be fast” is not.

Error 2: Omitting the exclusions section. Most scope statements list what the project will deliver. Far fewer explicitly list what it will not deliver. This omission creates a dangerous vacuum: stakeholders assume that anything not explicitly excluded is included. The exclusions section is one of the most valuable parts of the scope statement. Every item that was discussed but deferred should appear here.

Error 3: Defining scope without the right stakeholders. Scope statements produced by the project manager alone, or by a small technical team, consistently miss business requirements and create misaligned expectations. Define Scope is a collaborative process. The people who will use, fund, and be affected by the deliverables must have voice in their definition.

Error 4: Treating Define Scope as a one-time event in adaptive projects. In agile and hybrid projects, scope at the product level evolves as learning accumulates. Teams that define scope once and then never revisit it end up delivering yesterday’s understanding of the product. Define Scope must be a recurring process — refreshed at each iteration boundary and whenever significant new information emerges.

Error 5: Failing to link scope to acceptance criteria. A scope statement without acceptance criteria is a wishlist, not a contract. Acceptance criteria define the observable, testable conditions that determine whether a deliverable is complete. Without them, scope definition is incomplete, and the risk of disputed deliverables at project close is high.

9. Tailoring This Process

PMBOK 8 explicitly acknowledges that the Define Scope process must be tailored to the unique characteristics of each project. Key tailoring considerations include:

Environmental dynamics: In highly dynamic environments — where markets, technologies, or customer preferences evolve rapidly — scope definitions must incorporate flexibility. Rather than a fixed scope statement, consider a scope framework that identifies immutable constraints (budget, timeline, regulatory requirements) while leaving room for iterative refinement of product features. This is the essence of adaptive scope management.

Design phase investment: In industries such as pharmaceutical and construction, where changes become exponentially more expensive as the project progresses, the Define Scope process deserves intensive investment early. Multiple rounds of scope definition, stakeholder workshops, mock-ups, and prototypes are justified if they prevent costly rework downstream. The cost of thorough upfront scope definition is almost always less than the cost of late-stage scope changes.

Adaptive and hybrid life cycles: In purely adaptive projects, the product scope statement is high-level and intentionally incomplete at the outset. Specificity is added iteration by iteration. In hybrid projects, the challenge is maintaining coherence between the predictive scope baseline for the overall project and the adaptive scope definitions for individual workstreams. A clear integration point (typically the sprint review / phase gate) must be defined where iteration-level scope decisions are reconciled with the project-level scope baseline.

External partnerships: When the project involves external vendors, subcontractors, or partner organizations, the scope statement must be precise enough to serve as the basis for contractual agreements. Vague scope definitions lead to scope disputes with third parties, which can result in claims, delays, and additional costs. In this context, the Define Scope process may require legal review and formal contract alignment.

10. Process Interactions

The Define Scope process does not exist in isolation. It is deeply connected to other processes and performance domains within PMBOK 8:

Interaction with Elicit and Analyze Requirements: Define Scope is directly downstream of requirements elicitation. The requirements documentation produced in the elicitation process serves as the primary input to Define Scope. The quality and completeness of requirements directly determines the quality of the scope statement. Poor requirements lead to poor scope definitions, which lead to poor deliverables.

Interaction with Initiate Project or Phase: The project charter produced during initiation provides the high-level project description that anchors the Define Scope process. The scope statement must be consistent with and traceable to the charter. Any scope definition that contradicts the charter must trigger a change request or charter update.

Interaction with Create WBS (Develop Scope Structure): The scope statement is the primary input to the Create WBS process. The WBS decomposes the deliverables described in the scope statement into manageable work packages. If the scope statement is vague, the WBS will be vague too, undermining scheduling and cost estimation.

Interaction with Integrate and Align Project Plans: The approved scope statement becomes the scope component of the project management plan. It must be aligned with the schedule baseline, cost baseline, and quality management plan to create a coherent, internally consistent project management plan.

Interaction with Validate Scope and Control Scope: Both the Validate Scope and Control Scope processes depend on the scope statement as their primary reference. Validation checks whether completed deliverables match the scope statement. Control monitors for unauthorized scope changes and measures scope creep relative to the approved scope baseline.

Interaction with Risk Management: Assumptions and constraints documented in the scope statement are inputs to the risk identification process. Risks often arise at scope boundaries — the places where what is in scope meets what is out of scope. Thorough scope definition reduces risk by eliminating ambiguity, but it also exposes risks by making constraints explicit.

11. Quick-Application Checklist

• ✅ Project charter reviewed and understood by all scope definition participants
• ✅ Requirements documentation reviewed and categorized (in-scope / out-of-scope / TBD)
• ✅ Scope definition workshop conducted with appropriate stakeholders
• ✅ Project scope statement drafted with: description, deliverables, exclusions, constraints, assumptions, acceptance criteria, quality standards
• ✅ Each deliverable has measurable, testable acceptance criteria
• ✅ Out-of-scope items explicitly documented in the exclusions section
• ✅ Assumption log updated with new assumptions discovered during scope definition
• ✅ Scope statement reviewed and approved by project sponsor and key stakeholders
• ✅ Scope statement communicated to entire project team
• ✅ For adaptive projects: sprint-level scope definitions include INVEST-compliant user stories with acceptance criteria
• ✅ Scope baseline established and version-controlled
• ✅ Change control process defined for managing scope changes

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.