Better decisions. More thoughtful work.

A work breakdown structure defines deliverables before the schedule

A small team in a meeting with an action card and notebook, no readable text.
AI-generated photographic illustration; not documentary photography.

A project plan begins as a long list of tasks, yet nobody can say whether the list covers everything being delivered. A work breakdown structure offers a different starting point: organise the scope into deliverables and progressively smaller components before turning it into a schedule.

The Project Management Institute’s discussion of work breakdown structures explains the deliverable-oriented approach. The structure describes the work within the project scope. It is not simply an organisation chart or a calendar with its dates removed.

Name what must exist at the end

For an illustrative office move, major components might include the prepared workspace, transferred equipment and operational handover. Each can be broken down until the team can define and manage the work sensibly. The example is a starting sketch, not a complete move checklist.

Ask what would demonstrate that each component is complete. “Communications” is vague; a defined set of approved notices and delivery responsibilities is easier to discuss. Include necessary coordination and handover work rather than counting only visible physical outputs.

Keep scope and sequence distinct

The structure helps establish what belongs in the project. Dependencies, durations and resource availability then help determine when activities happen. A lower item in the hierarchy is not necessarily something that occurs later in time.

Review the breakdown with the people who will deliver and accept the work. Look for gaps, duplicated components and items that fall outside the agreed scope. Where a component is ambiguous, add a concise description rather than multiplying labels.

When scope changes, update the affected parts deliberately and assess the consequences for the schedule and budget. A work breakdown structure is useful because it makes that conversation concrete. It should help the team explain the project, not become a decorative diagram disconnected from how the work is managed.