Work Breakdown Structure Example: Customer Portal Launch

A deliverable-based Work Breakdown Structure for a 12-week customer portal launch at a B2B SaaS company. Six Level 2 deliverable areas, 18 Level 3 sub-deliverables, and 32 Level 4 work packages. Includes WBS Dictionary excerpts for the most ambiguous work packages and an analysis of common WBS construction mistakes this example avoids.

By Brett Helling

When You Would Build This

Project: B2B SaaS customer portal launch. Three engineering teams, one design team, one QA engineer, and one project manager. Timeline: 12 weeks. Objective: Deliver a self-service portal allowing customers to view invoices, manage users, and submit support tickets without calling customer service. Contract type: Time and materials with defined deliverables for phase gate approval. WBS required by the client as part of project initiation.

The Example

Example

The WBS Structure

The WBS is organized around what the project delivers, not what the team does. Each Level 2 element is a deliverable category. Each Level 3 element is a specific deliverable within that category. Each Level 4 element is a work package: the smallest unit that can be assigned, estimated, and verified.

WBS Number	Element Name	Level	Est. Effort (hrs)
1.0	Customer Portal Launch	1 (Project)	1,680
1.1	Project Management	2	160
1.1.1	Project governance documents	3	40
1.1.1.1	Approved project charter	4 (Work Package)	8
1.1.1.2	Approved WBS and WBS Dictionary	4	16
1.1.1.3	Approved project schedule	4	16
1.1.2	Status reporting	3	120
1.1.2.1	Weekly status reports (12 reports)	4	60
1.1.2.2	Phase gate review documentation	4	24
1.1.2.3	Project closure report	4	36
1.2	Discovery and Requirements	2	200
1.2.1	Stakeholder and user research outputs	3	80
1.2.1.1	Stakeholder interview summaries (6 interviews)	4	24
1.2.1.2	User research synthesis report	4	56
1.2.2	Approved requirements documentation	3	120
1.2.2.1	Functional requirements document (FRD)	4	48
1.2.2.2	Non-functional requirements (performance, security)	4	32
1.2.2.3	Client-approved requirements sign-off	4	40
1.3	Design	2	280
1.3.1	Information architecture	3	60
1.3.1.1	Approved site map and navigation structure	4	60
1.3.2	UX deliverables	3	140
1.3.2.1	Wireframes for all portal screens (12 screens)	4	80
1.3.2.2	Approved wireframes with client sign-off	4	60
1.3.3	Visual design deliverables	3	80
1.3.3.1	Approved visual design system and component library	4	80
1.4	Development	2	680
1.4.1	Backend and data layer	3	280
1.4.1.1	Configured development and staging environments	4	40
1.4.1.2	Implemented and tested database schema	4	80
1.4.1.3	Completed REST API for invoice, user, and ticket modules	4	160
1.4.2	Frontend application	3	240
1.4.2.1	Completed invoice management module (view, download, filter)	4	80
1.4.2.2	Completed user management module (add, remove, permissions)	4	80
1.4.2.3	Completed support ticket module (submit, track, close)	4	80
1.4.3	Third-party integrations	3	160
1.4.3.1	Tested Stripe integration for invoice payment	4	80
1.4.3.2	Tested Zendesk integration for ticket routing	4	80
1.5	Testing and Quality Assurance	2	200
1.5.1	Test planning and execution documents	3	80
1.5.1.1	Approved test plan	4	40
1.5.1.2	Completed functional test execution and sign-off	4	40
1.5.2	Acceptance and performance testing outputs	3	120
1.5.2.1	Completed user acceptance testing (UAT) with client sign-off	4	80
1.5.2.2	Performance test report (load to 500 concurrent users)	4	40
1.6	Deployment and Launch	2	160
1.6.1	Production deployment artifacts	3	80
1.6.1.1	Completed production deployment with zero-downtime migration	4	40
1.6.1.2	Post-launch monitoring dashboard configured and active	4	40
1.6.2	User enablement materials	3	80
1.6.2.1	Customer user guide (PDF, 15 to 20 pages)	4	40
1.6.2.2	Administrator training session recording	4	40

WBS Dictionary Excerpts for Critical Work Packages

1.4.1.3: Completed REST API for invoice, user, and ticket modules
Description: Includes all API endpoints required to support the three portal modules: invoice retrieval, invoice download, user creation and deletion, user role assignment, ticket submission, ticket status retrieval, and ticket closure. Does not include payment processing endpoints (covered in 1.4.3.1) or admin configuration endpoints (out of scope).
Acceptance Criteria: All endpoints return correct HTTP status codes, pass the functional test suite in 1.5.1.2, and are documented in the API reference document delivered alongside the code.
Estimated Effort: 160 hours. Owner: Backend Engineering Lead.

1.5.2.1: Completed user acceptance testing with client sign-off
Description: Includes execution of the UAT test plan against the staging environment, facilitation of two UAT sessions with the client's designated testers, documentation of all issues discovered, confirmation that all critical issues are resolved, and the client's written sign-off on the UAT completion report.
Acceptance Criteria: Client provides written sign-off on the UAT Completion Report. All critical and high-priority defects are resolved or accepted as known issues with documented workarounds. Defect log is complete and reflects final status of every issue raised.
Estimated Effort: 80 hours. Owner: QA Engineer and Project Manager.

Key Takeaway

What makes this WBS effective and worth studying: every Level 4 work package is a noun that describes something the project delivers, not an activity.

What Makes This Example Work

What makes this WBS effective and worth studying: every Level 4 work package is a noun that describes something the project delivers, not an activity. The work package is 'Completed REST API for invoice, user, and ticket modules,' not 'Build the API.' This phrasing forces the team to think about what done looks like rather than just what they will be doing. Project Management (1.1) appears as a Level 2 deliverable area, which is the most commonly missed section in WBS construction. Project governance documents, status reports, and the closure report are all deliverables the project produces. Including them in the WBS ensures they are estimated, scheduled, and budgeted. Teams that omit project management from the WBS consistently produce estimates that do not account for the oversight and coordination work that makes delivery possible. The WBS Dictionary excerpts demonstrate how ambiguity at the work package level gets resolved. The API work package (1.4.1.3) explicitly states what is included (three modules) and what is not included (payment processing, admin configuration). Without those boundaries, different team members and the client would interpret the scope differently. The UAT work package (1.5.2.1) includes the process steps and the acceptance criteria: written client sign-off. That specificity is what makes the work package usable as a contractual deliverable rather than a vague aspiration. One deliberate choice in this WBS: 'Approved requirements sign-off' appears as its own work package (1.2.2.3) separate from the requirements document (1.2.2.1). The document and the approval are different deliverables with different owners. The PM controls the approval process. The business analyst produces the document. Collapsing them into one work package would assign an approval dependency to someone without the authority to obtain it.

Build your own version free

Try This in ClickUp

Common Questions About Work Breakdown Structure Example: Customer Portal Launch

Why is Project Management included as a Level 2 deliverable in this WBS?

Project Management represents real work that consumes real hours and produces real deliverables (status reports, the project schedule, governance documents). Including it in the WBS ensures those hours are estimated and budgeted rather than appearing as unaccounted overhead at project end. Teams that omit Project Management from the WBS routinely produce estimates that come in under actual cost, not because the technical work was under-estimated, but because no one budgeted for the coordination and reporting that consumed 10 to 15 percent of the project hours.

How was the effort estimate of 1,680 total hours arrived at?

Each Level 4 work package was estimated independently by the team member responsible for that type of work: the backend lead estimated the API work packages, the QA engineer estimated the testing work packages, and the project manager estimated the project management work packages. Estimates were reviewed and challenged in a planning session where team members explained their reasoning. The WBS effort sum (1,680 hours) then became the basis for the project cost estimate and the schedule, not the other way around.

What happened to elements like risk management and change control?

Risk management activities are embedded in the Project Management deliverable area (1.1) and in the Phase Gate Review Documentation work package (1.1.2.2). Change control in this project is handled through the client approval steps embedded in work packages throughout the WBS (requirements sign-off, wireframe approval, UAT sign-off). On a larger project, risk management and change management might warrant their own Level 2 deliverable areas with their own work packages. The right level of decomposition depends on project size and client expectations.