PRINCE2 7 Foundation · Study lesson 19
Build a plan from products
Understand what must exist before estimating the work to create it.
9 minute study lesson · Practices · Original learning material
What you will understand
- Explain product-based planning using a simple example.
- Distinguish a product breakdown structure from a product flow diagram.
- Connect product definitions to work packages, estimates and schedules.
The idea
Starting with a task list makes it easy to schedule activity while overlooking an essential result. Product-based planning reverses that habit. First establish what must be delivered, including the evidence that will make it acceptable. Then organise the work, resources and timing needed to produce those results. This reduces omissions without pretending that requirements never evolve.
At project level, the project product description establishes the overall product, its purpose, users’ quality expectations and acceptance arrangements. It helps people agree what successful delivery means. More detailed product descriptions explain individual products, their purpose, composition, relevant quality specifications and how their quality will be checked and approved. These definitions are developed with people who understand both the need and the feasibility of delivery.
A product breakdown structure decomposes the overall result into its constituent products. It is a structured view of what is required, not a timetable or an organisation chart. Products may be physical items, software, services, approved designs or other useful results. Include relevant external products that the project depends on, while making clear that another party creates them. External ownership does not make an essential dependency disappear.
A product flow diagram shows the order and dependencies between products: which outputs are required before another can be completed. It is different from the breakdown structure’s hierarchy. A venue layout may require an approved accessibility assessment before final approval, even if the assessment is supplied externally. Exposing that link makes it possible to ask when the assessment will arrive and what happens if it is delayed.
The planning procedure moves from defining and analysing products to organising work packages, preparing estimates, preparing the schedule and budget, and documenting the plan. Risk analysis runs throughout. Work packages should group related products and work coherently, with clear ownership and interfaces. Estimates need evidence about effort, resources, duration and costs; a delivery date chosen for convenience is not an estimate of what the work will require.
The schedule sequences the work using dependencies and available resources. The budget reflects the authorised scope, required resources and relevant provisions such as agreed risk or change budgets. Document assumptions, monitoring arrangements and constraints so the plan can be challenged and controlled. These activities are iterative: a resource clash may require regrouping work or revisiting a product decision. Product focus provides a reference point for those discussions rather than a prohibition on learning.
Plan from the required result
| Step | Useful output |
|---|---|
| Describe the project’s result | A shared view of the whole product and acceptance. |
| Break down the products | A clear account of what is needed. |
| Describe individual products | Purpose, requirements and checking arrangements. |
| Sequence dependencies | A product flow that informs activities, estimates and schedule. |
An original fictional example
Fictional example: a mobile science exhibition
A university plans a travelling exhibition. A task list says “design, build, transport”, but nobody has identified the approved safety instructions, venue access agreement or transport restraints as required products. The access agreement comes from host schools and is needed before the transport plan can be finalised.
The decision
Add the missing products, describe their approval requirements and show the external access agreement as a predecessor of the transport plan.
Why it makes sense
The team can now estimate and schedule the real work, including coordination and approvals that the initial activity list concealed.
A common confusion
The mistaken idea: A product breakdown structure shows the order in which products will be delivered.
The distinction: The breakdown shows composition. A product flow diagram shows dependencies and sequence, which then inform the delivery schedule.
Breakdown: what belongs. Flow: what depends.
Points to remember
- Define products and quality requirements before assuming the work is understood.
- Identify dependencies on products supplied outside the project.
- Analyse risks throughout planning rather than as a final administrative exercise.
Your takeaway
Product-based planning joins the required results to their creation and approval. Break products down, expose dependencies, organise delivery work and build evidence-based estimates, schedules and budgets around them.
This independently written explanation is supplementary study material. It is not official examination content. Read about our content and its limitations.