Develop Scope Structure in PMBOK 8 — Complete Guide

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

Develop Scope Structure in PMBOK 8 — Complete Guide

Formerly known as: Create WBS (PMBOK 6)

Two construction project managers were given the same scope statement for a mixed-use building development. The first manager produced a project schedule directly from the scope statement, assigning activities based on trade disciplines. Three months into construction, the project was in chaos: no one knew which deliverables were complete, cost tracking was impossible because activities crossed multiple budget codes, and the general contractor could not tell the client which percentage of the project was finished. The second manager spent four days producing a detailed scope structure — a hierarchical decomposition of every deliverable into work packages with clear ownership, measurement criteria, and cost tracking codes. The project delivered on schedule, on budget, and with a complete audit trail that the client used to release progress payments without dispute.

The WBS — now renamed Develop Scope Structure in PMBOK 8 — is not administrative overhead. It is the structural foundation from which schedules are built, costs are tracked, resources are allocated, and progress is measured. A project without a scope structure is a project without a skeleton: it may stand briefly, but it will not bear weight under pressure.

This guide covers everything you need to master this process:

• What it is — definition, PMBOK 8 position, and what changed from PMBOK 6
• Why use it — direct benefits and the cost of skipping it
• Full ITTO — from the official PMBOK 8 PDF
• Step-by-step application guide
• When to apply it
• Two real-world examples — Project Phoenix and Project ProjectAdm
• Templates and downloads
• Five common errors
• Tailoring — predictive, agile, and hybrid
• Process interactions
• Quick-application checklist

1. What Is Develop Scope Structure

Develop Scope Structure is the process of subdividing project deliverables and project work into smaller, more manageable components. It is Process 4 of the Scope Performance Domain in PMBOK 8, positioned in the Planning focus area (after Define Scope). Its key benefit is that it provides a strategic view of the project’s scope and value, and helps the project team remain aligned and working toward a common goal.

In predictive projects, the primary output is the Work Breakdown Structure (WBS) — a hierarchical decomposition of the total scope of work into smaller, manageable work packages that can be assigned, tracked, and measured. The WBS, together with the project scope statement and the WBS dictionary, constitutes the scope baseline in predictive approaches.

In agile projects, this process corresponds to the decomposition of the product backlog — breaking down epics into features and user stories. The product backlog serves the same structural function as the WBS in adaptive environments: it defines all the work the team will perform, decomposed to a level that enables estimation, scheduling, and tracking.

What changed from PMBOK 6 to PMBOK 8

The most significant conceptual evolution is the explicit value orientation. PMBOK 8’s renaming to “Develop Scope Structure” signals that the process is not just about decomposing work — it is about creating a structure that reflects the value hierarchy of the project’s deliverables, enabling value-based prioritization and informed trade-off decisions.

2. Why Use Develop Scope Structure

Direct benefits

• Foundation for scheduling and cost estimation: The WBS is the structural input for activity definition (Schedule Domain) and work package cost estimation (Finance Domain). Without decomposed work packages, activity lists are built from incomplete scope and cost estimates float without anchor points.
• Clear ownership and accountability: Each WBS work package can be assigned to a specific team member or work package owner. This accountability structure is not possible without decomposition — when work is at the deliverable level, ownership is diffuse.
• Scope baseline for performance measurement: In predictive projects, the scope baseline (scope statement + WBS + WBS dictionary) is the reference against which actual deliverable completion is measured. Without a WBS, there is no objective basis for measuring scope progress.
• Prevention of gold-plating: Gold-plating — adding features or quality beyond what was specified — is only detectable against a documented scope structure. When the team has a WBS that defines exactly what is to be delivered, any work outside the WBS is visible as unplanned scope.
• Shared understanding across the team: The WBS development process is itself a team alignment activity. When the team builds the WBS together, they develop a shared mental model of all the work required. This shared understanding prevents the “I thought someone else was doing that” failures that derail projects in execution.

The cost of skipping scope structure development

• Undetectable scope gaps: Without a complete decomposition, scope gaps are invisible until the deliverable stage reveals missing components. A scope gap discovered during system integration testing typically requires 3–5x more effort to address than the same gap discovered during scope structure development.
• Inaccurate schedules and budgets: Activity lists and cost estimates built without WBS anchor points are structurally incomplete. Key work packages are missing from the estimate, producing optimistic baselines that fail under execution pressure.
• Inability to measure progress: “We are 60% done” is meaningless without a defined structure of what 100% completion means. WBS-based progress measurement provides an objective, auditable basis for status reporting.

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

The following table presents the complete ITTO of Develop Scope Structure as defined in PMBOK 8 (Figure 2-17, p.148):

Inputs explained

Project scope statement: The scope statement defines the total scope of work that must be decomposed. Every element described in the scope statement must be traceable to at least one WBS element. Conversely, every WBS element must trace back to the scope statement. A WBS that contains elements not in the scope statement represents unauthorized scope.

Requirements documentation: Requirements define the acceptance criteria for deliverables and the functional capabilities the deliverables must provide. The WBS decomposes deliverables; requirements define what those deliverables must do. Together, they constitute the complete specification of what must be built and verified.

Approved changes: Any approved scope changes must be reflected in an updated scope structure. The WBS is a living document throughout the project — approved scope changes trigger WBS updates through the change control process defined in the scope management plan.

Tools & Techniques explained

Decomposition: The core technique of WBS development. Decomposition breaks deliverables progressively into smaller components until each component meets the work package criteria: can be assigned to a single work package owner; can be estimated with sufficient accuracy; can be tracked and measured independently; and represents a meaningful, verifiable unit of work. The 8/80 rule provides a practical guideline: work packages should represent between 8 and 80 hours of effort. Below 8 hours, the management overhead exceeds the tracking value. Above 80 hours, the work package is too large to estimate or track accurately.

Expert judgment: Subject-matter experts contribute knowledge of what the work actually involves at the task level, which is essential for decomposition accuracy. A WBS created without SME input will have structural gaps in areas the project manager does not understand intimately. SME involvement in WBS development also creates ownership: when team members help build the WBS, they understand and accept the structure they are being asked to execute.

Brainstorming: Group brainstorming sessions for WBS development ensure that all work components are identified, including work that individual team members would not have considered in isolation. Facilitated WBS brainstorming sessions with the core team are highly effective for complex projects where no single person has visibility into all required work components.

Outputs explained

Work Breakdown Structure (WBS): A hierarchical decomposition of the total scope of work, organized in levels. Level 1 is the project. Level 2 contains major deliverables or project phases. Level 3 contains sub-deliverables. The lowest level of each branch is a work package — the unit of work that is assigned, estimated, and tracked. The 100% rule governs WBS quality: the WBS must include 100% of the scope defined in the scope statement, and the sum of the WBS elements at any level must equal 100% of the level above.

WBS dictionary: A document providing additional detail for each WBS element: description of work, acceptance criteria, responsible party, resource requirements, estimated cost, and milestone dates. The WBS dictionary transforms the visual hierarchy of the WBS into an operational work specification. For complex projects or work packages being executed by external contractors, the WBS dictionary is the contractual specification of what is to be delivered.

Scope baseline: The approved version of the scope statement, WBS, and WBS dictionary. The scope baseline is the formal reference against which all scope performance is measured. Changes to the scope baseline require formal change control.

User stories and product backlog (adaptive): In agile projects, the equivalent outputs are the product backlog (the prioritized list of all work items) and user stories (the individual backlog items decomposed to a level appropriate for sprint execution). The product backlog is structured hierarchically: epics at the top level are decomposed into features, which are decomposed into user stories. This hierarchical structure is the agile equivalent of the WBS.

4. How to Apply the Process Step by Step

Step 1 — Start from the scope statement and requirements documentation

The WBS development session must begin with the project scope statement and requirements documentation visible to all participants. Every Level 2 WBS element (major deliverable) should have a direct correspondence to the scope statement. Read the scope statement aloud at the start of the session and ask the team: “What are the major deliverables this project must produce?” The answers become the Level 2 elements.

Step 2 — Identify Level 2 elements (major deliverables or phases)

Define the highest decomposition level below the project name. For deliverable-oriented WBS structures (recommended), Level 2 elements are the major deliverables the project produces. For phase-oriented WBS structures (sometimes used for large multi-phase projects), Level 2 elements are the project phases. Deliverable-oriented WBS structures are generally preferred because they maintain direct traceability to scope and facilitate earned value measurement.

Step 3 — Decompose each Level 2 element until work packages are reached

For each major deliverable, continue decomposing into sub-deliverables and components until every branch terminates in a work package meeting the work package criteria. Use the 8/80 rule as a practical guideline. Involve the team members who will execute each area of work in the decomposition of that area — they know the actual work components better than anyone else.

Step 4 — Apply the 100% rule and validate completeness

After the initial decomposition, verify the 100% rule at each level: the sum of all child elements must equal the full scope of the parent element — no more, no less. Walk through the scope statement line by line and confirm that every scope element maps to at least one WBS work package. Identify and resolve any gaps before proceeding to WBS dictionary development.

Step 5 — Develop the WBS dictionary for each work package

For each work package, document in the WBS dictionary: the work package ID and name; a description of the work; the responsible party or work package owner; the acceptance criteria; the estimated effort and cost; the expected duration; any dependencies with other work packages; and the quality standards that apply. The WBS dictionary is particularly important for work packages assigned to external vendors or contractors.

Step 6 — Obtain approval for the scope baseline

Present the completed WBS and WBS dictionary to the sponsor and key stakeholders for review and formal approval. The approved WBS, together with the scope statement and WBS dictionary, constitutes the scope baseline. Record the approval date and version in the project management information system.

5. When to Apply Develop Scope Structure

• After Define Scope: The scope statement is the primary input for WBS development. WBS development without a defined scope statement will produce an incomplete structure.
• Before scheduling and cost estimation: The WBS is the structural input for the Schedule Domain’s Develop Schedule process and the Finance Domain’s Estimate Costs process. Always complete the WBS before building the schedule or cost estimate.
• After any approved scope change: Scope changes that affect deliverables require WBS updates. The updated WBS is the revised scope baseline.
• At the start of each phase (rolling wave): In multi-phase projects using rolling wave planning, the WBS may be developed at a high level initially with detailed decomposition of near-term work packages deferred to the appropriate phase planning activities.

6. Two Real-World Examples

Project Phoenix — TechCorp Website Relaunch

After the scope statement was approved, Alex Morgan facilitated a two-day WBS development session with the TechCorp project team, the external design agency, and the IT infrastructure lead. She structured the session around the 5 Level 2 deliverables identified in the scope statement: Design System, Content Architecture, Frontend Development, Backend Integration, and Launch & Transition.

The decomposition of “Backend Integration” revealed a significant scope gap: the requirements documentation referenced a CRM integration, but the scope statement had not explicitly included it. The IT director confirmed the integration was required for the loyalty program (which was in scope). This gap, identified during WBS development, was addressed through a scope statement update before any development work began — preventing what would have been a significant rework event six weeks later.

The final WBS contained 4 levels, 47 work packages, and a WBS dictionary with estimated effort, owner assignment, and acceptance criteria for each package. The scope baseline (scope statement + WBS + WBS dictionary) was approved by Sarah Chen on day 14 of the project. All subsequent change requests were evaluated against this baseline, making impact assessment faster and more accurate.

Project ProjectAdm — SaaS Project Management Platform

Eduardo used a three-level backlog structure as the scope structure for ProjectAdm: Epics (major product areas), Features (capabilities within each epic), and User Stories (individual deliverable increments). The initial product roadmap contained 8 epics. The story mapping workshop Eduardo facilitated produced 143 user stories across those 8 epics.

The scope structure served a dual purpose: it provided the product owner with a complete picture of all committed product scope, and it provided the development team with a decomposed backlog ready for sprint planning. The scope structure was presented to the engineering team lead and investor board at the quarterly planning session, where it was used to validate that the committed product scope was feasible within the funding runway. Three features were deferred from the initial scope structure based on this analysis — a decision that would have been impossible without a complete, decomposed scope structure visible to all decision-makers.

7. Templates & Downloads

• Work Breakdown Structure Template: Download — WBS template for software development projects with pre-populated Level 2 elements.
• Scope Baseline Template: Download — includes scope statement, WBS structure, and WBS dictionary format.
• Scope Management Plan Template: Download — defines the governance process for scope baseline management.

8. Five Common Errors

Error 1 — Including activities in the WBS instead of deliverables

A WBS decomposes deliverables (nouns), not activities (verbs). “Mobile Interface” is a WBS element. “Develop Mobile Interface” is an activity. Including activities in the WBS creates an activity list masquerading as a WBS, losing the deliverable traceability that makes the WBS valuable. The activity list is produced during schedule development, not WBS development.

Error 2 — Violating the 100% rule

WBS elements that include work outside the scope statement introduce unauthorized scope. WBS structures that exclude scope statement elements create delivery gaps. The 100% rule is the quality standard for WBS development — validate it explicitly before approving the scope baseline.

Error 3 — Not developing the WBS dictionary

The WBS diagram without the WBS dictionary is a visual representation, not an operational specification. Work packages without dictionary entries have no documented acceptance criteria, no assigned owners, and no reference cost or duration estimates. The WBS dictionary transforms the WBS from a communication tool into a management instrument.

Error 4 — Decomposing to an inappropriate level

Over-decomposition (work packages of 2–3 hours) creates management overhead that exceeds tracking value. Under-decomposition (work packages of 200+ hours) creates estimates that are too imprecise for reliable planning. The 8/80 rule provides a practical calibration. Apply judgment: the appropriate decomposition level is the level at which the work can be accurately estimated, meaningfully assigned, and objectively measured.

Error 5 — Building the WBS without the team

A WBS built by the project manager alone will be incomplete in areas the PM does not understand intimately and will lack the team ownership that drives commitment to the structure. WBS development is a team activity. The people who will execute the work packages must participate in defining them — both for quality and for ownership.

9. Tailoring Considerations

10. Process Interactions

Inputs from: Define Scope (project scope statement); Elicit and Analyze Requirements (requirements documentation); Initiate Project or Phase (project charter); approved changes from change control processes.

Feeds into: Schedule Domain’s Develop Schedule (WBS work packages become the basis for activity definition); Finance Domain’s Estimate Costs and Develop Budget (WBS work packages are the units of cost estimation); Monitor and Control Scope (scope baseline from this process is the reference for scope performance measurement).

Interactions with other domains: The Finance Domain (cost baseline is built from WBS work package estimates); Schedule Domain (activity list is derived from WBS work packages); Risk Domain (WBS elements are analyzed for risk identification — each WBS element is a potential risk source); Resources Domain (resource requirements are assigned at the WBS work package level).

11. Quick-Application Checklist

• Scope statement reviewed and all major deliverables identified?
• WBS development session facilitated with the core team?
• WBS structured around deliverables (nouns), not activities (verbs)?
• 100% rule verified at every level?
• All scope statement elements traceable to WBS work packages?
• Work packages meeting the 8/80 hour guideline?
• WBS dictionary developed for every work package?
• Acceptance criteria documented for each work package in the dictionary?
• Scope baseline (scope statement + WBS + WBS dictionary) formally approved?
• Scope baseline stored in project management information system?

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.