In this post I’m going to show you how to create a Work Breakdown Structure as the foundation for your project planning.
A Work Breakdown Structure (WBS) is a simple, yet methodical way of organizing a project scope in a hierarchy of smaller and manageable components and is the foundation of project planning.
So, why bother creating a WBS for your project?
Hereafter a few reasons…
- Gives clarity on the project needs in terms of deliverables and success criteria – it highlights the “what” of the project
- Subdivides the scope into manageable components in terms of size, duration, and responsibility
- Aids in monitoring and controlling the project
- 100% Rule: The WBS should define the total scope of the project and capture ALL deliverables, including project management. If not, the risk of gaps and missing components is high.
- Mutual Exclusivity: It is important that there is no overlap in scope definition between two elements of a WBS. This ambiguity could result in duplicated work.
- Deliverables, Not Actions: Deliverables are the desired ends of the project, such as a product, result, or service and can be predicted accurately. Actions, on the other hand, may be difficult to predict accurately.
- Reasonable Level of Detail: Don’t go into too much detail. What you’re looking for is enough detail so you can plan, manage and control the project. An effective limit of WBS granularity may be reached when it is no longer possible to define deliverables and the only details remaining are actions. The lowest level in the WBS is called a “Work Package”.
- List high-level deliverables
- Get granular
- Check WBS principles
In the following image you can see an ideal Work Breakdown Structure.
WBS applies also to Agile. An agile WBS is organized around end-user deliverables. Here deliverables are decomposed into Epics, User Stories and Functionalities.