Creating a Work Breakdown Structure (WBS)

What is the secret behind accomplishing seemingly impossible tasks in any area? The answer is to break down the required work into smaller, manageable pieces. This is also a very important process in project management. To be able to actually execute the project, the project scope is broken down into manageable tasks by creating a work breakdown structure (WBS). In other words, a WBS is a deliverable-oriented hierarchy of the work that must be performed to accomplish the objectives of and create the deliverables for the project.

The figure below shows the input, tools and techniques, and output of creating the WBS. The project scope statement contains the list of deliverables and the product description. The requirements documentation describes the product and project requirements. Information in these two items provides the basis for creating the WBS. You should always consider organizational process assets while going through this and several other processes. In this case, the organizational policies and procedure related to creating the WBS, as well as relevant project files and lessons learned from previous projects, are some examples of organizational process assets that can be helpful.

Create WBS Process.jpg

Furthermore, even though each project is unique, there are similarities among sets of projects in an organization. These similarities can be used to prepare templates that will be used as a starting point for the WBS, to avoid the duplication of work. With or without templates, you will need to go through breaking down the deliverables, a very important step in creating the WBS.

Decomposition
Decomposition is a technique for subdividing the project deliverables into smaller, manageable tasks called work packages. The WBS is a hierarchical structure with work packages at the lowest level of each branch. Based on their complexity, different deliverables can have different levels of decomposition, as shown in the examples presented in the figure below. In a WBS such as the one below, the lines are called branches, and the boxes are called nodes.

You decompose the project work by executing the following steps:

Identify the deliverables and the work involved by analyzing the project scope statement and the requirements documentation.
Understand the relationships among the deliverables.
Structure and organize the first level (just below the root of the hierarchical tree) of the WBS hierarchy. Based on the project at hand, you can use one of the following approaches:

◆ Use the deliverables as the components in the first level.
◆ Use the phases of the project as the components in the first level.
◆ Use the subprojects as components in the first level. A subproject is a part of the project that is independent enough of the rest of the project that it can be performed by another project team. This approach is useful when you want to outsource (or procure) parts of the project.
◆ Use different approaches within each branch of the WBS— for example, a subproject and deliverables in the first level.

WBS Example.jpg

4. Decompose the upper level into more detailed components for the lower level.
5. Keep decomposing to lower levels until necessary and sufficient decomposition has been achieved.
6. Assign identification codes to the WBS components.

As the work is decomposed to lower levels of detail, work components become more concrete and manageable. However, you should avoid excessive decomposition, because it will lead to a large number of work packages, and it will not be possible to manage all of them effectively. In other words, excessive decomposition leads to inefficient use of management and other resources. Necessary and sufficient decomposition is the key.

TIP During decomposition, the components are defined in terms of how the project work will actually be executed and controlled. You must verify the correctness of the decomposition at each level by requiring that the lower-level components are necessary and sufficient to the completion of the corresponding higher-level deliverables.

One final point. While using the technique of decomposition, remember a useful concept or trick: rolling wave planning. It’s a fancy term that refers to handling a deliverable or subproject that currently cannot be decomposed fully because you don’t know the details about it yet— for example, it is to be executed far into the future. You leave the decomposition of such a deliverable at a level allowed by the available information and wait for further decomposition until more information becomes available. Yes, it is an example of progressive elaboration. The WBS document is the key item of the Create WBS process, but there are some other output items as well.

Output of Creating WBS
The output of the Create WBS process consists of the items discussed in the following list.

◆ Work breakdown structure. As explained earlier, the WBS is a deliverable-oriented hierarchical structure that decomposes the deliverables into the work that will be executed by the project team to create the planned deliverables and to accomplish the planned project objectives. The project manager creates this document with the help of the project team. Following are some important characteristics of the WBS:

◆ Control account. Remember that each node represents a deliverable or a component of it at certain level, and each deliverable will have scope, schedule, and cost attached to it. Some suitable nodes in the WBS are selected as management control points. At each of these control points, scope, schedule, and cost are integrated for the purposes of monitoring and controlling the performance. For example, the integrated scope, schedule, and actual cost at these points can be compared to the earned value to measure the project performance. (You will learn about earned value in an upcoming chapter.) Such management points are called control accounts. Each control account may have one or more work packages under it. Obviously, each work package must belong to only one account; otherwise, some factors, such as cost, will be double counted or counted multiple times. A WBS component that is below the control account, that has a welldefined work content but does not yet have a detailed schedule, is called a planning package.

◆ Code of account. Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources.

◆ Scope. The WBS embraces the full scope of the project. If a task is not included in the WBS, it will not be done as a part of the project.

◆ Step toward team building. Because the project manager creates the WBS with the help of the project team, it is also the beginning of the team-building process on the part of the project manager.

◆ Step toward scheduling. The WBS decomposes the project work into manageable pieces (work packages) that can be assigned to individuals. This helps define the responsibilities for the team members and is the starting point for building the schedule.

◆ Reference for communication. Throughout the project, the WBS works as a reference for communication regarding what is included in the project and what is not.

◆ WBS dictionary. This is a supporting document for the main WBS document to provide details about the components of the WBS. The details about a component might include elements such as a code of account identifier, description of work involved, quality requirements, acceptance criteria, a list of milestones schedule, cost estimates, required resources, contract information (if any), and the organization or group responsible for this component.

◆ Updates. During the create WBS process, the project team might realize that something out of the existing scope must be included in order to accomplish something in the scope. This will give rise to a change request, which might also come from other stakeholders during or after the first creation of the WBS. After the change request has been approved, not only the WBS will be changed— the scope statement must also be updated accordingly. The impact of the approved change request on the project scope management plan must be evaluated, and the plan must be updated accordingly.

◆ Scope baseline. This is not a different item in and of itself. The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all the change requests will be evaluated.

NOTE Do not confuse the WBS with other information breakdown structures, such as the organizational breakdown structure (OBS), which provides a hierarchy of the performing organization and can be used to identify organizational units for assigning the WBS work packages. Remember, the end goal of the WBS is to specify the project scope in terms of work packages; this is what distinguishes the WBS from other information breakdown structures.

You might wonder who creates the WBS. Well, it is your responsibility, and you, the project manager, create it with the help of the team. Which team? The work packages do not exist before the WBS is complete; therefore, no assignments have been made yet. Catch 22? Yes, you are right— depending upon the project, the final formal project team might not even exist yet. However, practically speaking, there will already be some people working with you on the project by now. Some of them are the potential team members. In addition to them, you can use the help of relevant experts in the organization and some stakeholders. Also, by now you have a very good idea of who will probably be working to generate the outcome of the project. It’s a good idea to involve those individuals in creating the WBS. This will give them a sense of participation and ownership. After all, the WBS will be the reference for the work throughout the project.

CAUTION FOR EXAM The CAPM/PMP exam expects you to know the ropes of the formal standard terminology. For example, if I say project plan, you should be able to figure out that I’m referring to the project management plan. Another example: If I say defining scope, you should be able to translate it to the Define Scope process, the same way you will translate the planning stage to the planning process group.

Before and After the WBS
From the initiating process group until now, I have discussed quite a few documents created in various processes. Some of these documents become input into another process that creates some other document. It is important to understand the order in which these documents are created and which document is an input to creating which other document. This is shown in the figure below.

Relationship between inputs, processes and order documents are created.jpg

The WBS is at the heart of project management. It affects directly or indirectly almost all the processes that are performed after its creation. The figure below shows some of the processes that are directly based on the WBS as a component of scope baseline.

The three most important things to remember about defining project scope are as follows:

◆ You need to collect requirements by using the Collect Requirements process before you can define the project scope.
◆ The requirements documentation generated by the Collect Requirements process and the project charter generated during the project initiation are used to define the scope, which is documented in the project scope statement.
◆The requirements documentation and the project scope statement are input items to create the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages. The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.

Summary
After a project has been initiated, the project management plan is developed to specify how the project at hand will be executed, monitored and controlled, and closed. The project management plan can contain subsidiary plans, such as a quality management plan, a risk management plan, a project scope management plan, and a scope baseline. The scope baseline consists of the project scope statement, work breakdown structure (WBS), and WBS dictionary. Collecting requirements is part of the scope planning, which creates requirements documentation. The project charter and requirements documentation are used to define the scope, which creates the project scope statement.

The project scope statement is a document that defines the scope of a project, including the product scope, by stating what needs to be accomplished by the project. It includes project deliverables, product description, product acceptance criteria, assumptions and constraints, and project exclusions. The project scope statement and requirements documentation are input items to creating the work breakdown structure (WBS), which is a breakdown of project deliverables into manageable pieces called work packages, which in turn are used to develop the project schedule. The WBS is supported by another document called the WBS dictionary, which offers details for the WBS components.

The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all change requests are evaluated. The WBS is the heart of project management, as it is used in managing many aspects of the project, including developing the schedule.

The schedule and communication planning are the next steps in your project plan.