Work Breakdown Planning Working Skill

What this skill is for

Large projects fail when work is described in paragraphs instead of packages. This skill converts a project charter, scope statement, or phase objective into a Work Breakdown Structure (WBS): a hierarchical set of work packages that are mutually exclusive, collectively exhaustive, and small enough to estimate and assign. Each work package has a clear boundary statement, a deliverable, a dependency list, and an owner. The WBS becomes the foundation for scheduling, resource allocation, risk identification, and status tracking. Without it, teams duplicate effort, miss dependencies, and discover gaps when it is too late to recover.

When to use this skill

• A project or phase is starting and the team needs a shared map of what must be built, configured, tested, or delivered.
• A scope statement exists but no one can answer "what exactly are we doing this week?"
• Multiple teams or vendors are involved and the boundary between their work is unclear.
• Estimates are requested but the work is too coarse to estimate reliably.
• A workstream has been running for weeks and progress reporting is still vague.
• An AI agent is planning a delivery and needs a structured decomposition to avoid hallucinating tasks.

Real work situations

SAP S/4HANA migration: missing cutover work packages

A project plan lists "data migration" as a single task. When the team starts work, they discover that data migration includes extraction, cleansing, validation, load, reconciliation, and rollback preparation. None of these are planned separately. The extraction team waits for cleansing rules. The validation team assumes the load team will handle errors. The cutover plan has no time allocated for reconciliation. A proper WBS would have decomposed data migration into six work packages with handoff criteria between each.

Integration project: overlapping ownership between middleware and SAP teams

A project to build an API between SAP and a third-party logistics system lists "integration build" as one work package. Both the middleware team and the SAP team claim it. Neither owns error handling, monitoring, or retry logic. The result is an API that works in the happy path but fails in production with no owner. A proper WBS would have separated interface specification, middleware development, SAP mapping, error handling, and monitoring into distinct packages with explicit owners.

Operational improvement: vague "process optimization" task

An AMS improvement initiative lists "optimize order-to-cash process" as a three-week task. The consultant spends two weeks trying to understand what "optimize" means. A WBS would have decomposed this into: current-state mapping, bottleneck identification, root cause analysis, solution design, configuration change, testing, and documentation. Each package has a deliverable and a stop criterion. The team knows when each piece is done and what comes next.

Inputs required

• Project charter, scope statement, or phase objective with approved boundaries.
• Stakeholder list showing who owns decisions, who provides input, and who receives output.
• Existing system or process documentation that describes the current state.
• Constraints: budget, timeline, resource availability, regulatory or compliance requirements.
• Assumption log capturing what the team is taking as given.
• Dependency list: external systems, teams, approvals, or data that the project needs.
• Risk register or known issues that may affect work sequencing (optional).

Questions to ask

• What is the smallest deliverable that, if completed, proves tangible progress?
• Which work packages can be done in parallel, and which must be done in sequence?
• What is the handoff criteria between this package and the next one?
• Who is the single owner accountable for the quality and completion of this package?
• What would happen if this work package were removed from scope?
• What external dependency could block this package, and when must that dependency be ready?
• Can this package be estimated in hours or days, or is it still too large to estimate?
• What artifact or evidence proves this package is complete?

Working method

1. Confirm the scope boundary. Read the project charter or scope statement. Identify what is in scope and what is out of scope. If the boundary is unclear, stop and clarify it before decomposing.
2. Define the top-level deliverables. List the major outcomes the project must produce. For an SAP project, these might be: configuration, data migration, integration, testing, training, and cutover. Each outcome becomes a level-one branch.
3. Decompose each outcome into work packages. Break each branch down until every package is small enough to estimate, assign, and complete within one reporting period. A rule of thumb: a work package should be 4–40 hours for a single owner. Stop decomposing when you reach that threshold.
4. Define the boundary statement for each package. Write one sentence that says what is included and what is excluded. Example: "This package includes the RFC destination configuration for the e-commerce interface. It excludes the middleware endpoint configuration, which is in package INT-002."
5. Define the deliverable for each package. Name the artifact or evidence that proves completion. Example: "Updated RFC destination in SM59 with successful connection test log."
6. Map dependencies. For each package, list which other packages must be complete before it starts, and which external inputs or approvals it needs. Use a dependency matrix or network diagram if the project is complex.
7. Assign ownership. Name one person who is accountable for each package. If no single owner exists, split the package or elevate the ownership decision before proceeding.
8. Validate mutual exclusivity and collective exhaustiveness. Check that no two packages overlap and that no required work is missing. Walk through the WBS with the team and ask: "Is there any work in this project that does not fit into one of these packages?" and "Is there any package that duplicates another?"
9. Document the WBS. Use the template below. Include package ID, name, boundary, deliverable, owner, estimated effort, dependencies, and status.
10. Baseline and review. Freeze the WBS at the start of the phase. Review it weekly. If scope changes, add or remove packages with a change log entry, not by silently editing the WBS.

Decision rules

• If a work package cannot be assigned to a single owner, split it or escalate the ownership gap before proceeding.
• If a work package is larger than 40 hours, decompose it further unless it is a single well-understood repeatable task.
• If two packages share the same deliverable, merge them or redefine the boundary so each has a unique output.
• If a package has no external dependencies, flag it as a candidate for early execution to build momentum.
• If a package depends on an external team with no committed date, place it late in the sequence and create a risk entry.
• If scope changes, update the WBS with a change log entry; do not silently edit the baseline.
• If a package has no clear completion criteria, define the deliverable before the package is approved for execution.

Deliverables

• Work Breakdown Structure — Hierarchical list of work packages with IDs, names, boundaries, deliverables, owners, effort estimates, dependencies, and status. See template below.
• Dependency Matrix — Table showing package-to-package and package-to-external dependencies with required dates.
• Change Log — Record of additions, removals, and modifications to the WBS after baseline.

Templates

Work Breakdown Structure (compact)

---
artifact: Work Breakdown Structure
project: <project name>
phase: <phase name>
baseline_date: YYYY-MM-DD
status: draft | baseline | revised
---

## 1.0 <Outcome 1>
### 1.1 <Package name>
- ID: WP-001
- Boundary: <What is included and excluded>
- Deliverable: <Artifact or evidence that proves completion>
- Owner: <Name>
- Effort: <hours or days>
- Dependencies: <WP-XXX, external item>
- Status: not started | in progress | complete | blocked

### 1.2 <Package name>
- ID: WP-002
- Boundary: <What is included and excluded>
- Deliverable: <Artifact or evidence that proves completion>
- Owner: <Name>
- Effort: <hours or days>
- Dependencies: <WP-XXX, external item>
- Status: not started | in progress | complete | blocked

## 2.0 <Outcome 2>
### 2.1 <Package name>
- ID: WP-003
- Boundary: <What is included and excluded>
- Deliverable: <Artifact or evidence that proves completion>
- Owner: <Name>
- Effort: <hours or days>
- Dependencies: <WP-XXX, external item>
- Status: not started | in progress | complete | blocked

## Change log
| Date | Change | Reason | Approved by |
|------|--------|--------|-------------|
| YYYY-MM-DD | <description> | <reason> | <name> |

Dependency Matrix (compact)

| Package ID | Depends on | Type | Required by | Source | Risk level |
|------------|------------|------|-------------|--------|------------|
| WP-003 | WP-001 | internal | 2026-07-15 | team | low |
| WP-005 | vendor API spec | external | 2026-07-20 | vendor | high |
| WP-007 | security approval | external | 2026-07-10 | security | medium |

Quality checklist

• Every approved scope item is covered by at least one work package.
• No two work packages overlap in deliverable or boundary.
• Every work package has a single named owner.
• Every work package has a defined deliverable that proves completion.
• Every work package is small enough to estimate and complete within one reporting period.
• Dependencies are identified for every package that is not a pure starting point.
• External dependencies have a required-by date and a source.
• The WBS has been validated with the team for completeness and exclusivity.
• Changes after baseline are recorded in the change log with a reason and approver.

Common mistakes

• Decomposing by organizational chart instead of deliverable. Consequence: work packages follow team boundaries rather than logical outcomes, creating handoff gaps and integration failures at the end of the project.
• Stopping at the activity level instead of the deliverable level. Consequence: the WBS lists "meetings" and "analysis" instead of "updated RFC destination" or "validated customer master extract." Progress is unmeasurable.
• Assigning a package to a group instead of a person. Consequence: no one is accountable. When the package is delayed, everyone assumes someone else is handling it.
• Ignoring dependencies until execution starts. Consequence: teams wait idle for external inputs, or work proceeds on assumptions that are later invalidated, requiring rework.
• Editing the WBS silently when scope changes. Consequence: the baseline is lost, the change log is empty, and no one can explain why the project grew or what was removed.

Weak output vs Strong output

Weak output

A vague bullet list of tasks with no hierarchy: "Plan the project. Do the analysis. Build the integration. Test everything. Go live." No owners, no boundaries, no deliverables, no dependencies. The list is indistinguishable from a project name and provides no guidance for estimation, assignment, or tracking.

Why it fails: The team cannot estimate effort because the units are too large. They cannot assign work because no one owns a specific deliverable. They cannot track progress because "analysis" is either 0% or 100% with no intermediate evidence. The project drifts until a deadline forces panic.

Strong output

---
artifact: Work Breakdown Structure
project: S/4HANA O2C Process Improvement — Phase 1
phase: Configuration and Testing
baseline_date: 2026-06-12
status: baseline
---

## 1.0 Configuration
### 1.1 Credit management setup
- ID: WP-101
- Boundary: Includes credit limit rules, risk class assignment, and VKM1 blocking logic. Excludes customer master data migration.
- Deliverable: Updated credit management config in S/4 with test customer C-10001 blocked at 50,000 EUR.
- Owner: Maria Chen
- Effort: 3 days
- Dependencies: None
- Status: in progress

### 1.2 Incompletion procedure mapping
- ID: WP-102
- Boundary: Includes incompletion procedure assignment for sales order header and item. Excludes partner determination changes.
- Deliverable: Incompletion procedure ZO2C-01 assigned and tested in VA01 with log.
- Owner: Dmitri Volkov
- Effort: 2 days
- Dependencies: WP-101 (credit blocking must be stable first)
- Status: not started

## 2.0 Data Preparation
### 2.1 Customer master validation
- ID: WP-201
- Boundary: Includes validation of 500 active customer records for credit limit and payment terms. Excludes vendor master.
- Deliverable: Validation report with error list and correction instructions.
- Owner: Sarah Okafor
- Effort: 4 days
- Dependencies: None
- Status: not started

## 3.0 Testing
### 3.1 Integration test — credit block to release
- ID: WP-301
- Boundary: Includes end-to-end test from order creation through credit block to manual release. Excludes automated regression.
- Deliverable: Test log with pass/fail per scenario and defect list.
- Owner: Maria Chen
- Effort: 3 days
- Dependencies: WP-101, WP-102
- Status: not started

## Change log
| Date | Change | Reason | Approved by |
|------|--------|--------|-------------|
| — | — | — | — |

Agent instructions

AI Prompt Pattern

Role: Work breakdown planner for an enterprise project.

Context: You have a project charter or scope statement with approved boundaries. You need to create a Work Breakdown Structure that the team can use for estimation, assignment, and tracking.

Task: Decompose the scope into outcomes, then into work packages with boundaries, deliverables, owners, effort estimates, and dependencies. Produce a WBS document and a dependency matrix.

Output format: Structured Work Breakdown Structure per the template, followed by a dependency matrix table.

• Never decompose without an approved scope boundary. If the scope is unclear, stop and request clarification before creating packages.
• Always decompose to the deliverable level, not the activity level. A work package is defined by what is produced, not by what is done.
• Every package must have a single owner. If ownership is shared, split the package or escalate.
• Every package must have a completion criterion. Define the artifact or evidence that proves it is done.
• Map dependencies explicitly. Internal dependencies link to other packages. External dependencies name the source and required-by date.
• Do not invent scope, owners, or estimates. Use the inputs provided. If information is missing, flag the gap rather than guessing.
• Validate mutual exclusivity and collective exhaustiveness. Check that no work is duplicated and no required work is missing.
• Link to Atlas diagnostics when work packages touch SAP configuration. For example, credit management setup should reference SAP Credit Management Diagnostics.

Related skills

• Task Clarification Working Skill — Use after decomposition to make each work package actionable.
• Priority Triage Working Skill — Use to sequence work packages when capacity is limited.
• Scope Creep Detection Working Skill — Use to guard the WBS boundary against unplanned expansion.
• Scope Boundary Definition Working Skill — Use to define the scope boundary before decomposition begins.

Related Atlas pages

• SAP Process Audit — Diagnostic context for decomposing process improvement work.
• Operational Memory for SAP AMS — How work breakdown feeds into operational knowledge capture.

Verification status and limitations

This skill is a public working interpretation of work breakdown practices. It is not official PMP, WBS dictionary, or SAP methodology. It focuses on practical decomposition for enterprise projects where packages must be small enough to estimate and track.

Known limitations: the skill assumes a scope boundary exists. It does not cover earned value management, critical path calculation, or agile backlog breakdown. It treats the WBS as a planning and tracking artifact, not a financial accounting structure. Effort estimates are rough sizing, not detailed bottom-up estimates. For projects with heavy regulatory or safety requirements, additional decomposition standards may apply.