The Value Breakdown Structure (VBS): What, How and Why?

My recent blog articles have mentioned the value breakdown structure (VBS), with a link to the Wikipedia description. Now several people have asked me expand on this concept: what does it look like, how to create one, and why is it a valuable tool?

To get across the concept, I’ve created the abbreviated VBS below for a project to build a small house. Please note that this is not intended to be a complete or comprehensive VBS – it is merely a sample designed to give a sense of the VBS structure, with certain branches (BEDROOMS, BATHROOMS) decomposed more than others. (Ultimately, the other elements should also be decomposed to reveal optional items: KITCHEN, for instance, might include an optional dishwasher and garbage disposal, as well as a mandatory sink.)

VBS for House

The VBS is a technique that I have implemented from time to time in my consulting career. I then introduced the idea in my 1999 book Total Project Control. Although I regularly taught the concept in my corporate classes, up until a couple of years ago I had assumed that the idea had not “caught on”. Then about three years ago I did a Google search on the term and discovered, to my delight, that it was being applied in several countries in Europe and the Middle East!

The most thorough description of the VBS and its application is in the second edition of my first book just out from CRC Press this week: Total Project Control: A Practitioner’s Guide to Managing Projects as Investments. I would urge anyone who finds the concept interesting to read the chapter on developing the WBS and the VBS in that book. However, let me try here to provide a thumbnail sketch of the concept.      

First, as my books stipulate, all projects and programs are investments and must be managed as such. One part of any investment is the money (and on a project, effort and time) that must be invested. In general, traditional project management does a pretty good job of this.

However, the other side of an investment is the value that the invested money is supposed to generate (which, after all, is the whole purpose of the investment!). That side of the equation is almost totally ignored. Even in cases where senior management, or the sponsor/customer, or the manager of the program of which the project is a part, has performed value analysis and has quantified the project’s expected value, that specific information is almost never passed along to the project manager and team. Yet those are the people who can really use that information to maximize the project value.

In my two previous blog articles, I have made the case that all levels of management engaged in project work have a specific role to play. The customer/sponsor and/or the program manager must ensure that the project they are funding will generate the benefits/value they want.

The business value of a project is generated by its scope, primarily the product scope. This value is then almost always impacted by the completion date. If our remote-controlled snowblower is in the stores by the three days before the first snowstorm of winter, we estimate that our sales revenues for the winter will total $25 million. However, for every week later, we anticipate a drop in revenue of 10%. Ten weeks later, our potential customers will be looking to purchase lawnmowers, not snowblowers. Although they are rarely given such information, the expected value of the scope and the value/cost of time are two crucial data items for every project team in achieving what should be their goal – to maximize the value to the investor(s).

Traditional project management loads the resource costs for program and project into the elements of the work breakdown structure and sums them to the top to create both the budget and the earned value baseline for each summary element and for the whole project and program. But the project’s expected value, even if estimated, is never tied to the specific program projects, products, work packages and work elements of scope that will generate it. Yet this is the very tool that allows the sponsor/customer/program manager to collaborate with the project manager and team to:

  1. Ensure that scope elements that will generate the desired benefits/value are clearly specified;
  2. Measure their expected contributions; and
  3. Make sure they are not actually costing more than the value they are adding (a key consideration related to the computation of the true cost of work, which I will explore in a later blog article).

The whole concept of establishing and prioritizing scope items based on their importance to the sponsor customer is not entirely new. There is in fact a technique (sometimes used in agile methodologies) called the MoSCoW method, where:

  • M stands for Must;
  • S stands for Should;
  • C stands for Could; and
  • W stands for Won’t.

The MoSCow method is an excellent place to start; but then the prioritization information should be quantified, in terms of the value that each scope item is adding, and assembled into a VBS.

When this is done, Must equates to mandatory scope – elements that must be included either because the project would make no sense without them, would have no value without them, or scope that is mandated by law or internal regulation. Mandatory scope items have a value-added equal to that of the entire project – without these items, the project has not been performed!

Should and Could equate to optional scope items – they don’t have to be included, but they will add some value. Whether or not they are included should depend on their value versus their cost.

As the house VBS above shows, value behaves differently from cost. Whereas cost is always additive (the sum of the costs of five detail activities ALWAYS is equal to the dollar cost of their parent summary activity), value is not. The value of two activities may be more than the sum of each, i.e., they may either duplicate some of the other’s value or kindle each other’s value. For example, on a small airplane that is expected to be sold for $100,000, although both the left wing and the right wing are mandatory and therefore each has a value-added of $100,000, the value-added of “wings” is NOT $200,000 – value just works differently than cost.

In looking back at that house project VBS, notice that the value-added of each of the two bathrooms is $200,000 for the first and $40,000 for the second. In other words, until the house has a bathroom it will not get an occupancy permit and it will basically have zero value. So the first bathroom is mandatory and therefore has a value-added equal to 100% of the value of the project. But the second bathroom is optional, with a value equal only to the difference between what we could expect to sell it for with one bathroom versus with two. Please note that it is not intended to be a complete or comprehensive VBS – it is merely a sample designed to give a sense of the VBS structure, with certain branches (BEDROOMS, BATHROOMS) decomposed more than others. (Ultimately, the other elements should also be decomposed to reveal optional items: KITCHEN, for instance, might include an optional dishwasher and garbage disposal, as well as a mandatory sink.)

As I expect to show in a future article, optional activities are actually the ones that allow opportunities for decision-making and optimizing of the project investment.

Are you finding the VBS topic interesting? If so, please consider indicating this fact to me by selecting the appropriate option in the embedded poll below.

Fraternally in project management,

Steve the Bajan

2 thoughts on “The Value Breakdown Structure (VBS): What, How and Why?

    • Hi, Dan.

      The detailed answer to your question is complex. In a nutshell, every project is an investment. In any investment, we want to make sure we are not investing more than something is worth. In simplest terms, we’d never want to pay a salesperson $20 for every widget of ours that they sell if the price of the widget is just $15. In the same way, we want to make sure that we don’t include work on any project that costs more than its worth.

      The VBS, at start, is a way of prioritizing the components and work of the project. As mentioned in the article, it extends the agile technique of MoSCoW (Must, Should, Could, Won’t) by generating estimates of the value-added of each work package or task. Mandatory is Must, and is worth the entire expected value of the project investment. If you eliminate a mandatory activity, the project will have no value and should be cancelled. All other components/work is optional, and could be eliminated if its cost is too high. Therefore it is important to know what the expected value-added is, a process that should always be performed in close communication with the sponsor/customer/investor.

      The other side to this process is close oversight of the true cost of each component/task. True cost = drag cost plus resource costs. The blog article shows how low value work that makes sense if its off the critical path and therefore has zero drag cost can become a net loss if it migrates to the critical path and takes on drag and drag cost. You would not want to include work on your project that adds $50,000 of value but that requires $15,000 of resources AND delays project completion by two weeks, each at a delay cost of $20,000.

      If you want to learn more about this, I’d suggest reading my two books Managing Projects as Investments: Earned Value to Business Value and Total Project Control: A Practitioner’s Guide to Managing Projects as Investments.

      Good luck.

      Fraternally in project management,

      Steve the Bajan


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s