As we develop the project’s lifecycle table, including stages, tasks, deliverables and work process, we must also plan the project’s content by breaking down the structure of the outcome services or products.
This breakdown is called a ‘Work Breakdown Structure’, or WBS. It is a central and essential tool of project planning.
A WBS divides the project’s content into smaller, manageable and measurable work units. The lower we drill down, the more detailed the work description. Accordingly, a WBS defines the entirety of the work to be undertaken within a given project’s framework and not a single task beyond it. In other words, if it does not appear in the WBS, it is not included in the scope of the project!
The major aim of breaking down the content into smaller units is to define the project’s boundaries. It is also useful when estimating the budget. Failing to include one component or another in the WBS will lead to changes at the execution stage when the omission is discovered, which will then lead to unavoidable deviations from the project’s planned schedule and budget.
The WBS is an essential tool in defining the scope of the project and forms the basis of the agreement with the clients as to what is or is not to be included in the project’s deliverables.
There are many models for breaking a project down into its components. The two most common and natural ones are:
- Functional Breakdown – This model describes the project’s content by listing the various components of the product or service being developed;
- Chronological Breakdown – This model describes the content of the project based on the planned order of task completion.
For example, the first level of a WBS in our book writing project called “Being a Project Manager” – based on the chapters included in the book, will look like this (left to right):
Whereas according to a chronological breakdown the first level will be in accordance with the work process of writing the book (left to right):
One is not limited to using only a single method at a time. That is, using chronological breakdown for the first stage of the project does not prevent the use of functional breakdown in the rest of the WBS. Regardless of the method chosen, the tasks at the lowest level of this hierarchical chart are ones that can be assigned for completion to a single team member or contractor. These lowest level tasks are the ‘Work Packages’ of the project.
A Work Package is the most basic component of a WBS, the cost and duration of which can be estimated relatively accurately. A WBS is concerned only with the project’s scope. It does not take into account either the order in which the tasks needs to be completed or any dependencies between them. The hierarchical depth of a WBS depends on the accuracy required for the budget estimate and the team’s ability to describe each component in the necessary degree of detail.
Typically, a project’s WBS includes two or three levels at the preliminary planning stage. As the project progresses, the content is further broken down into as many levels as are necessary to achieve ever more accurate work estimates.
The more detailed the WBS, the more useful a picture of the project’s extent it provides, enabling a more accurate planning and control process. However, breaking the project down into tiny components might require more managerial resources than can be justified. Therefore, one must carefully weigh the desired level of detail against the importance of having accurate estimates of the project’s components and the natural uncertainty and risk elements inherent in the project.
If so, to what extent should we break down the scope?
There are some rules of thumb for creating a WBS but the first two rules should ensure that every task at the bottom level of the breakdown structure has:
- A single and clear responsible person, and not several
- A content sufficiently clear that its further division would not add to its understanding
- The WBS describes the content of the project, not the order in which tasks are completed.
- It is possible to combine different methods to develop the WBS, but it is better to use a single approach under one component of the chart.
- The WBS should be broken down to a level where the work, cost, and resources required for each task can be estimated at their lowest level. It is recommended that a maximum and minimum size of each work package be defined according to required time or cost.
- It is important to find the right level of detail that will result in the necessary balance between the desired level of budget accuracy and the managerial overhead cost required to generate such a detailed structure.
- It is useful to find the right balance between a highly detailed WBS with lots of project-specific details and a more generic one that can then be re-used in future projects.
- The WBS reflects the project’s goals and describes all the tasks necessary to meet those goals.
- The WBS clearly delineates the project’s boundaries and creates a common language that can then be used by all stakeholders.
- The WBS forms the basis for planning the project in detail and for delegating areas of responsibility.
- The WBS forms an excellent basis for project control and lessons to be learned.
- The WBS can be used as the basis for planning similar projects in the future.
- Developing and maintaining a WBS requires managerial effort—often quite substantial.
- The more detailed the WBS, the less opportunity for managerial flexibility exists.
Please note: It is possible to present a WBS using an indented list instead of a hierarchical diagram as we have done above. However, using a diagram has a distinct advantage over an indented list: It is far easier to notice missing elements, surpluses and duplications on a diagram. Equally important is the fact that a diagram facilitates easier discussion and collaboration among the project’s partners while the WBS is being developed. Therefore, it is recommended that the first few levels of a project’s WBS be developed as a hierarchical diagram and, only after this diagram is approved, the rest of the WBS be developed as an indented list using a work breakdown tool.
Generating the WBS and creating the lifecycle table of the project’s stages and tasks discussed in the previous section should be done simultaneously—using one to help develop the other and vice versa—until both tools truly reflect everything we currently know about the project.