Developing Work Breakdown Structure (WBS)

Project WBSWhen all the deliverables of the project are defined and the scope is clearly stated, the project manager needs to answer this question: How to make relationships between the deliverables and project work? Developing a work breakdown structure (WBS) is the way to do this. A WBS creates links between the deliverables and their numerous components at all possible levels of project work. It serves as a foundation for planning and defining 100% of the work planned for completion.

What is a Work Breakdown Structure (WBS)?

Typically, a Work Breakdown Structure for a project is a deliverable-oriented hierarchical decomposition of project work planned for completion by the project team. The WBS creates a detailed representation of the relationships between the deliverables and their components which are defined within the project scope.

In contrast to the project implementation schedule, the WBS defines the “what” part of project work, while the schedule defines the “when” and “how” parts of the project (The PMBOK Guide). The work breakdown structure gives a clear and efficient format to define the volume of project work necessary for producing every deliverable and to track the progress of project implementation.

The main idea of the WBS is to decompose the necessary implementation process into smaller, manageable and auditable pieces of project work that can be scheduled and measured against the scope baseline. There is no single and accepted format for the work breakdown structure (WBS), but usually it has a tabular view. You are free to choose any WBS format that fits into your implementation needs in the best way. The WBS is designed, formatted and managed by means of project management software (for example, MS Project software, VIP Task Manager software).

WBS Development

Developing the work breakdown structure means defining the relationships between the project goals, deliverables and scope. Usually this process is about creating a detailed decomposition of work planned for completion into smaller, more manageable and measurable components (The PMBOK Guide). Developing the work breakdown structure involves the following steps:

  • Identify project deliverables based on stakeholder requirements (use the project deliverables statement)
  • Define the amount of work necessary for producing the deliverables.
  • Create a high-level decomposition of work using the above information.
  • Specify the high-level decomposition by smaller, more manageable pieces of work to create separate work packages.

Considering these steps, the WBS development involves creating a decomposition that consists of the three major levels:

  • Level #1: This WBS level is dedicated to the scope of the project. At this level you should describe the scope baseline. The first level of the WBS also includes the information on the phases of the implementation life cycle identified atthe Project Setup.
  • Level #2: The second level of the work breakdown structure dedicated to the project deliverables. At this level you should outline the deliverables, including product features and functions, based on stakeholder requirements. All the project deliverables should be divided into manageable, auditable and measurable components. You should decompose or divide the deliverables into smaller activities to determine timeframes, assign team responsibilities, estimate resource needs and assess work effort.
  • Level #3: The third level of the WBS should present scheduled tasks and jobs. You should define elements of activities (tasks and jobs) and identify dependencies between them (how one element of a particular activity depends on the completion of another one). The level includes separate work packages necessary for producing the desired deliverables.

The WBS can be further divided into more levels but this involves additional risks. As more levels are added to the WBS as higher risk it brings to the project. Usually the three-level  development process is adequate for most projects.

Daniel Linman

Daniel is a business analyst for a Canadian software company. He has worked on various IT projects but is most interested in systems architecture and software development. In his free time, Daniel enjoys playing the guitar, loves going for hikes, and spending time with his family.

You may also like...