Create Work Breakdown Structure (WBS)

Create WBS (Work Breakdown Structure) is the process of subdividing project deliverables and project work into smaller, more manageable components.

The Create WBS process is part of the Project Scope Management knowledge area in the PMP.

Why do project teams need a WBS?

·         Defining and organizing the project work

·         Project budget can be allocated to the top levels of the work breakdown structure

·         Allocating time and cost estimates to WBS, a project schedule and budget can be quickly developed

·         Tracked to identify project performance and identify issues and problem areas

·         Identify potential risks in a given project

PITFALLS:
Lastly let's look at five common pitfalls to creating a WBS. If you can keep these few possible issues in mind when you are creating your WBS, you and your team will be much more successful at creating a useful and accurate Work Breakdown Structure.
1. Level of Work Package Detail
When deciding how specific and detailed to make your work packages, you must be careful to not get too detailed. This will lead to the Project Manager to have to micromanage the project and eventually slow down project progress. On the other hand, work packages whose details are too broad or large become impossible for the Project Manager to manage as a whole.
2. Deliverables--Not Activities or Tasks
The WBS should contain a list of broken down deliverables. In other words, what the customer/stakeholder will get when the project is complete. It is NOT a list of specific activities and tasks used to accomplish the deliverables. How the work is completed (tasks and activities) can vary and change throughout the project, but deliverables cannot without a change request, so you do not want to list activities and tasks in the WBS.
3. WBS is not a Plan or Schedule
The WBS cannot be used as a replacement for the project plan or schedule. A WBS is not required to be created in any type of order or sequence. It is simply a visual breakdown of deliverables.
4. WBS Updates require change control
The WBS is a formal project document, and any changes to it require the use of the project change control process. Any changes to the WBS change the deliverables and, therefore, the scope of the project. This is an important point to help control scope creep.
5. WBS is not an Organizational Hierarchy
The WBS and Organizational Hierarchy chart are never the same thing. Although often similar in appearance, these two documents are very different. The Organizational Hierarchy shows things like chain of command and lines of communication, but the WBS is restricted simply to a project and shows only the deliverables and scope of that project.

The inputs to the WBS are:

1)      Organizational Process Assets – The templates, check list can be find here

2)      Requirements Document – List the functional and non functional requirements of the project

3)      Project Scope Statement – Lists what needs to accomplished in this project

Tools and Techniques:

Decomposition is the sub division of project deliverables into smaller components, until the work and deliverables are broken down as work packages.

This WBS breaks the project work down by phases.

The phases are break down by deliverables.

The planned work contained within the lowest level of WBS components is called as work packages.

The work packages can be scheduled, assigned to resources, cost estimated, monitored and controlled.

How to decompose the deliverables into the work package:

·         Start with a major deliverables

·         Identify the related works in the deliverables

·         Structure and organize the deliverables

·         Begin breaking down the project into smaller and smaller pieces

·         Developing and assigning the identification codes to the WBS work packages

·         Verify the work package is assigned and manageable

The good WBS should have:

·         Easy to understand

·         Corresponds to job description

·         Not too detailed

·         Preserve the most important relationship among the tasks

·         Doesn’t add length to the project

The outputs are:

1) WBS:

WBS is all about taking deliverables and coming up with work packages that will create them.

The sample WEBS contains:

·         Task ID

·         Task Description

·         Predecessor

·         Owner

·         Role

·         % Complete

·         Start Date

·         Finish Date

·         Deliver To

Tools to create WBS:

·         Mind Mapping Software

·         Microsoft Project Planner

·         I-Planner

·         Excel Sheet

2) WBS Dictionary:

The WBS dictionary is the document that supports WBS which provides more detailed description of the components in the WBS.

The WBS dictionary document contains:

·         Work package id

·         Work package name

·         Responsible person

·         Schedule milestone

·         Associated activities

·         Cost estimate

·         Quality requirements

·         Acceptance criteria

·         Technical information

3) Scope Baseline:

As the project goes on, you will want to compare how you are doing to what you planned for. So, the scope baseline is there to compare against. It’s made up of the scope statement, the WBS, and the WBS Dictionary. When work gets added to the scope through change control, you need to change the baseline to include the new work packages for that work, so you can always track yourself against the plan.

4) Project document updates:

Whenever a change is approved through change control, the baseline needs to be updated. Approved changes are changes to the scope management plan also, so it’s important that you re-baseline your project when they are approved. That way, you’ll always be comparing your performance to the most updated plan.


PITFALLS:
Lastly let's look at five common pitfalls to creating a WBS. If you can keep these few possible issues in mind when you are creating your WBS, you and your team will be much more successful at creating a useful and accurate Work Breakdown Structure.
1. Level of Work Package Detail
When deciding how specific and detailed to make your work packages, you must be careful to not get too detailed. This will lead to the Project Manager to have to micromanage the project and eventually slow down project progress. On the other hand, work packages whose details are too broad or large become impossible for the Project Manager to manage as a whole.
2. Deliverables--Not Activities or Tasks
The WBS should contain a list of broken down deliverables. In other words, what the customer/stakeholder will get when the project is complete. It is NOT a list of specific activities and tasks used to accomplish the deliverables. How the work is completed (tasks and activities) can vary and change throughout the project, but deliverables cannot without a change request, so you do not want to list activities and tasks in the WBS.
3. WBS is not a Plan or Schedule
The WBS cannot be used as a replacement for the project plan or schedule. A WBS is not required to be created in any type of order or sequence. It is simply a visual breakdown of deliverables.
4. WBS Updates require change control
The WBS is a formal project document, and any changes to it require the use of the project change control process. Any changes to the WBS change the deliverables and, therefore, the scope of the project. This is an important point to help control scope creep.
5. WBS is not an Organizational Hierarchy
The WBS and Organizational Hierarchy chart are never the same thing. Although often similar in appearance, these two documents are very different. The Organizational Hierarchy shows things like chain of command and lines of communication, but the WBS is restricted simply to a project and shows only the deliverables and scope of that project.