A look into Work Breakdown Structures (WBS)

At the very end of my last article I promised that I would return to earned value in this article, but alas I must fall a bit short on that promise. After giving it a some thought I felt that the subject of earned value deserved more space than could reasonably be given within a single article. Why not make the article longer, the astute reader might wonder. The reason is that I have a self-imposed 1,000 word limit for my entries, since I am hard pressed to believe anyone can maintain interest beyond that. Even for a subject as interesting as financial- and project-controlling

Therefore I will use my next three articles to discuss earned value. This article will concern itself with what I feel is the basis for all proper project management; work breakdown structures (abbreviated as WBS).

All projects contain, at their very core, a number of tasks that needs to be executed, or goals that need to be achieved, for the project to be seen as a success. For simpler projects, it might be enough with a list of activities. For more complex projects, I have found them to benefit greatly from a hierarchy where the tasks need to be completed are broken down into small packages of work to be delivered. A fairly simple example (that could definitely be completed with merely a list of activities) is the creation of a new bicycle.

First we will list the overall outcome that is desired (level 0). Then we will list the results that needs to be reached to complete that output (level 1). The we break those results, or outputs, down into a new subset of goals (level 2). We will continue to break these down until they are as small as is reasonable. To give an example, it would look like this when expressed graphically:

If we look closer at the box called design, then we could break that down further like this:

This should, of course, be done for all activities on any given level, until we've reached a level where breaking them down any further wouldn't make sense¹. This should give you a hierarchy, or pyramid, with the goal of the project at the very top.

The advantages of doing it this way are straight forward; you get a way to track all the activities needed to complete the project, and an understanding of how they relate to the overall goal. Furthermore, I feel that any controlling done using earned value has no real value, unless based on a work breakdown structure or, at the very least, a list of activities.

There are a few important rules and reminders to take into account when using a hierarchy like this for a project. The first one is the “100% rule”; all of the project scope must be included in the structure. If it isn't then the breakdown structure will not give you a complete overview of the activities, and there is a very real danger, that these activities will not be follow-up upon.

The second rule is the “rule of mutually exclusive elements”. Behind this rather wordy rule is the simple idea that all the elements must have unique content, understood in the way that no task or activity may appear in more than one package in any given level of the hierarchy.

The third rule is more of a reminder than a rule per se. When defining the WBS, you should define goals or outcomes and not the actions needed to reach them. The WBS should serve as a structure and hierarchy for the goals you need to accomplish. If you define the tasks needed instead of the goals, you end up with a structure that needs to be amended and changed frequently, as new tasks needed to complete the projects pop up all the time. There is also a risk of forgetting some tasks all together.

The fourth rule is the “rule of bottom level input”. This should be understood in the way that you should always report at the WBS packages at the bottom level. No registration should occur at any level with a lower number than the bottom level. This is closely tied with the fifth rule (which is more of a guideline), “same level input”; you should always strive for the work packages (where input is to be given) to be at the same level. The reason I include this is that, even though it is strictly not necessary, I have found that people often report on other levels than the bottom, if it not the same for all work packages. Also when it comes to ERP systems, they often have even more problems keeping track of data and proper reporting, if it is not the same bottom level. One could easily imagine a project where the work needed to complete two different level 1 tasks would be of vastly different scope. This would mean that if the work packages at the bottom level should contain roughly the same amount of work (which is a good idea) then they would end up with a different bottom level. This can be solved easily with a structure like this:

As you can see the rightmost work package at the lowest level is exactly the same as the one above. There is nothing wrong with this, it is merely implemented as to have the same bottom level for all work packages.

Why a WBS is so important when it comes to earned value should, hopefully, be very obvious in my next article, which will be on earned value in projects with a low degree of complexity.

1There are different rules for when this has been reached. One that I have come across more than once is the ”80 hour rule”. A goal shouldn't be broken down further than units that would take roughly 80 hours to complete. I have found that it is normally fairly easy to see when it doesn't add any value to break down tasks any further.