Friday, December 3, 2010

WBS yet again

From time to time, the debate reemerges about the definition of the WBS. And so it happened again last month with a series of exchanges about 'work' vs 'the product of the work'.

This time, the fireworks began with a posting my Mike Clayton, followed by several responses from readers and critics.

In my response to Mike's post, I said:
Hey Mike: On this side of the pond, the WBS originated in the Defense Department, going back into the ’60s at least, as now given in MIL HDBK 881A, now in its upteenth upgrade and reprinting. PMI is a very late comer to the ‘definition’ game. DoD has always defined the WBS in terms of the product of the work, not the work itself. The 881A definition is: “A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item. ” You can read all about it at

But really, I think all the controversy can be reduced to one word: "Microsoft".

Microsoft can be blamed for everything.  Microsoft beget MSProject, and MSProject captured the market for an inexpensive and easy to use scheduling tool decades ago. Being mostly a database of tables and fields, with some application code written around it, MSProject allows the user to expose certain fields that have a built-in data definition. One of these fields is entitled "WBS".

Verbs, nouns, and narrative
However, schedules are the world of 'verbs': actions that are to be scheduled. The WBS, on the other hand, is the world of the 'nouns', things that are memorials to completed actions.

The project 'narrative' is just the verbs from the schedule put into sentences where the nouns from the WBS are the objects of the verbs [hopefully, everyone recalls sentence diagramming from the 5th grade]

Application smarts
MSProject's application is not smart enough to distinguish between the 'nouns' and the 'verbs'. So, even if you have been diligent by making the summary row a noun with the subordinate rows containing the scheduled verbs, when the WBS column is exposed all records [rows] in the database [schedule] acquire a WBS number in an indentured and sequential order. The numbering is part of the application functionality.

So, naturally there is a confusion between schedule and WBS if you do not give the field [aka 'column' in the application] a user-defined 'title'. I like 'index', as shown in the figure below, but pick your own. Caution: do not rename the 'field name' since the field name is sacrosanct in the database.

 Bookmark this on Delicious
Are you on LinkedIn?    Share this article with your network by clicking on the link.


  1. Even without the DoD credentials, the "product of the work" is more useful than what amounts to a schedule template. I think that a lot of people use the terms "SDLC" and "WBS" interchangeably. The important thing to remember is that a WBS is a scope artifact, not a schedule artifact.

    I have posted more about this on my blog: Work Breakdown Structures are Useful if done Right

  2. Bruce: your point is well taken. In my mind the gold standard on WBS is MIL 881A, and in it's section on WBS Exclusions, it reinforces your point: Guidance for WBS Element Exclusions

    Program acquisition phases (e.g., SDD, Production and Deployment), and types of funds used in various phases (e.g., Research, Development, Test and Evaluation) are inappropriate WBS elements.