# Work Breakdown Structure: [Project name]

> Deliverable-oriented decomposition of the full project scope into
> manageable work packages, with a WBS dictionary that defines each
> element. Based on common project management practice. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Decompose deliverables (nouns), not activities (verbs). Activities belong in the
  schedule, which is built from the work packages defined here.
- Apply the 100% rule at every level: the children of an element add up to exactly
  the work of the parent, no more and no less.
- Stop decomposing when a work package can be estimated, assigned to one owner and
  verified as complete.
- Baseline the WBS with the scope statement; later changes need a change request.
-->

| Field | Value |
|---|---|
| Document ID | [WBS-PROJECT-001] |
| Project | [Project name] ([code]) |
| Version | [0.1] |
| Status | [Draft / Approved / Baselined] |
| Owner | [@project-manager] |
| Related | [Scope statement, Project schedule SCH-001] |
| Last updated | YYYY-MM-DD |

## 1. Purpose and scope

<!-- Guidance: State which scope baseline this WBS decomposes and any parts deliberately excluded. -->

This WBS decomposes the approved scope statement of [Project name] (version [x.y]) into deliverables and work packages. It covers all project work, including project management, and excludes [items explicitly out of scope, for example ongoing operations after handover].

## 2. Numbering and conventions

<!-- Guidance: Define the numbering scheme once so the WBS, schedule, cost codes and RAID log can reference the same IDs. -->

Elements are numbered hierarchically: level 1 is the project (1), level 2 the major deliverables (1.1, 1.2), level 3 sub-deliverables (1.2.1) and the lowest level the work packages. Work package IDs are reused as cost codes in [finance system] and as task groups in the schedule.

| Convention | Rule |
|---|---|
| Names | Nouns describing outcomes, for example "Test environment", not "Set up environment" |
| Depth | Three to four levels for most projects |
| Project management | Always a separate level 2 element |
| Owner | Every work package has exactly one accountable owner |

## 3. WBS diagram

<!-- Guidance: Show levels 1 to 3 in the diagram; keep work packages in the outline if the chart becomes crowded. -->

The diagram below shows the top three levels of the WBS.

```mermaid
flowchart TB
  P["1 Digital onboarding project"]
  P --> A["1.1 Project management"]
  P --> B["1.2 Process design"]
  P --> C["1.3 Onboarding platform"]
  P --> D["1.4 Organisational change"]
  P --> E["1.5 Deployment"]
  C --> C1["1.3.1 Application front end"]
  C --> C2["1.3.2 Integrations"]
  C --> C3["1.3.3 Test and acceptance"]
  D --> D1["1.4.1 Training"]
  D --> D2["1.4.2 Communications"]
```

## 4. WBS outline

<!-- Guidance: The outline is the authoritative list. Mark work packages with (WP). -->

The outline lists every element down to work package level.

- **1 [Digital onboarding project]**
  - 1.1 Project management
    - 1.1.1 Planning and baselines (WP)
    - 1.1.2 Monitoring, reporting and governance (WP)
    - 1.1.3 Project closure (WP)
  - 1.2 Process design
    - 1.2.1 Current-state process analysis (WP)
    - 1.2.2 Target process and procedures (WP)
  - 1.3 Onboarding platform
    - 1.3.1 Application front end (WP)
    - 1.3.2 Integrations with core banking and identity service (WP)
    - 1.3.3 Test and acceptance (WP)
  - 1.4 Organisational change
    - 1.4.1 Training (WP)
    - 1.4.2 Communications (WP)
  - 1.5 Deployment
    - 1.5.1 Production release (WP)
    - 1.5.2 Hypercare and handover (WP)

## 5. The 100% rule check

<!-- Guidance: Confirm the decomposition is complete and has no overlaps. Do this review with the workstream leads. -->

The WBS has been reviewed against the scope statement to confirm that the children of each element contain all of the parent's work and nothing outside it.

| Check | Result | Reviewer | Date |
|---|---|---|---|
| Every in-scope item in the scope statement maps to at least one work package | [Pass / Gaps listed] | [@name] | YYYY-MM-DD |
| No work package contains out-of-scope work | [Pass] | [@name] | YYYY-MM-DD |
| No two work packages cover the same work | [Pass] | [@name] | YYYY-MM-DD |
| Effort and cost of children sum to the parent | [Pass] | [@name] | YYYY-MM-DD |

## 6. WBS dictionary

<!-- Guidance: One row per work package. Acceptance criteria must be verifiable. Effort and cost come from bottom-up estimates and roll up to the cost baseline. -->

The dictionary defines each work package so that owners, estimators and acceptors share one description.

| ID | Name | Description | Deliverables | Acceptance criteria | Owner | Effort (pd) | Cost | Dependencies |
|---|---|---|---|---|---|---|---|---|
| 1.2.2 | *Example:* Target process and procedures | Design the future onboarding process for 7 customer scenarios | Process maps, procedure documents | Signed off by head of operations; all 7 scenarios covered | [@ba-lead] | 40 | 4,800 EUR | 1.2.1 |
| 1.3.2 | *Example:* Integrations | Build and test APIs to core banking and identity service | Interface specs, integration code, test evidence | All interface tests pass; latency below 2 s at p95 | [@tech-lead] | 90 | 10,800 EUR | 1.2.2, vendor contract |
| 1.4.1 | *Example:* Training | Train 240 branch staff on the new process | Training plan, materials, attendance records | 95% of staff trained before go-live; assessment pass rate 80% | [@change-lead] | 35 | 9,200 EUR | 1.2.2, 1.3.3 |
| [x.y.z] | [Name] | [Description] | [Deliverables] | [Criteria] | [@owner] | [n] | [Cost] | [IDs] |

## 7. Work package sizing rules

<!-- Guidance: Agree sizing limits before decomposing, so packages are comparable and trackable. -->

Work packages follow these sizing rules, which balance control against administrative effort.

| Rule | Threshold | Rationale |
|---|---|---|
| Maximum effort | [80] person-days or [8 to 80] hour rule at task level | Progress visible within one reporting period |
| Maximum duration | [6] weeks | Problems surface before they become late |
| Single owner | One accountable person | Clear accountability |
| Verifiable output | Each package produces a deliverable with acceptance criteria | Objective measure of completion |
| Estimable | Effort and cost can be estimated with +/- 15% confidence | Supports a credible cost baseline |

Packages that break a rule are either decomposed further or justified in the notes below.

[Justified exceptions, for example: 1.5.2 Hypercare runs 8 weeks because the service level must hold for a full month-end cycle.]

## 8. Roll-up summary

<!-- Guidance: Totals must reconcile with the cost baseline in the project management plan. -->

The table rolls up effort and cost to level 2.

| ID | Element | Effort (pd) | Cost | Share of total |
|---|---|---|---|---|
| 1.1 | Project management | *Example:* 120 | 14,400 EUR | 8% |
| 1.2 | Process design | 70 | 8,400 EUR | 5% |
| 1.3 | Onboarding platform | 260 | 171,200 EUR | 62% |
| 1.4 | Organisational change | 80 | 34,000 EUR | 12% |
| 1.5 | Deployment | 60 | 36,000 EUR | 13% |
| **Total** | | **590** | **264,000 EUR** | **100%** |

## 9. Change history

<!-- Guidance: Each change after baselining cites its change request. -->

Changes to the baselined WBS are recorded below.

| Version | Date | Change | Change request | Author |
|---|---|---|---|---|
| 1.0 | YYYY-MM-DD | Baselined at plan approval | n/a | [@name] |
| 1.1 | YYYY-MM-DD | *Example:* Added 1.3.4 Accessibility audit | CR-004 | [@name] |

## Standard and licence note

Based on common project management practice for work breakdown structures
and WBS dictionaries. This template is original text written for this
collection. Template licence: MIT.