I've been a bit heavy on theory lately, and it's paying off.

As I push for a theoretical approach (sometimes to what folks consider remedial skills) I am slowly uncovering all those little reasons we are sometimes resistant to the theoretical approaches that we ought to support and execute. One whole area for this investigation is in the creation of a proper work breakdown structure.

For today I have a single, narrow topic: why it is that we must focus on deliverables, not tasks, in our WBS, and why it is we resist doing so. I'll assume you are with me that far. That you know full well what a WBS is supposed to be, and also see all around you the eagerness of the human brain (even one finely honed by constant adherence to PMI guidelines) to jump into life-cycle, methodology, whaddawee-gonnadoo-next approaches to work.

The seeds of confusion are right there in the name: "work" breakdown. Brewing is work; beer isn't. Baking is work; pretzels aren't. So in a work breakdown we are breaking down the tasks, not the deliverable. Except we aren't. So the WBS right off the bat has a tough name.

Properly, we are breaking down deliverables into ever-smaller component deliverables, and we keep doing so until that gets silly. We are then allocating work to the ends of the deliverable breakdown. Deliverable-breakdown-until-silly-and-work-allocation structure, the DBUSAWAS, would never have caught on, though, so we have to work a little harder to explain ourselves and use the tool correctly with the name it has.

Here are two arguments I am getting in resistance to a deliverable focus in a WBS. They come up when we insist upon including internal project deliverables like ‘Test Report' and ‘Requirements Documents' on level 1 of the WBS. My replies are ones I think answer the objections well, and are instructive as we seek to explain ourselves and push for excellence with non-technical or skeptical peers.

Argument 1 (in response to 'Test Report' on Level 1 of a WBS, instead of 'Testing'): "This is putting the cart before the horse, or something. We don't test to create a test report: we test to increase quality and reduce risk. Focusing on the test report is taking your eye off the ball."

Oh, be honest. If you could deliver an exciting and valuable new technology in two days with a staff of three, doing almost nothing in that time, you would do it, right? You don't spend 2,000 hours on a job because the tasks are ones you find fulfilling. Absolutely none of the tasks we do in a project are for their own sake. They are always and forever for the deliverable. When we aren't working for a deliverable it is time to go home. We take our eye off the ball when we do any task that isn't necessary to a deliverable. Make a note to read this paragraph again when you are done: we don't want work, or tasks, or schedules; we want deliverables. (We don't want brewing; we want beer.)

An accurate test report stands on its own because it reflects the outcome of testing. That is why it is a standard and required project deliverable. Undocumented testing doesn't stand on its own, even though it has value. So really, now, isn't it letting the tail wag the dog to focus on activities rather than the essential deliverable they make necessary?

Argument 2 (in response to 'Requirements Documents' on Level 1 of a WBS, instead of 'Gather Requirements'): "I already know, for instance, that I need requirements. Writing down nouns tells me absolutely nothing new. It is when we identify the necessary tasks that we are learning something."

Taken to an extreme, you could begin designing a new jetliner for Boeing by asking "What should we do first, ladies and gentlemen? And what next?" Could that even possibly end well? Of course not. And we wouldn't dream of it (find the pun).

When thinking of a large, physical delivery it becomes obvious that you must focus on the deliverables, and break them down into ever-smaller component deliverables, before ever getting to a verb. But in tech deliveries, or less exotic deliveries we think we understand, we have little patience for the breakdown part of a WBS, and eagerly anticipate giving in to our instinctive desire to think in terms of tasks and life-cycles. Because we are smart and know what to do – or something.

And let's be honest about that task focus that comes so easy to us. Even cave people – who were rarely PMP certified, though some were probably lawyers – thought through and even planned their tasks. It's visceral to do so. It is more advanced to break down the deliverable (roasted mammoth steak) into its component and ancillary required deliverables.

It is when you get all those necessary pieces listed out and broken down that you can validate your action list. And this approach helps you exclude unnecessary tasks from your day, reducing the calories you have to kill. With a noun-based WBS you won't end up with raw mammoth, or without a safe cave in which to enjoy your meal.

Theory works. So whaddawee-gonnadoo-next?