How Critical is the WBS to Project Scheduling?
What is a Work Breakdown Structure (WBS) anyway
As we've mentioned on these pages before, LinkedIn on the Internet can be an excellent source of serious discussions on various aspects of project management. One such discussion is around the question of how important is the Work Breakdown Structure to managing a project, or project scheduling in particular? Unfortunately, as a discussion drags on, with new people discovering the exchanges, the proverbial waters tend to get rather muddied. So, for the benefit of a wider audience, we thought it worthwhile summarizing the consensus in response to this question about the WBS. We also thank all those who participated in this recent LinkedIn discussion.
For many people, a Work Breakdown Structure (WBS) is such a rudimentary part of a project that to ask: "How critical is the WBS to project scheduling?" seems like a superfluous if not a positively fatuous question. Yet I think that it is at the root of what a project is all about. And that, apparently, is not at all clear in the minds of many people!
So let's start at the beginning. What is a project? OK, never mind the "official, standard" definitions. The contemplation of a project is an intent to produce something useful. That is to say it will achieve some objective by creating something that satisfies a need. That "something" may be "tangible" like anything on two or more wheels that makes it easier for its owner to move things around, or intangible like improving one's stature in one's community as in political machinations. Either way it represents a benefit to the project's owner.
Which ever it is, and interestingly enough, the project is only worth doing in the first place so long as the perceived benefit is greater than the amount of work assumed to be required in the doing of it. We also know intuitively that "work" involves "activity" and that "activity" is the combination of "effort" spent over "time".
In the case of relatively small projects, it is quite possible for the original "objective" to be so simple or so common, like building a dog kennel for instance, that it is easy to be "internalized" in the minds of those who will undertake work. This enables them to jump straight to a list of all the things they need to do - in other words a list of activities. This list is typically generated, whether ostensibly recognized or not, through a "brain storming" session that produces a random list of the required activities expressed by "verbs".
But project management is at least partly about doing things efficiently, so the next step is to organize the random list of activities by reassembling them under a series of suitable headings. These headings are represented by "nouns" and, lo and behold, we suddenly have in our hands a "Work Breakdown Structure"! But notice two things here: This WBS listing really is a list of the "work" required, i.e. the activities represented by verbs. However, if we remove from this listing all the items represented by verbs, what we have left is just a list of the headings represented by nouns. In other words what we have left is just a "product" breakdown structure, or "PBS".
So, what have we learned? We have learned that it is OK to have both nouns and verbs in a WBS and that a WBS, by definition implies both effort and time. Hence the next logical step is to organize the work (activities) into an effective sequence that recognizes the relationships (dependencies) between them and exercise all the related techniques of scheduling such as resourcing, and time and cost estimating.
Dog kennels aside, what about a serious project?
However, (there is always a "however!) on much larger projects it is no longer possible to internalize the extent of the project objectives in one's mind without breaking down the product into "convenient chunks". These chunks are typically called work packages (WPs). Remember, according to George Miller, the average person can only handle seven things in their mind at a time, plus or minus two.[1] Incidentally, that means that a "large project" is any project that has more than nine components (nouns) in its structure.
Moreover, the larger the project, the more WPs there are likely to be and the more detail it is advantageous to store in the description of each one. Which is why, for practical graphical display purposes, we assign a system of reference numbering and have a "WBS Dictionary" that defines each WP. What does, or should, the graphical display look like? Well, all the parts are essential, but how you arrange them depends on the project and the project manager's preference. However, the results usually look like some form of family tree. As to presentation, that too, is a matter of preference to suit the circumstances. It could be black board, white board, electronic, or just plain old bits of paper.
For example, suppose you are a cabinetmaker and you are making a cabinet consisting of several parts. You would probably lay out all the required materials on your workbench before you start. Where you actually put them will be according to your personal preference, but the first thing you will want to check is to account for all of the cabinet's components. And then you want to make sure that you have everything you need for this cabinet building project.
So, in such cases, that is by far the majority of projects, it makes sense to start with the breaking down of the end product, in other words a "PBS", and work backwards to the work involved. It is just unfortunate that we have all slipped into the lazy habit of calling this a "WBS". But who cares what's in a name, in the end it all amounts to the same thing.
So to answer the original question: How critical is the WBS to project scheduling? For effective and efficient project management, and certainly for projects of more than nine components, a so-called "WBS" is both fundamental and essential. That is, if the work is going to be scheduled so that it can be carried out in some logical sequence at minimum effort, i.e. minimum waste. In that case, the WBS is not only absolutely critical, but the work of creating it is also of highest value.
1. See my previous musing A New Project Management Standard? for more details.
|
