What is a work breakdown structure? A WBS example for a payments integration

A work breakdown structure (WBS) is a hierarchy that divides a project's total scope into deliverables, then into smaller components, down to work packages that one owner can estimate and manage. PMI describes it as a hierarchical decomposition of the total scope of work the project team will carry out to meet the project objectives and create the required deliverables. A useful WBS names outcomes rather than tasks and accounts for all of the work, including project management itself. This guide explains the rules and levels, then walks through an illustrative WBS for integrating a new acquirer or payment gateway.

What does PMI say a work breakdown structure is?

In PMI's guidance, each level of the WBS is a more detailed definition of the project work. At the bottom sit work packages: the work defined at the lowest level of the WBS for which cost, effort, duration and resources are estimated and managed. PMI's blog adds that a work package has a unique identifier and a single point of responsibility, and can be estimated, managed and measured. PMI: What is a work breakdown structure? · PMI Lexicon of Project Management Terms

That property makes every cost line, risk and activity traceable to one coded piece of scope with one owner. The WBS is not a schedule or an org chart: it describes what will exist when the project is finished, while the schedule sets the order of work and critical path analysis then shows which activities can move the launch date.

What rules make a WBS useful?

PMI's practice-standard material sets out the core rules: the WBS covers all project work, including interim deliverables and project management; children add up to exactly their parent; and elements are deliverables written as nouns, while activities belong in the schedule. PMI: Practice Standard for Work Breakdown Structures

The first four rows come from PMI's material; the last two are common conventions, and the size threshold is a judgment, not a PMI number.

What are the levels of a WBS?

There is no fixed number of levels; most project WBSs settle at three or four:

1. Level 1: the project. The whole scope, for example "Acquirer B integration".
2. Level 2: major deliverables. Outputs a sponsor would recognize, such as payment flows, settlement and operational readiness.
3. Level 3: components. The parts of each deliverable, such as authorization, capture and refunds under payment flows.
4. Level 4: work packages. The units that receive an owner, an estimate and acceptance criteria.

Number every element (1.3.2, 1.4.1) so activities, costs, risks and change requests share one code. In a program, each project's WBS rolls up into the program view.

What does a WBS look like for a payment gateway integration?

This illustrative example is a merchant platform adding a second acquirer, through its gateway, for online card payments. Level 3 codes appear for two deliverables; the others decompose the same way.

Three deliverables are often missing from first drafts. Settlement and reconciliation (1.4) is where an integration that passes every test can still fail because nobody can match the money; see reconciliation as product infrastructure. Certification (1.6) has its own scope, test cases and evidence, set by the partner; payment partner certification readiness covers it. Operational readiness (1.7) is the work that lets support and operations run the new route on day one.

Regional scope changes the authentication work package. For payments in scope of the EU's strong customer authentication rules, 1.3.4 must cover authentication and exemption handling under the EU Regulatory Technical Standards, Regulation (EU) 2018/389. For UK payments, confirm current requirements with the acquirer. In the UAE, the central bank has announced the inauguration of Jaywan, the country's first national card scheme CBUAE: Jaywan inauguration, so state whether Jaywan acceptance is in or out of scope; a written exclusion gives the 100% rule a clear boundary.

What goes in a WBS dictionary?

PMI's lexicon defines the WBS dictionary as a document that provides detailed deliverable, activity, scheduling, cost and resource information about each component in the WBS. PMI's blog lists scope, milestones, responsible party, resources and acceptance criteria. An illustrative entry:

Acceptance criteria are where the dictionary earns its place: "settlement done" invites argument, "ten clean days and finance sign-off" does not. When scope changes, the dictionary is the baseline that a change request amends.

How does a WBS connect to the schedule and critical path?

Scope statement

States what the integration includes and excludes.

Decompose deliverables

WBS and dictionary

Coded work packages with owners and acceptance criteria.

Break packages into activities

Does every activity trace to a work package?

If noFix the scope first

Add the package through change control or drop the activity.

If yesSequence and estimate

Add durations and dependencies for each activity.

Dependency network

Critical path and baseline

Identify the path that sets the date, then baseline.

Simplified: real plans revisit the WBS as partner documentation and test results arrive.

Work packages break down into activities with durations and dependencies, which form the schedule. Risks tagged with a WBS code go into the RAID log, so a steering group can see which deliverable each one threatens.

Which WBS mistakes should you avoid?

• Writing a task list. "Hold kickoff, write code, test" is a schedule fragment that cannot show whether all scope is covered.
• Organizing by team. An org-chart WBS hides work between teams, which in payments is usually reconciliation and support.
• Leaving out non-engineering scope. Contracts, finance sign-off, training and merchant communication are deliverables too.
• Decomposing too far. A package smaller than the effort to track it is a to-do item.
• Never updating it. Change the WBS through change control and keep the previous baseline.

FAQ

What is the 100% rule in a work breakdown structure?

The WBS includes all of the project's work, including project management, and nothing outside it. At every level, child elements add up to exactly their parent.

What is the difference between a WBS and a project schedule?

A WBS lists deliverables as nouns and shows what will exist. A schedule lists activities as verbs, with durations, dependencies and dates.

How many levels should a WBS have?

No fixed number. Three or four suit most projects; stop when packages can be estimated, owned and evidenced.

What is a work package?

The lowest level of the WBS: a coded unit with one owner, for which cost, effort, duration and resources are estimated and managed.

Is a WBS useful in agile projects?

Yes, as a map of scope. Backlog items can carry WBS codes, showing that partner, finance and operations deliverables are covered while engineering runs in sprints.