Work breakdown structure

A WBS decomposes deliverables rather than activities, level by level, until each work package is small enough to estimate honestly. It is a tree, so it draws itself from text.

The discipline is that every level is a noun, not a verb. That is what keeps it a breakdown of the work rather than a schedule.

#When to reach for one

• Scoping before estimating, where the risk is forgetting whole areas.

• Agreeing scope with a client or stakeholder.

• Deriving a project plan from something more structured than a list.

#How to draw it in Capable

#A worked example

A WBS decomposed to work packages:

The source, which you can paste into a new diagram and edit:

flowchart TD
  P[1.0 Website relaunch]
  P --> A[1.1 Content]
  P --> B[1.2 Design]
  P --> C[1.3 Build]
  P --> D[1.4 Launch]
  A --> A1[1.1.1 Content audit]
  A --> A2[1.1.2 Rewrite core pages]
  B --> B1[1.2.1 Design system]
  B --> B2[1.2.2 Page templates]
  C --> C1[1.3.1 CMS setup]
  C --> C2[1.3.2 Template build]
  C --> C3[1.3.3 Migration]
  D --> D1[1.4.1 Redirects]
  D --> D2[1.4.2 Cutover]

#A few things that catch people out

• Number every node. The numbers become the reference in every later conversation.

• Stop decomposing when a package can be estimated in days rather than weeks.

• A WBS is not a schedule. Sequence comes later, from a Gantt or PERT chart.

#Related

A plan you can change is a plan people trust.