1) Deliverable-based decomposition and the “100% rule” (practical meaning)
A Work Breakdown Structure (WBS) is a deliverable-oriented breakdown of the project’s total scope into smaller components until you reach work packages that can be estimated, assigned, and tracked. The key idea: you break down what you will deliver, not a to-do list of activities.
Deliverable-based decomposition
Start with the final outcome and split it into major deliverables (things a customer/user can recognize), then split each deliverable into smaller deliverables, and so on. Activities (like “meetings” or “coding”) can appear in the WBS only when they are necessary to produce a deliverable and are framed as a deliverable outcome (for example, “Approved design review package” rather than “Hold design meeting”).
The 100% rule in practical terms
The 100% rule means: the WBS includes 100% of the work required to deliver the project outputs, and only that work. Practically, it helps you avoid two common failures:
- Missing scope: a deliverable is assumed but not represented anywhere in the WBS (e.g., training materials are needed but not planned).
- Double counting: the same work appears in two places (e.g., “User guide” included under both “Product” and “Launch”).
Apply the 100% rule at every level: the children of a WBS element should add up to the full scope of that parent element. If something is not in the WBS, it is not planned; if it is in the WBS twice, it will be planned twice.
2) Step-by-step method to create a WBS
Step 1: Define the Level 1 (the project) and Level 2 (top deliverables)
Write the project name as Level 1. Then list 4–8 major deliverables as Level 2. A practical way to find Level 2 deliverables is to ask: “What would I hand over at the end, and what major components must exist for that handover to be real?”
- Listen to the audio with the screen off.
- Earn a certificate upon completion.
- Over 5000 courses for you to explore!
Download the app
Examples of Level 2 deliverables (depending on project type):
- Product or service component(s)
- Documentation and training
- Deployment / rollout package
- Operations handover
- Project management deliverables (plans, reports) if they are required outputs
Step 2: Decompose each deliverable into smaller deliverables
For each Level 2 deliverable, break it down into sub-deliverables that are still nouns (or noun phrases) and represent outputs. Keep decomposing until you reach work packages.
Helpful prompts:
- What parts make up this deliverable?
- What must be produced, reviewed, tested, or approved for this deliverable to be accepted?
- What artifacts must exist (files, configurations, signed approvals, installed components)?
Step 3: Stop decomposing when the work is estimable and assignable
A work package is the lowest level you plan and track. Stop decomposing when you can answer these questions for the element:
- Can one owner be accountable? (even if multiple people contribute)
- Can we estimate effort/cost and duration?
- Is the output clear and reviewable?
- Are completion criteria objective?
Rule of thumb: if a work package is so large that you cannot confidently estimate it, or so vague that you cannot define “done,” decompose further.
Step 4: Assign WBS codes and keep the structure mutually exclusive
Use hierarchical numbering (e.g., 1.0, 1.1, 1.1.1). Ensure each work package belongs in exactly one place. If something seems to fit in two places, clarify boundaries by redefining deliverables or moving shared items into a single “shared component” deliverable.
Step 5: Validate against the 100% rule and refine
Review the WBS with a completeness checklist (provided later) and adjust. Validation is not a one-time step; it typically takes 2–3 passes to remove overlaps and fill gaps.
3) Define work package naming, outputs, and completion criteria
Naming conventions (make the WBS readable)
Use consistent, deliverable-focused names. Good names are specific and measurable.
- Prefer: “Configured payment gateway integration”
- Avoid: “Payment work” or “Integrate payments”
- Prefer: “Approved content calendar”
- Avoid: “Marketing planning”
Practical naming pattern: [Adjective/State] + [Deliverable Noun] (e.g., “Signed vendor contract,” “Tested onboarding flow,” “Published FAQ page”).
Define outputs (what exists when done)
For each work package, specify tangible outputs such as:
- Document (spec, guide, checklist)
- Configured system component
- Test report and pass results
- Published page or deployed feature
- Signed approval
Completion criteria (objective “done” conditions)
Completion criteria should be verifiable. Use conditions like:
- Reviewed and approved by a named role
- Meets defined acceptance checks (e.g., “All test cases pass”)
- Deployed to a specified environment
- Stored in a specified repository/location
Example:
- Work package: “Approved onboarding email templates”
- Output: 5 email templates in the marketing tool
- Completion criteria: Templates created, links validated, and approval recorded in the review log by Marketing Lead
4) WBS dictionary entries for major work packages
A WBS dictionary is the companion document that removes ambiguity. You do not need a long document for every tiny item; focus on major work packages and anything that could be misunderstood.
Recommended fields (simple but effective)
| Field | What to capture |
|---|---|
| WBS ID | Code (e.g., 1.2.3) |
| Name | Deliverable-focused label |
| Description | What is included and what is explicitly excluded |
| Owner | Accountable person/role |
| Inputs | What this work package needs to start (documents, decisions, assets) |
| Outputs | What it produces (artifacts, configurations, approvals) |
| Completion criteria | Objective checks for “done” |
| Dependencies | Upstream/downstream work packages (optional but useful) |
Practice: Build a WBS for a sample project and validate it
Sample project
Project: Launch a simple marketing website for a local bakery (5 pages) with a contact form and basic analytics.
Assumptions for this exercise: You will deliver a live website on a chosen domain, with content provided/approved, and a working contact form that sends emails to the bakery inbox.
A simple deliverable-based WBS
1.0 Bakery Website Launch Project 1.1 Website Content Package 1.1.1 Approved site map and page list 1.1.2 Approved copy for 5 pages 1.1.3 Approved images and brand assets 1.2 Website Design Package 1.2.1 Approved wireframes (5 pages) 1.2.2 Approved visual design (style guide + page designs) 1.3 Website Build Package 1.3.1 Implemented page templates (5 pages) 1.3.2 Configured navigation and footer 1.3.3 Implemented contact form (validation + email routing) 1.3.4 Configured SEO basics (titles, meta, sitemap) 1.3.5 Configured analytics tracking 1.4 Quality and Launch Package 1.4.1 Completed functional test checklist 1.4.2 Completed content proofing and fixes 1.4.3 Configured hosting and domain (SSL enabled) 1.4.4 Production deployment completed 1.5 Handover Package 1.5.1 Admin access and credentials delivered 1.5.2 Maintenance notes and update instructions deliveredNotice how each element is an output. Even “Completed functional test checklist” is framed as a deliverable (the completed checklist and results), not just “test.”
WBS dictionary entries (major work packages)
Below are dictionary entries for the Level 2 deliverables (major work packages) to clarify boundaries and acceptance.
WBS Dictionary: 1.1 Website Content Package
| Field | Entry |
|---|---|
| WBS ID | 1.1 |
| Name | Website Content Package |
| Description | All written and visual content required for the 5-page site. Includes site map, page copy, and approved images/brand assets. Excludes new photography sessions and logo redesign. |
| Owner | Content Lead |
| Inputs | Bakery product/service details, existing logo/brand files (if any), stakeholder approvals |
| Outputs | Approved site map; final copy for each page; approved images in web-ready format |
| Completion criteria | Approvals recorded for site map, copy, and images; assets stored in agreed shared folder |
| Dependencies | Feeds 1.2 and 1.3 |
WBS Dictionary: 1.2 Website Design Package
| Field | Entry |
|---|---|
| WBS ID | 1.2 |
| Name | Website Design Package |
| Description | UX and visual design artifacts needed to build the site. Includes wireframes and visual designs/style guide. Excludes custom illustration work beyond basic layout and styling. |
| Owner | Designer |
| Inputs | Approved site map and content direction (from 1.1), brand assets |
| Outputs | Approved wireframes; approved visual design files; style guide (colors, typography, components) |
| Completion criteria | Design approval captured; design files versioned and shared; components defined for build |
| Dependencies | Requires 1.1.1; feeds 1.3 |
WBS Dictionary: 1.3 Website Build Package
| Field | Entry |
|---|---|
| WBS ID | 1.3 |
| Name | Website Build Package |
| Description | Implementation of the website in the chosen platform/stack. Includes page templates, navigation/footer, contact form, SEO basics, and analytics configuration. Excludes ongoing content updates after launch. |
| Owner | Developer |
| Inputs | Approved designs (1.2), content assets (1.1), hosting/platform access |
| Outputs | Working site in staging; configured contact form; SEO settings; analytics tracking active |
| Completion criteria | All 5 pages render correctly in staging; contact form sends to correct inbox; analytics events/pageviews visible; SEO basics present |
| Dependencies | Requires 1.1 and 1.2; feeds 1.4 |
WBS Dictionary: 1.4 Quality and Launch Package
| Field | Entry |
|---|---|
| WBS ID | 1.4 |
| Name | Quality and Launch Package |
| Description | Verification and release activities packaged as deliverables: test evidence, proofing fixes, hosting/domain setup, and production deployment. Excludes post-launch marketing campaigns. |
| Owner | Release Lead |
| Inputs | Staging build (1.3), domain registrar access, hosting credentials |
| Outputs | Completed test checklist; proofing log resolved; SSL-enabled domain pointing to hosting; production deployment record |
| Completion criteria | Test checklist completed with pass results; critical issues resolved; site accessible via final domain with SSL; deployment timestamp recorded |
| Dependencies | Requires 1.3; precedes 1.5 |
WBS Dictionary: 1.5 Handover Package
| Field | Entry |
|---|---|
| WBS ID | 1.5 |
| Name | Handover Package |
| Description | Materials and access needed for the bakery to operate the website. Includes credentials delivery and basic maintenance notes. Excludes ongoing support services. |
| Owner | Project Lead |
| Inputs | Production site (1.4), list of admin users, platform documentation links |
| Outputs | Admin access granted; credentials delivered securely; maintenance notes (how to update hours/menu, how to view form submissions, how to view analytics) |
| Completion criteria | Client confirms access works; maintenance notes delivered and stored; handover checklist signed off |
| Dependencies | Requires 1.4 |
Completeness validation checklist (use this to test your WBS)
100% rule and coverage
- Every promised deliverable is represented somewhere in the WBS.
- Each parent element is fully covered by its children (no “hidden work” assumed).
- Project management deliverables are included only if they are required outputs (e.g., “Approved launch checklist”).
No duplication
- No work package appears to produce the same output as another work package.
- Shared items (e.g., images, approvals) have a single home and are referenced as inputs elsewhere.
Clear boundaries
- Each work package has a clear output and completion criteria.
- Each work package has one accountable owner.
- Inclusions/exclusions are stated for major work packages (especially where misunderstandings are likely).
Right level of detail
- Work packages are small enough to estimate and assign.
- Work packages are not so small that tracking becomes overhead (avoid breaking into hour-by-hour items unless necessary).
Quick validation exercise (apply to the sample WBS)
- No missing deliverables: Is “contact form” explicitly included? Yes (1.3.3). Is “domain + SSL” included? Yes (1.4.3). Is “analytics” included? Yes (1.3.5).
- No duplicated work: Are “SEO basics” and “analytics” only in one place? Yes (both in 1.3). Proofing is in 1.4, not repeated under content.
- Clear boundaries: Is new photography included? Explicitly excluded in 1.1. Is post-launch marketing included? Excluded in 1.4.
