Status Your Project with the WBS

The WBS serves as a perfect framework for project status reporting

Your WBS is the list of everything that needs to get done to complete the project.  It’s a ready-made framework for monitoring and statusing the project.

Let’s begin with the basic structure of the WBS:

WBS Code	WBS Description
100	Project Management
200	Product
200.1	Product Requirements
200.1.1	Stakeholder Requirements
200.1.2	System Requirements
200.2	Product Design
200.3	Product Build
200.4	Product Testing
200.5	Product Deployment

If we are going to use this for reporting, we need to include who’s in charge of delivering each WBS Item.  Generally, this can be the Project Manager for that piece of work.

WBS Code	WBS Description	Responsible
100	Project Management	PM
200	Product	n/a
200.1	Product Requirements	n/a
200.1.1	Stakeholder Requirements	Bill F
200.1.2	System Requirements	Jane T
200.2	Product Design	John X
200.3	Product Build	Mary G
200.4	Product Testing	Keith D
200.5	Product Deployment	Sara S

The updated table above shows which manager or lead has responsibility for delivering the work described in each WBS entry.  The items 200 – Product, and 200.1 Product Requirements have no designated responsible person because all the work under them are parcelled out to the work subitems under them.

Now we need to update the table to show the status.

WBS Code	WBS Description	Responsible	Status
100	Project Management	PM	n/a
200	Product	n/a	Started
200.1	Product Requirements	n/a	Started
200.1.1	Stakeholder Requirements	Bill F	Completed
200.1.2	System Requirements	Jane T	70%
200.2	Product Design	John X	NYS
200.3	Product Build	Mary G	NYS
200.4	Product Testing	Keith D	10%
200.5	Product Deployment	Sara S	NYS

In the above update, we see that item 200.1.1 has been completed, 200.1.2 is 70% completed, some of the work are Not Yet Started.  Work 100 – Project Management will have no status because it is ongoing work, while 200 and 200.1 will have only Started at their level. They will become Completed when all the sub-items under them have been completed.

The problem with the above is that it says nothing about whether the project is going according to schedule, going ahead, or being delayed.

For that we can use Earned Values to show the status of the work.

And because the status date of each individual work item may differ, it might be useful to add another column to indicate the as-of status date for that piece of work.

The Work Breakdown Structure (WBS), part 2

Since the WBS is a hierarchical structure, it has bottom level parts.  The WBS can be constructed like a table of contents, like so:

WBS Item 1 WBS Item 1.1 WBS Item 1.2 WBS Item 1.3 WBS Item 1.3.1 WBS Item 1.3.2 WBS Item 1.4 WBS Item 2 WBS Item 2.1

The lowest level items (shown above in bold) are called ‘Work Packages’.  The Work Packages are discrete pieces of work to be assigned to someone in the project, perhaps an individual, a business unit, and internal, team, or a contractor.  The key is that there is someone responsible for delivering the Work Package.

WBS’s should be oriented towards the deliverables, not towards the functional groups.

The reason for breaking down the project into smaller work packages is for management and control. 

The smaller a piece of work is, the easier it is to estimate how much time is needed to do the work.  Work packages also facilitate the scheduling of the project. The work packages can be the components mentioned in the master schedule. Work packages can be scheduled individually, and the resulting duration be fed into the master schedule, which only shows the work packages.

It is also easier to estimate the cost of smaller work than bigger work.  To estimate the cost of the project, just estimate the cost of each individual work package and sum them up.

The WBS is often claimed to be the backbone of the project, and some writers have said that project failures can be traced back to faulty WBS’s:

“Component or full-project failures, when they do occur, can often be traced to a poorly developed or non-existent WBS”(Norman, Brotherton, and Fried, "Work Breakdown Structures: The Foundation for Project Management Excellence")

The Work Breakdown Structure (WBS)

After the Gantt chart and the network diagram, there is perhaps no other project management tool that is more ubiquitously discussed than the WBS. 

As the Gantt chart is the primary tool for documenting the project schedule, so is the WBS the primary tool for documenting the project scope.

What is a WBS?

The PMBOK Guide describes the WBS as “a deliverable-oriented hierarchical decomposition of the work required to be executed by the project team to accomplish the project objectives and create the required deliverables.” 

That is, the WBS, “defines the total scope of the project.”

According to this definition, the WBS is a “decomposition of the work required”. 

But work required to do what? There are two kinds of work:

1. Work required to accomplish the project objectives
2. Work required to create the required deliverables

Together, these two kinds of work define the sum total of all kinds of work required: all project work falls into at least one of these two.  We say at least, because it is possible that some piece of work can be properly thought of as belonging to one or the other – that is not a matter of great concern.

The first kind of work is about work that need to be done in order to successfully complete the project objectives, even though they are not the purpose of the project.  An example of this type of work is developing the project schedule (which is needed to help attain project completion date objectives).  Other examples include developing a WBS,  supervising the work-force, and conducting project communications.

The second kind of work is covers what’s needed to deliver what the project needs.  Examples include designing a piece of software, integrating components, reviewing the quality of sub-components, and testing the components.

Note that the WBS is “deliverable-oriented”, but it is not a compilation of the deliverables.  It is a compilation of the work required, hierarchically organised around the deliverables.  The star of the show is the work, not the deliverables.

A software development project with the goal of delivering a commercial software product (and nothing else, not even documentation), the list of deliverables will not change, whether you use an Agile approach or a waterfall approach.

However, the WBS for the Agile approach will be different from the WBS of a waterfall approach.  Examples of the differences include:

• The Agile WBS will include such work as ‘Write User Stories’
• The Waterfall WBS will include such work as ‘Develop Design Document’

The deliverable is the outcome, the work is the effort and activities required to produce the outcome. 

Given that there are many different ways to produce the outcome, the WBS is a reflection of the plan chosen to produce the outcome.  Change the strategy, the WBS can potentially change.