Work breakdown structures
Break the outcome into manageable deliverables without losing the whole.
The idea
A work breakdown structure decomposes project scope into deliverables and smaller work packages. It helps identify ownership, estimates, and coverage. It is not necessarily a chronological task list or a network schedule. Include testing, documentation, security verification, and handover where they are required. Use a level of detail that supports management without duplicating every minor action.
In practice
A recovery project includes recovery design, protected copies, tested restoration, operating procedures, and owner training as distinct deliverables.
A common misunderstanding
Breaking work into many lines does not guarantee that all outcomes are covered. Review the structure against scope and acceptance.
Check your understanding
How does a WBS help with omissions?
Think it through: It makes major deliverables explicit so missing work can be identified before delivery is considered complete.
Decompose the deliverable, not just the meeting list
A work breakdown structure organizes project scope into smaller components so the team can assign responsibility and estimate effort. Begin with the outcome and its major deliverables. Break each into pieces that are manageable enough to plan, while retaining a clear relationship to the whole. Different organizations use different levels and terminology; consistency matters more than an impressive numbering scheme.
For a secure onboarding improvement, top-level deliverables might include account provisioning, access approval, employee guidance, and operational handover. Under account provisioning, work could include role templates, a test workflow, and an exception process. Meetings and emails may support these deliverables, but a list of meetings alone does not describe the required scope.
A fictional missing branch
A team decomposes an authentication rollout into purchasing, configuration, and deployment. A review reveals no branch for users who lose their devices. Adding recovery design, support training, and a rehearsal changes the estimate, but also prevents an incomplete service from being declared finished. The structure has exposed a genuine gap rather than created unnecessary paperwork.
As decomposition continues, check that deliverables do not overlap ambiguously. If two work packages both claim ownership of access approval, clarify their boundaries. If nobody owns validating the resulting permissions, create a responsible work package. Smaller pieces should improve accountability rather than fragment the outcome into disconnected tickets.
Practice a scope review
Draw a three-level structure for a fictional backup upgrade. Include protected data, configuration, restore validation, and handover. Ask whether every required outcome appears somewhere and whether any item is counted twice. Choose one work package and describe its owner and acceptance evidence. Avoid breaking it into tiny actions that make the diagram harder to maintain without improving estimates or responsibility.
Keep exploring
References & further reading
Original explanations, with primary references for deeper study.
UK Government: Project Delivery Functional Standard