Decomposition

Scope technique · See it on the map

Runnable here

Splitting project work into progressively smaller pieces until each is small enough to plan and track.

When to use it

Use it once scope is defined and you need to turn 'what we're delivering' into 'what work that requires' -- creating the WBS, or re-decomposing a deliverable that turned out to be too coarse to estimate or assign to one owner.

When to avoid it

Don't decompose past the point a work package can be usefully estimated and assigned -- decomposing every deliverable down to hour-level tasks up front produces a WBS nobody maintains and that goes stale the first week. For work far enough out that its detail genuinely isn't knowable yet, decompose only the near-term deliverables now and leave the rest as a single placeholder package to break down later (rolling wave), rather than guessing at detail you'll just rewrite.

Steps

1. Start from the accepted scope statement and the deliverables it names -- decomposition subdivides deliverables, not the org chart and not a task list you already have in your head.
2. Identify the major deliverables (or, on a driftless-planned project without a WBS, the workstreams) and break each one into its component deliverables one level at a time.
3. Keep going until a component deliverable is small enough that one task -- or a short, ownable set of tasks -- can produce it and one person can be accountable for it.
4. Name each level by the deliverable it produces ('Payment integration tested', not 'Backend team'), and verify with the team that does the work that the lowest level is estimable.
5. Since driftless has no dedicated WBS node today, record the decomposition as tasks nested under the workstream (or project) the deliverable belongs to, with the deliverable name as the workstream or task title -- the hierarchy the reader has is project / workstream / task, and decomposition's job is to make sure each task in it is a deliverable-sized piece of work, not an activity fragment.

What it produces

• A hierarchy of deliverables broken down to work-package level (in driftless: workstreams and tasks named after what they produce).
• A set of work packages each small enough for one owner to estimate and be accountable for.

Common pitfalls

• Decomposing by organizational team ('Frontend team', 'DBA team') instead of by deliverable -- the breakdown mirrors the org chart, not the product, and two teams' work on the same deliverable ends up untracked as a single thing.
• Stopping a level too coarse to estimate ('Build the reporting module' as one task no one can size) or going a level too fine to manage (tracking fifty two-hour tasks that turn every status update into an audit).
• The classic error: decomposing into activities ('design', 'code', 'test') instead of deliverables. A WBS is a hierarchy of things produced, not a hierarchy of verbs -- 'design the login screen' is an activity that belongs inside a task against the deliverable 'Login screen', not a decomposition level of its own.

Worked example

A regional credit union is building a new online loan application. The scope statement names one deliverable: 'Online loan application, application through decision'. The PM decomposes it into component deliverables -- 'Applicant identity verification', 'Document upload', 'Underwriting decision integration', 'Applicant status notifications' -- each sized so one engineer or a small pair can own it. In driftless, each becomes a workstream under the project, with tasks underneath named for what they produce ('Document upload accepts PDF and JPEG', not 'Write upload code'). When 'Underwriting decision integration' turns out too big to estimate as one task, the PM decomposes it one more level into 'Send application to underwriting API' and 'Receive and store decision result' rather than leaving it as one unestimable line.

Source

• PMBOK-6 §5.4.2.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.