The work breakdown structure (WBS) is a deliverable-oriented hierarchical decomposition of work to be executed by the project team to achieve the project objectives and create the required deliverables.

The WBS organizes and defines the project’s planned work tasks. How detailed should it be and how many levels should it have? The obvious answer is as detailed and minimal as can be programmed, estimated, monitored and controlled, or it will not be effective. You can have the most detailed WBS in the world, but if you can’t manage it, it won’t work. So depending on the scope of the project and the project team (which includes the project manager), it should be “perfect”.

How do we arrive at an effective WBS?

o The project team should define the tasks

Project managers manage projects, the team performs the work and produces the deliverables; they are the ones who really know what to do. Ask the team to define the activities needed to produce each deliverable (top-down approach) and then peer review the activity definition to ensure they are complete (bottom-up review)

o Continuous wave planning approach

It progressively allows future tasks to be defined at a higher level while short-term tasks are defined at a lower level so that work can begin on them. As future tasks approach, they are reset to their lowest level

o Stay within the scope of the project

Make sure the deliverables and the tasks to produce them are exactly what the project calls for. Producing more and/or better without stakeholder approval is nice but counterproductive

A simple example of a good WBS for a house painting project:

o Clean walls (this is a deliverable)

– Pressure washer rental (this is an activity/task)

– Pressure clean walls (this is an activity/task)

– Back pressure cleaner (this is an activity/task)

o Paint walls (this is a deliverable)

– Select paint color (this is an activity/task)

– Buy paint (this is an activity/task)

– Buy painting tools (this is an activity/task)

– Paint walls (this is an activity/task)

A simple example of a bad WBS for a house painting project:

o Clean walls (this is a deliverable)

– Inspect which walls need cleaning (this is an activity/task)

– Find the best price to rent a pressure washer (this is an activity/task)

– Pressure washer rental (this is an activity/task)

– Pressure clean walls (this is an activity/task)

– Back pressure cleaner (this is an activity/task)

o Paint walls (this is a deliverable)

– Find the best price for the painting (this is an activity/task)

– Look at different brands of paint, types, brightness and colors (this is an activity/task)

– Select paint brand (this is an activity/task)

– Select the type of painting (this is an activity/task)

– Select paint brightness (this is an activity/task)

– Select paint color (this is an activity/task)

– Buy paint (this is an activity/task)

– Buy painting tools (this is an activity/task)

– Paint the walls on the north side (this is an activity/task)

– Paint the east side walls (this is an activity/task)

A WBS is not a schedule, and I am sorry if I disappoint some of you with this statement. Schedules are based on activities and indicate what to do, when to do it, and the order in which they should be done. This information is derived from the WBS. If you focus on the schedule while developing a WBS, you won’t develop a good WBS.

Once the WBS is created, you can use a programming tool to produce the program. It will automate most manual scheduling tasks like moving dates up or down based on effort, duration, dependency on other tasks, resources used, etc.

I think we’ve broken the work breakdown structure. Don’t you think so…? Okay I will.