Work breakdown structure – OPEN

Add your own custom notes.

You need to login before you can record your own custom course notes.

Registration is easy, and completely free.

Topic 5.1: Work breakdown structure

Likes people like this topic - including you!

SharesThis topic has been shared 25 times!

Progress2,630 people have passed the quiz

Like many professions, project management has its own secret language (or jargon) that is used as a communication shorthand.

One term you will hear a lot is ‘WBS’

This is short for work breakdown structure.

The PMBOK Guide rather grandly defines the work breakdown structure as, ‘A deliverable-oriented hierarchical decomposition of the work to be executed by the (project) team.’

Why make things harder than they have to be?

I will let you in to a little secret, though: the WBS is nothing more than a list.

A list of all the things you need to do to make the project happen.

You know, kind of like every shopping or task list you have ever written in your life.

So where did all the big words come from?

Well, when we say ‘deliverable-oriented’ what we mean is that each task on the list has its own output or deliverable; in other words, something that can be handed to the next task or person in the chain.

For example, if I am building a house, my project task list (or WBS) might look something like this:

Plans

Finance

Foundations

Power and water

Walls and roof

Interior

Landscaping

Each task in my list is in fact a mini-project with an observable output that is necessary for some or all of the other tasks to start or finish.

So, when I have the plans, then I can start pouring foundations.

When the walls and roof are up, then I can begin work on the interior fittings.

Each task is oriented towards a deliverable.

For example, the task ‘Plans’ could be decomposed, or broken down into a series of less ambiguous tasks.

Now this is obviously an incomplete list and used for illustrative purposes only, but you can see that the more we break down the work, the more that uncertainty is avoided.

And as we know, uncertainty can be increasingly costly the further we get into our project.

Lists can also be structured ‘hierarchically’

By that we mean that the breakdown of our project tasks is clustered by common features.

The list shown above is structured in a hierarchy, with the main output, sub-outputs, and sub-sub-outputs.

Alternative ways to present your hierarchy could be by task owner or by phase.

You may even present the same WBS in different ways, depending on the needs (or for the convenience) of your stakeholders:

As you can see, hierarchies can be graphically represented as well

Although the WBS is the necessary first step towards developing your project plan, there is no hard and fast rule for structuring the breakdown of your project work.