Value breakdown structure

Goal

The PMBOK Guide defines the value breakdown structure as a hierarchical structure that links the project scope and its expected value to the product scope that generates that value (§2.2.1). Its Section 5 describes it as a WBS in which each element carries an estimate of value.

A WBS states what the project produces and what each part costs. It does not state what each part earns. Without that figure the team knows neither which deliverable to sacrifice when the budget runs short nor what a week saved is worth. This observation was the starting point of Stephen Devaux's method. For him a project is an investment. Traditional project management tracks the sum invested and leaves aside the value that this sum is meant to produce.

With the value breakdown structure, the sponsor and the team decide which elements are mandatory, which optional elements are worth their cost and what accelerating an element on the critical path earns. The technique produces a tree of deliverables in which each node carries a status (mandatory or optional) and an added value. According to the PMBOK Guide, the team decomposes each leaf of this tree through the WBS. The guide prescribes no form for this link. A traceability matrix documents it: it ties each leaf to the work packages that produce it.

Usage

When to use it

• Benefits already quantified: the business case gives a value in francs or in measurable units that can be carried down to the deliverables.
• A budget or deadline that forces cuts: sort the scope on the value of each element.
• Value that depends on the date: put a figure on a week of delay when the project targets a seasonal launch, a regulatory deadline or savings that start at go-live.
• A trade-off on the critical path: decide whether to pay to accelerate a critical activity or to remove it from scope.
• A project that a programme depends on: each week of delay on this project delays the value of the whole programme.
• A fixed-price supplier on the critical path: calculate the early-completion bonus to write into the contract.

When not to use it

• No quantified value from the sponsor: values that the team estimates alone produce false precision; prioritise with MoSCoW (see prioritisation).
• Scope entirely imposed: nothing to trade off; put a figure on time with critical path drag.
• Adaptive approach without a WBS: the product backlog ordered by value plays this role at each iteration.

Description

The elements

The node is a deliverable or a sub-deliverable. It is named as an outcome ("Online invoice submission") rather than as an activity ("Develop the submission module"). The top level gathers the major deliverables that the stakeholders have discussed and agreed together (PMBOK Guide, §2.2.1).

The added value estimates what the element brings to the project. The PMBOK Guide allows two forms: a number in the project's unit of value or a percentage of its total expected value. A company counts in revenue or savings. The guide also cites children who learn to read and lives saved.

The status classifies the element. A mandatory element is one without which the project loses its purpose and its value. Devaux puts an element that the law or an internal rule imposes in the same class. Its added value equals that of the whole project, which the PMBOK Guide writes as 100%. An optional element adds value without being indispensable. Its value is the difference between what the project is worth with it and what it is worth without it.

Devaux shows this on a house. Without a bathroom the house gets no occupancy permit and is worth nothing: the first bathroom is mandatory and carries the house's 200'000 dollars (100%). The second bathroom is worth 40'000 dollars: the difference in sale price between a house with one bathroom and a house with two.

Devaux starts from the MoSCoW method. Must becomes mandatory. Should and Could become optional and receive a quantified value. Won't stays out of scope.

Value does not add up

In a WBS the cost of a parent equals the sum of its children's costs. Value does not follow this rule. The two wings of a small aircraft that sells for 100'000 dollars are both mandatory and each is worth 100'000 dollars. The pair of wings is still not worth 200'000 dollars. Two elements can also overlap: the value of the two together then stays below the sum of the two. They can instead reinforce each other and exceed it.

A health insurer builds an online reimbursement portal. The portal's business case puts the savings at CHF 23'000 per week of operation: CHF 5'980'000 over five years.

The children's costs make up the parent's CHF 300'000. Their values total CHF 6'240'000 and exceed the parent's value. A value total calculated by rolling up the tree is therefore wrong. The team estimates the value of the parent itself with the sponsor.

Building the structure

1. Gather the major deliverables. The stakeholders discuss them and agree them together. They form the top level (PMBOK Guide, §2.2.1). They come from the business case, the project charter or the scope statement.
2. Classify each deliverable with the sponsor. Section 5 of the PMBOK Guide gives the test: an element is mandatory if removing it wipes out the project's value.
3. Estimate the added value. A mandatory element receives 100%. An optional element receives the difference in value with and without it. The sponsor, the customer or the investor supplies these figures. The analyst attaches them to the deliverables.
4. Decompose. The team divides each deliverable into sub-deliverables and gives them a status and a value under the same rules. Decomposition stops when each optional element forms a separate decision. In the kitchen of his house, Devaux separates a mandatory sink from an optional dishwasher.
5. Link to the work packages. Each leaf decomposes through the WBS into work packages and activities (PMBOK Guide, §2.2.1). Functional decomposition describes this WBS and its rules.
6. Weigh value against cost. An optional element stays in scope if its value exceeds its cost. The team judges the mandatory scope as a block. The total expected value already counts all the options. If the cost of the mandatory scope exceeds it, no choice of options makes the project pay.
7. Price the critical path. For each element on the critical path, estimate its drag cost and compare it with the cost of accelerating or removing the element.
8. Revise. Rework the values when the business case changes or when the go-live date slips.

Drag cost on the critical path

A project's value often depends on its date. Devaux takes the example of a remote-controlled snow blower. If it is in the shops three days before the first storm of the winter, it is expected to earn 25 million dollars. Each week of delay takes 10% off those sales.

Section 5 of the PMBOK Guide defines two terms that put a figure on this sensitivity. Critical path drag is the time that a critical activity adds to the project's duration. It is read from the network of the critical path method. Drag cost is the drop in the project's expected return that this drag causes. The team estimates this cost for each element on the critical path from the added values in the structure (§2.2.1).

For an element on the critical path, Section 5 suggests checking whether another plan earns more: accelerating or removing the element can earn more than the acceleration or the removal costs.

Drag cost alone decides nothing. Removing automatic reading brings go-live forward by four weeks but loses more value than it gains.

A project on which a whole programme depends carries that programme's value. In one of Devaux's examples, a bridge gives the only access to the building site of a hotel complex expected to earn 3.5 million dollars a week. Each week saved on the bridge is worth that amount. If a contractor builds the bridge at a fixed price, Devaux recommends writing a substantial bonus for each week of early completion into the contract.

Pitfalls

Adding up the values. The sum of the nodes soon exceeds the project's value and can reach several times that value. A spreadsheet that rolls values up like costs produces a total that nobody should read. The check: no sum formula in the value column.

Letting the team invent the values. Devaux observes that the expected value almost never reaches the project manager and the team, even when management or the sponsor has quantified it. A team that fills this gap builds the tree on its own assumptions. The figures come from the sponsor, the customer or the investor. A value that does not come from them carries its author's name and the label "assumption".

Declaring everything mandatory. Each stakeholder defends their own deliverable. A tree with no optional element adds nothing to the WBS. The Section 5 test settles it: if the project keeps its value without the element, the element is optional.

Confusing value with cost. A team that takes an element's cost as its value can no longer tell the options apart: each one is worth exactly what it costs. Value is measured from the point of view of the user or the sponsor: revenue, savings, risk avoided.

Stopping above the WBS. A structure that does not reach the work packages does not steer the work. A work package that no valued leaf justifies adds cost without adding value. The traceability matrix exposes this gold plating.

AI considerations

A language model drafts a first tree from a WBS, a charter or a business case. It rewrites activities as deliverables. It compares the structure with the WBS to list the work packages that have no valued leaf. It finds the spreadsheet formulas that add up values. It writes the formulas that recalculate the drag costs and the trade-offs; the spreadsheet does the calculation. For each optional element it prepares the questions to put to the sponsor.

The values remain the sponsor's business. A model produces plausible figures that nobody has taken responsibility for supplying. Mandatory status belongs to the same decision. The business case figures are confidential. At a health insurer the claims data concern health: the revised Federal Act on Data Protection (nFADP) classes them as sensitive personal data (Art. 5 let. c). These figures and data go to a hosted service only within the framework that the organisation has set.

Examples

In the health insurer's portal, the policyholder submits medical invoices online.

Three mandatory elements each carry CHF 5'980'000. Automatic invoice reading carries only its increment. Adding up the first-level nodes would give CHF 18'460'000 for a CHF 5'980'000 project.

Visualisations

The traceability matrix ties each leaf of the structure to the work packages in the WBS. The last row shows a package that no leaf justifies.

Cost

Tooling

A spreadsheet is enough for most projects. Each row holds one element with its code, its parent, its status, its added value, its cost and the codes of its work packages. A check column flags any formula that adds up values.

Scheduling software such as MS Project or Primavera P6 holds the value in a custom task field. It calculates the network and the float. It does not calculate drag. The team derives drag by hand from the network (see critical path drag). A diagramming or mind-mapping tool draws the tree for the workshop with the sponsor.

Sources

• Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8th ed., PMI: the definition of the value breakdown structure, its top level, the two forms of added value, the 100% of a mandatory deliverable, its use to prioritise and to estimate drag cost, the decomposition through the WBS (§2.2.1); the VBS as a valued WBS, the test of a mandatory element and the check for another plan that earns more (Section 5, entry "Hierarchical charts"); critical path drag and its cost (Section 5, entries "Critical path drag" and "Critical path drag cost").
• Stephen A. Devaux, "The Value Breakdown Structure (VBS): What, How and Why?", Total Project Control, 3 April 2015: the move from MoSCoW to statuses, mandatory and optional elements, value that does not add up, the examples of the aircraft, the house and the snow blower.
• Stephen A. Devaux, "How to Determine the Expected Value of Those Crucial Enabler Projects!", Total Project Control, 2 July 2015: the project that a programme depends on and the bridge example.
• Stephen A. Devaux, Total Project Control: A Practitioner's Guide to Managing Projects as Investments, 2nd ed., CRC Press, 2015: the full account of the method by its author. He introduced it in the 1st edition in 1999.

Stephen Devaux designed the value breakdown structure and remains its only detailed source. The PMBOK Guide covers it in two paragraphs.