Work Breakdown Structure

Once you are clear about the scope and the outcome of the project, the first thing you require is project planning. Project planning is to break down overall deliverable into manageable chunks, work out the schedule, identify resources and finally work out the cost. Work-Breakdown Structure is the most popular technique used by professional project managers using formal project planning methodologies.

A Work-Breakdown Structure (which is also called the Indenture Level Structure) is the best way to understand the detailed tasks of the project when you have to start a project from scratch. It breaks the project down into the major phases, deliverables and work components in sequential steps leading to greater project detail. These components can be further broken down into the activities to be carried out towards the outcome of the project. Hence work break down structure establishes the hierarchical order in a system, thereby identifying the tasks and milestones when applied to a project.

The Work-Breakdown Structure is definitely the most structured approach to identify the activities. But how does one actually identify the task? Well, this is something that you have to do individually. Following are few tips when building Work-Breakdown structure:

Identify level of breakdown process

You should be specific and detailed while breaking down the structure into components and further into activities. If project manager gets into too much detailing of activities then this will lead to micromanage the project which will consume more time in managing the project detailing instead of actual progress of a project.

Note the Jargon for components of WBS

If you are working on large project it is useful to place all the important terminology or information in WBS dictionary. The WBS dictionary should hold information in form of numeric identifier (1.1, 1.1.1, 1.1.2 etc.) containing track of all the summary and detailed activities, including a short description, estimated efforts and track of changes in WBS.

Don’t place requirements on WBS

Don’t place requirements on WBS. You can place deliverables on WBS and break it further into activities that are required to achieve the deliverable.

Place Deliverables and not Activities or Tasks

WBS should consists the deliverables which your customer or stakeholder will get as an outcome of the project. You don’t have to place activities or task carried out by project team to achieve those deliverables. These deliverables placed in the WBS may not change except the stakeholder gives change request.


Updating of WBS on Change Request

WBS is a formal document showing the deliverables of the project, any change in either the requirements of the customer or the change in WBS will be affecting scope of your project. Any change request given by the customer should reflect WBS in order to manage change.