So, lets get started!!!
What is WBS?
WBS stands for Work Breakdown Structure. It is something that helps breakdown the whole projects scope into smaller and more 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.
How to create the WBS?
Just like other documents related to project planning & management, the WBS is created using a set of inputs, by applying a set of tools & techniques to create the WBS. The picture below is a high level summary of how the WBS is created.
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.
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 used 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.
To understand Decomposition better, let us take a look at an example WBS of a Website Development Project
In any WBS – the lines are called “Branches” and the boxes are called “Nodes”. For practical understanding purposes, each of these nodes can be considered as one manageable piece of work.
As you can see, we have decomposed the whole project work into 3 parts:
1. User Interfaces
2. Server &
3. Database
Each of these parts is further divided into more nodes which carry out a specific function that is part of the higher level activity.
How do you decompose a Project Work?
You can decompose the project work by executing the following steps:
1. Identify the deliverables and the work involved by analyzing the project scope statement and the requirements documentation.
2. Understand the relationships among the deliverables.
3. Structure and organize the first level (Server, UI and Db in our example) of the WBS hierarchy. Based on the project at hand, you can use one of the following approaches:
o Use the deliverables as the components in the first level.
o Use the phases of the project as the components in the first level.
o 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 parts of the project.
o Use different approaches within each branch of the WBS, for example, a subproject and deliverables in the first level.
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.
Trivia:
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.
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 verifying that the lower-level components are necessary and sufficient for the completion of the corresponding higher-level deliverables.
Trivia:
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, you got it right. This 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 following items:
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. 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 well-defined 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 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, 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.
Trivia:
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.
A Last Word:
You might be wondering who creates the WBS. Well, as expected, it is your responsibility, and you, the project manager have to create it with the help of your team.
Previous: Defining Project Scope
Next: Before & After the WBS
Thank's for the information. It helped me a lot =)
ReplyDelete