Product-based planning I: product breakdown structures and product descriptions

Product-based planning is the technique at the centre of PRINCE2 planning and the practical expression of the principle of focusing on products. Instead of starting with a list of tasks, the planner starts by defining what the project must deliver, breaks it down into its component products, describes each product and its quality criteria, and only then works out the order in which products must be created and the activities needed to create them. PRIN-110 explained why the focus on products matters. This lesson and the next show how to do it.

PRINCE2 describes product-based planning in four main steps: write the project product description; create the product breakdown structure; write product descriptions; and create the product flow diagram. This lesson covers the first three. Lesson 9 covers the product flow diagram and how it leads to a schedule.

Why start with products

Planning from products has several advantages over planning from activities. It reduces the risk of missing work, because every product must be identified and every product needs activities. It clarifies scope, because what is in the product breakdown is in scope and what is not is out. It makes quality explicit, because every product has a description with quality criteria. And it helps communication, because users and sponsors understand products such as a customer portal or a trained team far more readily than lists of tasks.

The project product description

The project product description describes the final product the project will deliver: the overall output that the users will accept at the end. It is written during starting up a project, usually by the project manager with the senior user and executive, and it is part of the project brief. It records the purpose of the final product, its composition, the customer's quality expectations, the acceptance criteria and how acceptance will be confirmed, and the project-level quality tolerances. It is the starting point for the product breakdown and the basis on which the project will be closed.

Customer quality expectations and acceptance criteria are not the same. Expectations are what the customer wants, often in general terms; acceptance criteria are measurable conditions that, if met, mean the customer will accept the product. Turning expectations into criteria is one of the most valuable conversations in starting up a project, because disagreements discovered now are cheap to resolve.

The product breakdown structure

A product breakdown structure (PBS) is a hierarchy of all the products the plan must produce. At the top is the final product from the project product description. Below it are major products, and below those their components, down to a level suitable for the plan. A PBS can be drawn as a tree, written as an indented list or held in a planning tool. PRINCE2 encourages including management products as well as specialist products, so that the plan accounts for the effort of producing them, and including external products, which the project needs but does not create.

Conventions vary, but a common one is to draw specialist products as rectangles, external products as ellipses and intermediate groupings, which are not real products but help organize the structure, in a different style. The important thing is that the PBS includes everything that must be produced or obtained, and nothing else. Each box at the lowest level should be a product that can be described, built and checked.

External products deserve special attention. Ridgeline Water depends on a radio spectrum authorization from Innovation, Science and Economic Development Canada for its meter network, and on the existing billing system, which the project does not own. Neither is in the project's control, so each should appear in the PBS and in the risk register, with an owner who will monitor it.

Building a PBS step by step

A practical way to build a PBS is to work with the people who know the products: users, suppliers and specialists. Start with the final product, ask what it is made of, and keep asking until each product is small enough to estimate and check. Then walk through the structure looking for gaps: training, documentation, data migration, handover and decommissioning of old systems are often forgotten. The code below holds part of Ridgeline Water's PBS as a nested structure and lists the lowest-level products, which are the ones that will need product descriptions and activities.

pbs = {
    "Operational smart-metering service": {
        "Installed meters": {"Pilot district meters": {}, "Rollout district meters": {},
                             "Meter supply contract (external)": {}},
        "Network and data platform": {"Radio network": {}, "Head-end system": {}, "Data platform": {}},
        "Billing integration": {"Billing interface": {}, "Migrated meter records": {}},
        "Customer change": {"Alert design": {}, "Customer communications": {}, "Follow-up process": {}},
        "Operational readiness": {"Trained staff": {}, "Updated procedures": {},
                                  "Decommissioned reading routes": {}},
    }
}

def leaves(tree, path=()):
    for name, sub in tree.items():
        if sub:
            yield from leaves(sub, path + (name,))
        else:
            yield path + (name,)

items = list(leaves(pbs))
external = [p for p in items if "(external)" in p[-1]]
print(f"{len(items)} lowest-level products, {len(external)} external")
for p in items:
    print("  " + " > ".join(p[1:]))

14 lowest-level products, 1 external
  Installed meters > Pilot district meters
  Installed meters > Rollout district meters
  Installed meters > Meter supply contract (external)
  Network and data platform > Radio network
  Network and data platform > Head-end system
  Network and data platform > Data platform
  Billing integration > Billing interface
  Billing integration > Migrated meter records
  Customer change > Alert design
  Customer change > Customer communications
  Customer change > Follow-up process
  Operational readiness > Trained staff
  Operational readiness > Updated procedures
  Operational readiness > Decommissioned reading routes

The listing shows fourteen lowest-level products, one of them external. Note that decommissioned reading routes appears as a product. Ending the old way of working is part of the change, and if it is not planned as a product, the old routes may continue running alongside the new system, eroding the reading-cost benefit in the business case. A PBS that includes the ending of old processes is a sign that the planner has connected the plan to the benefits.

Product descriptions

A product description is written for each significant product in the PBS. It records the product's purpose, composition, derivation (what it is developed from), format and presentation, the development skills required, the quality criteria and tolerances, the quality method, and the people responsible for producing, reviewing and approving it. Product descriptions are written early, when the product is planned, so that everyone knows what is expected before work begins.

Quality criteria are the heart of a product description. They should be measurable, so that a reviewer can say whether the product meets them, and they should trace back to the customer's quality expectations. Vague criteria such as user-friendly or high quality cannot be checked. PRIN-131 covers the quality practice, including quality methods and the quality register; here the point is that product-based planning creates the product descriptions that the quality practice uses.

required = ["purpose", "composition", "derivation", "quality criteria",
            "quality method", "producer", "reviewer", "approver"]
vague = ["user-friendly", "high quality", "robust", "appropriate", "as required"]
descriptions = {
    "Alert design": {"purpose": "x", "composition": "x", "derivation": "x",
                     "quality criteria": "80 % of tested customers understand the action",
                     "quality method": "x", "producer": "x", "reviewer": "x", "approver": "x"},
    "Trained staff": {"purpose": "x", "composition": "x",
                      "quality criteria": "staff are trained to a high quality",
                      "producer": "x", "approver": "x"},
}
for name, d in descriptions.items():
    missing = [f for f in required if f not in d]
    crit = d.get("quality criteria", "")
    fuzzy = [w for w in vague if w in crit.lower()]
    status = "ok" if not missing and not fuzzy else "revise"
    print(f"{name}: {status}")
    if missing:
        print("   missing:", ", ".join(missing))
    if fuzzy:
        print("   vague criteria:", ", ".join(fuzzy))

Alert design: ok
Trained staff: revise
   missing: derivation, quality method, reviewer
   vague criteria: high quality

The trained staff description is missing its derivation, quality method and reviewer, and its only criterion is vague. A better criterion might be that every billing clerk completes the course and passes a practical assessment of handling an exception alert, with a pass mark of 80 %. Simple checks like this are not part of PRINCE2, but they help project support and project assurance catch weak descriptions before work starts.

How much detail

Product descriptions should be proportionate. A major product with many users and high risk deserves a full description; a minor internal product may need only a title, purpose and one or two quality criteria. On agile projects, product descriptions are often lightweight and supplemented by user stories with acceptance criteria. What matters is that, for every product, the people producing, reviewing and approving it agree in advance what good looks like.