Work Breakdown Structure Creation

Name: Work Breakdown Structure Creation
Availability: InStock

Learn to create effective Work Breakdown Structures to define project scope, organize tasks, and improve project planning.

My workspace30 minFree to watch

What you’ll learn

01Creating a Work Breakdown Structure: Core Principles and PracticeWelcome to this session on creating a Work Breakdown Structure. If you have ever managed a project and felt unsure about whether you had captured all the work, this session will give you a practical, foundational tool. Today, our goal is straightforward: we will take a real project deliverable and systematically decompose it into clear, assignable work packages. Think of the W B S as a deliverable-oriented, hierarchical map of your total project scope. It focuses on “what” we produce—using nouns—not “how” we do it with verbs. This distinction is critical because it builds a reliable foundation for accurate estimation, clear assignment, and tight scope control. By the end, you will be ready to move from a high-level deliverable to a set of manageable components ready for your team to own. Let us begin by first clarifying what a W B S is—and just as importantly, what it is not.pmi.org pmi.org pmi.org+21 min
02What a WBS Is (and What It Is Not)Let's start by clarifying exactly what a Work Breakdown Structure is, and just as importantly, what it is not. The formal definition calls it a deliverable-oriented, hierarchical decomposition of the total project scope. Think of it as a map of outcomes—it shows 'what' we will produce, not 'how' we will produce it. In practice, this means your WBS contains deliverables, like a 'User Research Report', never activities like 'conduct user interviews'. To keep this distinction clear, use nouns for every element. This also means a WBS is not a task list, not a project schedule, and not an organizational chart. It is the foundation that those other tools are built upon. So, if you're ever unsure, ask yourself: 'Am I naming a thing we can hand off, or describing an action someone performs?' Let's take that deliverable focus a step further and see how it applies to the next slide, 'The 100% Rule and Deliverable-Driven Thinking'.pmi.org pmi.org pmi.org+22 min
03The 100% Rule and Deliverable-Driven ThinkingIn the last section, we saw how deliverables keep the WBS focused on what we produce rather than what we do. That idea is captured by something called the one hundred percent rule, and it is our first tool on this slide. The rule is simple. The WBS, as a whole, must capture the entire project scope, no more, no less. But it also applies at every level. Each child level must represent one hundred percent of its parent's scope. If a parent deliverable requires four components, all four must appear as children. This dual check prevents both gaps, where work is missing, and overlaps, where the same work gets counted twice. The next practical tool is starting from deliverables, using nouns, not verbs. When we define a finished report or a tested module, we have a clear, stable target. Verbs invite scope creep; a task like 'analyze requirements' can stretch indefinitely. A deliverable either exists or it does not. This slide also introduces a simple classification. Internal deliverables are outputs the team needs, like design specifications or test plans. External deliverables are what stakeholders receive, like the final product or a signed-off report. Both are part of the one hundred percent rule. Often, the team must also produce interim or enabling deliverables along the way, such as a prototype used only for testing. These intermediary outputs are real deliverables that require time and resources, so they must appear in the WBS as well. The key takeaway is this: the one hundred percent rule is your scope boundary, and every deliverable, whether internal, external, or interim, gets a home inside that boundary. Next, we will move from identifying these deliverables to the process of breaking them down in 'Decomposition: From High-Level Deliverable to Work Package'.pmi.org pmi.org pmi.org+22 min
04Decomposition: From High-Level Deliverable to Work PackageNow let's discuss how to break down major deliverables into actionable components using decomposition. Decomposition is a top-down technique that takes a high-level scope element and divides it into smaller, manageable deliverables. We continue this process until we reach the lowest level, the work package. A work package is where work becomes estimable, schedulable, and assignable to a single owner. To size work packages properly, apply the eight-eighty rule. This practical guideline suggests work packages should take no less than eight hours and no more than eighty hours of effort. Smaller packages create administrative overhead; larger ones hide too much risk and become hard to estimate. The reporting-period rule reinforces this by ensuring each work package fits within a single status interval, letting you report it as simply not started, in progress, or complete. Consider this example. An E-commerce Website high-level deliverable decomposes into a User Research Report. That report further decomposes into Interview Transcripts. Notice how each level becomes more specific and assignable. Up next, we'll apply these concepts to structuring a WBS for clarity and assignment.pmi.org resources.rework.com ganttgrind.com+22 min
05Structuring a WBS for Clarity and AssignmentNow, let's talk about the actual structure you'll put down on paper or in your tool. You have options—an outline, a tree diagram, or a tabular format. The key is to pick what makes the overall scope easiest to scan, not just what looks familiar. As you build this structure, describe each element with nouns. We say 'Approved Design Mockups,' not 'Designing the mockup.' This keeps focus on the output. And here's a vital sequencing point: build the structure first, then assign the people. Defining the work before naming the team prevents you from tailoring the scope to fit a specific person's skills. So, how do we make each of those noun-based boxes absolutely clear? That's where a W B S dictionary comes in. It provides precise scope definition for every single node, leaving no room for assumptions. That leads us directly to our next topic, 'The W B S Dictionary: Your Scope Contract.'1 min
06The WBS Dictionary: Your Scope ContractNow let's talk about the document that makes your work packages truly unambiguous: the WBS dictionary. Think of it as a scope contract for every single work package. If a work package is a box of work, the dictionary is the label that tells everyone exactly what's inside, what's outside, and who signs for it. Every dictionary entry needs a few mandatory fields. First, a unique code—this ties it directly to your WBS structure. Then a clear scope description, explicit exclusions, measurable acceptance criteria, and an owner. I want to pause on exclusions, because this field is your strongest tool to prevent scope disputes. It's where you say, 'Here's what we are specifically not doing.' For example, look at work package three-two-one, 'Licensed Landscape Architect Report.' The scope might say the report includes site analysis and planting recommendations. The exclusions make it crystal clear that this does not include soil testing or irrigation design. That clarity protects both the project and the person doing the work. Up next, we'll shift from documentation to collaboration and look at building a WBS as a team.2 min
07Building a WBS as a TeamLet's shift our focus to how the work breakdown structure actually comes together. A reliable WBS is almost never built by one person working alone. It requires cross-functional collaboration to surface different perspectives on the work. To run an effective decomposition session, you typically need three key roles. First, a facilitator who guides the process and keeps the team moving. Second, subject matter experts who understand the detailed activities required. And third, scope holders who own the deliverables and can clarify boundaries. For the session itself, use visual tools like whiteboards, sticky notes, or a digital board such as Miro. Making the breakdown visible helps the group spot gaps and overlaps quickly. One of the most valuable outcomes of this teamwork is surfacing disagreements early. When two experts have different assumptions about where one work package ends and another begins, negotiate that boundary right in the room. That way, you leave with clear, agreed scope boundaries that prevent rework later. Next, we will look at how this agreed structure flows into the schedule, cost estimates, and risk register.2 min
08From WBS to Schedule, Cost, and RiskLet's connect the work breakdown structure to the project controls that depend on it. Every work package you define feeds directly into the Define Activities process—that's how you build a realistic schedule. The real integration point is the control account. Think of it as the intersection of your W B S and your organizational breakdown structure. This is where scope, budget, and schedule come together under a single responsible manager. As your work package estimates roll up into the control account, you get the cost baseline needed for earned value measurement. And here's a planning advantage: granular deliverables expose granular risks. When you decompose scope into small, tangible work packages, you strengthen early risk identification. Up next, we'll walk through control accounts and work packages in practice, so you can apply this integration directly.web.aacei.org www2.lbl.gov source.aacei.org+21 min
09Control Accounts and Work Packages in PracticeNow let's see how control accounts and work packages function together in practice. A Control Account - often called a CA - sits at the intersection of your W B S and your organizational breakdown structure. It’s the single management point where you integrate scope, schedule, and budget for one responsible group. Inside each control account, you place near-term, detailed tasks as Work Packages. These are your basic building blocks: short-duration efforts measured in hours, dollars, or other concrete units, so you can track earned value objectively. For work that’s further out and less defined, you create Planning Packages. These hold time-phased budget and scope at a higher level, and you convert them to work packages later through rolling wave planning. The key financial rule is simple: the sum of all work packages and planning packages must equal the control account’s total approved budget. Budgets then roll up from work packages and planning packages to the control account, giving you a clear performance baseline. Up next, we’ll explore Common WBS Mistakes and How to Catch Them.web.aacei.org www2.lbl.gov source.aacei.org+22 min
10Common WBS Mistakes and How to Catch ThemNow that you know how to build a solid structure, let's look at some of the most common traps that can weaken a WBS. Being aware of these will help you check your own work. First, the classic mix-up: creating a task list full of verbs instead of a deliverable hierarchy built with nouns. If your WBS says 'design the report,' you're describing an activity. Instead, the deliverable is simply 'Report Design.' A good WBS focuses on the 'what,' not the 'how.' Second, watch the level of detail. Decomposing too much is gold-plating; you'll end up micromanaging tiny tasks. Decomposing too little leaves you with vague, unassignable work packages. Stop when the work package can be reliably estimated and handed to one person. A third frequent error is mixing phases, deliverables, and functions at the same WBS level. This breaks your hierarchy and creates confusion. Stick to a deliverable-oriented structure on every branch. And finally, one of the biggest mistakes is failing to update the WBS after changes are approved. If it doesn't reflect the current scope, the WBS loses its value for planning and control. Treat your WBS as a living document. Next, we'll put these lessons into practice with a validation checklist in 'WBS Quality Gates: Your Validation Checklist.'pmi.org pmi.org pmi.org+22 min
11WBS Quality Gates: Your Validation ChecklistNow that you've built your structure, it's time to validate it. A WBS is only as good as its ability to withstand scrutiny, so think of this slide as your quality gate checklist before you set a baseline. First, verify the two non-negotiable rules. Apply the one hundred percent rule to ensure every level captures all the work of its parent. Then, check for mutual exclusivity to make absolutely sure there is no overlap between work packages. If two elements are describing the same scope, you have a double counting problem that must be resolved immediately. Once those rules pass, do not skip the people review. A structured peer review catches gaps that you might miss, and formal stakeholder sign-off confirms that what you defined matches their expectations. Without that approval, your WBS is just a draft. Finally, treat your validated structure as a living document. You must implement strict version control and a change integration process. As scope evolves, your WBS evolves with it, but uncontrolled edits will destroy the integrity you just worked so hard to achieve. Let's put these quality checks into practice immediately. Our next slide is a hands-on exercise where you will apply the one hundred percent rule to a real-world scenario.pmi.org pmi.org pmi.org+22 min
12Hands-On: Decompose a Real-World ScenarioNow it's your turn to put decomposition into practice. We have a compact project scenario on the table, and your goal is to break down its high-level deliverables into clear, assignable work packages. Work together in small groups, take a top-level deliverable, and ask: what tangible, manageable components make this whole? Start brainstorming, then refine your list until each item is a single, assignable piece of work that can be estimated and tracked. Use a noun-based naming format and keep each work package sized between eight and eighty hours of effort. When you finish, we will compare outputs across teams. You will see how different perspectives can surface equally valid structures, and we will reinforce the standards for naming, sizing, and assignment that make a WBS truly actionable. Next, let's look at how the WBS functions in an Agile and hybrid world.1 min
13WBS in an Agile and Hybrid WorldNow let's bring the work breakdown structure into the agile and hybrid world. In these environments, the deliverable focus of the WBS continues to define what we are building. That is our scope baseline. The product backlog, on the other hand, sequences the when and the how through iterative delivery. Features in our scope decompose into epics and user stories, which naturally mirror traditional work packages. A key technique here is fractal decomposition. A single feature can have its own miniature WBS for each iteration, allowing the team to plan and manage scope precisely within a sprint. As requirements emerge and evolve, the WBS remains our stable scope baseline. It is the anchor that ensures every new story or feature maps back to an approved deliverable, preventing uncontrolled growth while embracing change. With this hybrid approach, we create a single source of truth for scope, no matter how the delivery cadence shifts. Next, we will tackle strategies for wrangling a WBS in large or complex projects.pmi.org pmi.org pmi.org+21 min
14Wrangling a WBS in Large or Complex ProjectsNow let's look at how the work breakdown structure operates in large or complex projects. The key mechanism is the control account. Think of a control account as the intersection between your W B S and your organizational breakdown structure. It’s the single point where scope, budget, and schedule are integrated, and where you assign responsibility to one person or group. From there, you can roll up actual costs and compare them to earned value. To maintain clear traceability from high-level contract deliverables all the way down to individual work packages, use a coding scheme. This lets you track every element as it decomposes through the hierarchy. One of the biggest strengths of this approach is scalability. On a small paver project, you might have just one control account for the entire design effort. On a mega-project, you could have hundreds. Finally, remember that the W B S integrates directly with your accounting and procurement systems, ensuring financial and contractual data align with the project scope. This consistency makes reporting and change management far more manageable. Up next, we’ll take all of this theory and bring it into the real world with 'Your First Day Back: Applying WBS Skills Immediately.'web.aacei.org www2.lbl.gov source.aacei.org+22 min
15Your First Day Back: Applying WBS Skills ImmediatelyHere we are at the final slide, and the real work starts when you walk back to your desk. Your first task is straightforward: pick a real, upcoming deliverable and build a mini W B S for it. Use the template and the compact quality checklist you now have. Don’t wait for permission. Pitch the approach to your sponsor by simply saying, “Let’s define what we’ll produce before we discuss how.” That one sentence shifts the conversation from activities to outcomes. As you build, return to the core principles we covered: focus on deliverables, use nouns, apply the one hundred percent rule at every level, and capture the details in a W B S dictionary. When you’re ready to go deeper, the P M I Practice Standard for Work Breakdown Structures is your next step. You now have a practical, proven method. Apply it on your first day back, and you’ll see the difference immediately. Thank you for joining me, and good luck on your next project.pmi.org pmi.org pmi.org+22 min

Sources consulted

Web sources consulted while building this course.