Rethinking the (Work) Breakdown Structure – Part 2.1: Cleaning up the narrative

by | Aug 29, 2021 | Breakdown Structures | 0 comments

In the last post, we summarised three pivot points central to our mission to rethink and reframe the Breakdown Structure.

In this post, we look at the first pivot point in more detail: To have better WBS’s, we need to pivot towards a unified, precise and repeatable set of guidelines.

Below I unpack this assertion in three separate but related points.

  1. The WBS is about work.
  2. Overloading the term work is confusing.
  3. Does “Deliverables-oriented” actually mean anything useful?

The WBS is about work – it’s not about tasks or deliverables

Let’s forget the debate between a “task” orientation and a “deliverables” orientation for a moment. Let’s ask ourselves: “What is the purpose of the WBS?”

The answer: It is a container for describing and categorising work. The often-quoted “100% Rule” says that the WBS needs to contain all the work in the project. I do not doubt that it can contain all the work in a categorised view – all the work we know about at any given time in the project.

The narrative still debates the change from “task-oriented” to “deliverables-oriented”. This almost obsessive focus detracts from its primary purpose of categorising work from different perspectives.

It seems like this transition from “activity” to “deliverables” was never really completed. As we will see next section, the result was the wrong solution to the correct problem statement.

Some 20 years later, many parts of the narrative still refer to tasks and deliverables (even though they say otherwise) or have handled the transition in a very clumsy way. These confusing and mixed references do little to help practitioners.

Not surprisingly, the use and application of breakdown structures is a bit of a “cottage industry” with differing practices and a multiplicity of breakdown structure types – 23 at my last count – that have evolved out of the practitioner community.

A WBS hierarchy is a tree, and so any values that a tree holds at any level are entirely defined by the values at the lowest level nodes – the “leaf-nodes”. Leaf nodes are the nodes in a tree that don’t have children of their own.

See the diagram below for a summary of tree-structure basics.

In a WBS, the leaf nodes contain estimates of work (duration or actual work units). Parent nodes do not have independently set values but aggregate all their descendants.

Every level of aggregation above the leaves has the same unit of measure in its sum as the original leaves, e.g. work hours.

Regardless of the label, the contents of the node in a WBS describe work.

Redefining the term “work” creates confusion.

In transitioning from a task/activity focus in the WBS in the 1980s to a deliverables orientation, the PMI decided to redefine the term “work”.

I don’t know the history and wasn’t there. If I read between the lines, I can make some guesses.

It seems that the PMI already had a great deal of material written (hundreds of pages) that referred to “work” as an activity, which would need rewriting. So perhaps an easy (quick and dirty) solution was to redefine the term “work” in one place and expect their readers to reprocess the term wherever else they found it. This technique is common in legal contracts but not everyday narrative texts.

This approach made things worse, not better.

This “solution” creates an overload of the term “work”. “Work” now has two very distinct senses. One sense is “activity or task”. The other (now) is the ” output of that activity”.

What may have appeared to be a simpler alternative to rewriting hundreds of pages of material, but it just doesn’t fly.

Overloading the term “Work” gives two different meanings and creates a knock-on definitional conflict.

There are two primary problems with this approach:

  1. Using “work” in the sense of “output” doesn’t work in English without linguistic scaffolding. An “article” (e.g. “a” or “the”) must come before the word “work”. When we refer to a thing, we say “a work” or “the work”. When we talk about multiple items, we say “the works”. In English, “work” on its own always strongly indicates the sense of activity. I’m not picky about grammar; it is about comprehension.
  2. There’s already a perfect term that we use to describe the output of an activity, and that is “deliverable”. The overloading of the word “work” gives us two meanings to understand in the one word: “work” in the deliverable sense and “deliverable” in the deliverable sense. Both words are used freely across the guidelines and definitions of WBS and how to create one.

Let’s roll back the term “work” to a single sense – meaning “activity or task”. If we want to refer to the output of a task, I’m happy to use the term “deliverable”.

Does “Deliverables-oriented” actually mean anything useful?

The narrative of the WBS since 1993 is that it is “deliverables-oriented”, which is a statement that is both vague and inaccurate.

We’ll cover the topic of what we are breaking down next post, but as a teaser, let’s say that we can’t break down deliverables because they have no intrinsic structure.

Nothing in the WBS narrative describes how to break down a deliverable in any precise or repeatable way.

But leaving that aside, any guidance written as “xxx-oriented” is hardly precise.

This fact is evident from the many commentators and practitioners who interpret it differently. Some take it literally to mean only deliverables are in the breakdown. Others take a more relaxed approach and say it is OK to use other a mix elements in the breakdown.

Even the guidance that is strictly deliverables only provide examples that include either all activity-based task breakdowns or (at best) a mix, e.g. components like “Integration” or “Project Management” are activities, not deliverables.

So we need to remove such vague phrases as “xxxx-oriented” and provide more precise guidance.

I’ll cover the “stuff” that we’re breaking down in the next post.

The Bottom Line

The bottom line is that we must focus on unambiguous and practical guidelines for breakdown design. These guidelines must provide complete, step-by-step, verifiable, and repeatable instructions that practitioners can use.

We need to be consistent and clear in our language and integrate our definitions across relevant domains.

It’s OK to provide a “toolbox” from which practitioners can draw as they need. It’s another thing altogether to give a mass of conflicting information from which the practitioner needs to parse and extract the relevant rules, tools and techniques.

To have better WBS’s, we need to pivot towards a unified, precise and repeatable set of guidelines.

Sign up for the AOP Newsletter

Each week Adam writes about interesting and varied topics for Project Managers everywhere and curates useful articles, books and papers from other sources.