Product-Based Planning and Work Packages in PRINCE2 2017

Executive summary

Why plan by products first?

Activity-first planning often begins with a list of things people expect to do: hold workshops, develop a design, configure a system, test, train and deploy. That can produce an attractive schedule while leaving ambiguity about exactly what each activity must produce. Product-based planning reverses the sequence. It identifies the outputs first, defines them sufficiently to agree what “complete” means, and only then determines the activities, dependencies and resources needed to create them.

This is the practical expression of the focus-on-products principle. The schedule becomes a means of delivering agreed products rather than an end in itself. It also strengthens scope control because the scope of a plan is represented by its products and the extent of their requirements. If a proposed activity cannot be traced to a required product, the project can challenge whether the activity is necessary. If a required product has no producing activity, the plan is incomplete.

The supplied material recommends a structured sequence that begins with plan design and product definition, then identifies activities and dependencies, estimates work, prepares the schedule and documents the plan. Risk analysis interacts with these steps rather than occurring only once at the end.

Step 1: design the plan

Before defining products, decide how the plan will be constructed and controlled. Choose the number and likely length of management stages, the delivery approach, relationships with technical stages, the planning and scheduling tools, the format for presentation and any organisational planning standards that must be followed.

This design step avoids an important failure mode: creating detailed schedule data before deciding what management decisions the plan must support. A Project Plan should communicate the major products, stages, timing, cost and resource picture to the Project Board. A Stage Plan needs enough detail for the Project Manager to authorise and monitor Work Packages. A Team Plan may use a specialist format that fits the delivery discipline.

The planning horizon should influence the degree of detail. The current stage can be planned deeply because the team has better information; later stages can remain at product and milestone level until their boundary approaches.

Step 2: define and analyse the products

For the Project Plan, the overall project product is first captured in the Project Product Description. This sets the high-level acceptance basis and provides context for the project approach. The next task is to break the required output into major products and sub-products.

The Product Breakdown Structure (PBS) is a hierarchical view of the products within the plan. The supplied material identifies the PBS as one of the minimum requirements. It should represent deliverables rather than activities. Nouns generally work better than verbs: “approved design” is a product; “designing” is an activity. The structure can be adapted to different delivery approaches; the source notes that agile environments may represent product hierarchy using concepts such as epics and user stories.

Each important product receives a Product Description. At minimum, the source expects purpose, composition, derivation and quality criteria, with the Quality theme adding quality tolerances, methods, skills and responsibilities. These descriptions become a shared contract about what the team must create and what reviewers will evaluate.

Product Flow Diagram and dependencies

A Product Flow Diagram (PFD) converts the hierarchy into a delivery sequence. The PBS answers “what products are in scope?” while the PFD answers “in what dependency order can they be produced?” Products may depend on other project products or on external products supplied by another initiative, operational team or supplier.

The source explicitly labels the Product Flow Diagram as recommended rather than a minimum requirement. This distinction is useful when tailoring. A very small project can use another clear method to represent dependencies, but it still needs to understand them. For a complex project, a PFD is valuable because it can expose missing prerequisites before activity scheduling begins.

When a dependency crosses organisational boundaries, record not just the product name but the required date, expected quality state and owner. An “external approval” shown as a dependency with no responsible party is not a controllable plan. The purpose of the diagram is to make the logic actionable.

From products to activities, estimates and schedule

Once products and dependencies are understood, the planning team identifies the activities needed to create each product. Activities can include production, review, approval, procurement, integration and any enabling work. Because each activity is anchored to a product, the team can test whether all work is necessary and whether every product has sufficient effort allocated.

Estimation then considers effort, duration, resources and cost. Specialist estimates should come from people with delivery knowledge, not solely from the Project Manager. Risk and uncertainty should be considered explicitly. A schedule is then prepared by sequencing activities according to product dependencies, resource constraints and management-stage boundaries.

The final plan should document more than dates. Record assumptions, external dependencies, budgets, tolerances, resource needs, product scope, controls and the narrative required for the intended management audience. The Project Plan will usually stay high level; the current Stage Plan should provide operationally useful detail.

Work Packages: the delivery interface

A Work Package contains the information relevant to the creation of one or more products. The source describes it as including the work description, relevant Product Descriptions, production constraints and an agreement between the Project Manager and the Team Manager or individual who will perform the work.

Work Packages convert a Stage Plan into controlled specialist commitments. Before authorisation, the Project Manager and Team Manager should agree the products, constraints, reporting frequency, tolerance, quality requirements, interfaces and completion expectations. The Team Manager then accepts the Work Package, manages execution and delivers the completed products back to the Project Manager.

Work-package tolerance supports manage by exception. The team manages within agreed limits. If it forecasts that a Work Package cannot be completed within tolerance, the Team Manager raises the issue to the Project Manager rather than independently changing the stage baseline. The Project Manager decides whether corrective action can remain within stage tolerance or whether escalation is required.

A practical product-based planning workshop

Begin with a facilitated session involving people who understand the customer need, specialist solution, quality expectations and delivery constraints. Place the overall project product at the top. Ask “what must exist for this product to be complete?” repeatedly until the team reaches a controllable level of deliverables. Avoid decomposing so far that the PBS becomes a task list.

Write Product Descriptions for the items that need explicit control. Then place products in dependency order and challenge every external input. Only after this should the group brainstorm production and review activities. Estimate using the relevant specialists and build the schedule from the dependency logic. Finally, split near-term work into management stages and Work Packages.

Review the result against the Business Case and acceptance basis. A technically elegant product hierarchy is insufficient if the planned products do not enable the intended outcomes or if the cost and timing no longer justify the investment. Product-based planning is therefore both a delivery technique and a way of testing whether scope is coherent.

Practical verification checklist

• Define the overall project product and acceptance basis before detailed scheduling.
• Build a Product Breakdown Structure using deliverables rather than activities.
• Write Product Descriptions for products requiring explicit control.
• Identify product dependencies and external inputs; use a Product Flow Diagram where it adds clarity.
• Derive activities from products, including review and approval work.
• Obtain estimates from the people who understand specialist delivery.
• Prepare schedules at the right level of detail for project, stage and team control.
• Authorise specialist delivery through clear Work Packages.
• Set Work Package tolerances and reporting expectations before work begins.
• Recheck product scope and plan viability against the Business Case.

Common mistakes to avoid

• Starting with a long activity list before defining outputs.
• Using verbs/tasks in the PBS until it becomes another work-breakdown schedule.
• Leaving Product Descriptions vague and expecting testers to infer acceptance requirements later.
• Treating a Product Flow Diagram as mandatory when the supplied source calls it recommended.
• Authorising work without clear product, quality, tolerance and reporting information.
• Letting a delivery team silently alter scope or dates when Work Package tolerance is forecast to be exceeded.

Related KEVOS handbook pages