How to Build a WBS: A Deliverable-Based Example and Effort Totals Without Double Counting

A work breakdown structure, or WBS, organizes approved scope into deliverables and manageable work packages. Its purpose is not to produce the longest possible task list. It should make missing work, overlapping estimates, ownership, and completion conditions visible. This fictional landing-page example connects decomposition, accountability, evidence, and effort totals.

Use the WBS for scope, the Gantt chart for timing, and milestones for gates

The WBS answers what must be completed. A schedule or Gantt chart answers when and in what order work proceeds. A milestone defines a decision or acceptance gate. They can share identifiers, but a deliverable hierarchy alone does not establish dates or launch readiness.

“Implemented page” is a deliverable; “launch on October 20” is a timing condition; “authorize launch” is a gate. Preserve those distinctions. Review approved scope before assigning people or dates. Work omitted from a WBS does not automatically disappear from an existing agreement. Establish whether it was overlooked or is a genuinely new request.

Check the approved scope for omissions and overlaps

PMI’s discussion of work breakdown structures describes a deliverable-oriented hierarchy covering project scope, including management work. The 100% concept concerns coverage of approved scope, not a success probability or a current completion percentage.

A parent’s scope should reconcile with its children. Including the same copywriting under both content and design creates overlap; assigning review to neither creates a gap. Check backward from the required deliverables rather than merely combining departmental task lists.

Account for management, meetings, quality checks, rights checks, migration, and handover where required. Each need not be a separate row if its containing package is explicit. Record exclusions and references. If an exclusion contradicts the approved baseline, resolve it with stakeholders rather than silently deleting a row. Distinguish overlooked work, refinement, and a new requirement when assessing cost and date effects.

A filled deliverable tree and work package dictionary

Here, parent 1 is “a landing page ready for launch and operation.” The five rows are fictional leaf-level work packages. Hours are illustrative estimates, not market benchmarks. Required reviews are included within the stated packages; actual projects must add any other approved work.

The parent is a summary. It may display its children’s 48-hour total, but must not be added to those children again. Final launch authorization remains a separate gate reviewing tests and open issues. Completing packages does not itself grant launch authority.

A package dictionary expands the row with its identifier, deliverable, included and excluded work, assumptions, acceptance conditions, and owner. Define which forms and environments belong to the implemented page. The explanation should let one person start the work and another verify its completion.

Set package size using accountability and completion evidence

Choose package size using observable outputs, an accountable contact, estimability, and completion evidence. A universal number of levels or an inflexible “8–80 hours” rule can force unrelated work together or hide uncertainty.

The accountable owner coordinates acceptance and decisions; that person need not perform every activity. Writing, specialist review, and approval may involve different people. Describe the handoffs rather than leaving ownership blank because work is collaborative.

Split a package when outputs, owners, assumptions, or completion conditions differ. Keep small related operations within the dictionary when they share one owner and evidence. Before changing status to Done, check the agreed evidence. Using the budgeted hours, submitting work, and having it accepted are different events. Define how rejection and retesting affect status, retaining the previous version and reason.

Sum leaf-level effort and calculate a defined completion measure

Place the work-package table above in columns A:G, with planned hours in F and status in G. Leaf rows are 2–6. Enter hours as numbers and use Done consistently. The total is assumed nonzero. Keep the parent summary outside this range.

Total planned effort = 8 + 12 + 20 + 4 + 4 = 48 hours. Completed packages represent 8 + 12 = 20 planned hours. Effort-weighted completion = 20/48 = 41.7%; item-count completion = 2/5 = 40.0%. Different denominators produce different measures, so do not label both simply “progress.”

For range totals, see Microsoft’s SUM documentation.

For conditional totals, see Microsoft’s SUMIFS documentation. Match the row dimensions and status text.

The 41.7% figure weights accepted completion by planned effort. It is not elapsed time, budget consumption, actual remaining effort, or a completion-date forecast. Unfinished packages may already contain completed activity, and their remaining estimates can change.

Hand off to scheduling and control scope changes

For scheduling, expand packages into executable activities and check dependencies, allocation, waiting, working calendars, and reviews. Predecessor IDs alone cannot calculate a critical path without durations and the necessary scheduling assumptions.

When scope changes, update affected packages, dictionary entries, estimates, dates, and acceptance conditions consistently. Do not hide new work inside an unchanged total. Retain the reason and agreement, and check the original baseline when the issue is an omission. Begin with one live project, draft a manageable set of deliverables, and test whether owners and completion evidence are clear. Correct gaps and overlaps before assigning dates.

For the next step, use Build a Gantt Chart in Excel or Google Sheets: Worked Table and Formulas; How to Set Project Milestones: A Template and Acceptance Criteria; Project Scheduling: Six Steps for Dependencies, Capacity, and Dates.