Focus on products

The sixth principle states that a PRINCE2 project focuses on the definition and delivery of products, in particular their quality requirements. A product is any input or output, tangible or intangible, that can be described in advance, created and tested. A new building, a trained workforce, a policy document, a software release and a signed contract are all products. Focusing on products means agreeing what will be delivered, and to what standard, before planning the activities to create it. It is the principle that turns a project from a set of busy people into a set of delivered results.

Why products come before activities

Many plans start with a list of tasks. Tasks are easy to list and easy to track: "hold workshops", "write code", "run tests". The trouble is that completing tasks does not guarantee delivering anything useful. A team can hold every planned workshop and still have no agreed requirements. A product focus asks a different first question: what exactly do we need to have at the end, what must it contain, and how will we know it is good enough? Activities are then planned to create those products.

Product focus also makes progress measurable. A task that is "80 % done" is notoriously hard to verify. A product either meets its quality criteria and has been approved, or it has not. PRINCE2 progress reporting is therefore based on products completed and approved, not on effort spent.

Product-based planning

PRINCE2 recommends a product-based planning technique, described in the plans practice. It has four main steps.

1. Write the project product description: what the project as a whole must deliver, its composition, the customer's quality expectations and the acceptance criteria.

2. Create a product breakdown structure: a hierarchy of all the products the plan must deliver, including external products that come from outside the project.

3. Write product descriptions for the significant products: purpose, composition, derivation, format, quality criteria, quality tolerance, quality method and quality responsibilities.

4. Create a product flow diagram: the sequence in which products must be created and their dependencies.

Only after these steps does the planner identify the activities and dependencies needed to create each product, estimate effort and build a schedule. The order is deliberate. If you start with activities, you plan what people will do; if you start with products, you plan what the customer will get.

Counting and checking products

On a small project, product descriptions may be a few lines each. On a large or high-risk project they can be detailed specifications. The principle does not demand a particular level of detail; it demands that the product, and especially its quality criteria, is understood and agreed before the work starts.

Quality criteria and acceptance criteria

Quality criteria describe how a product will be judged. They should be measurable or at least checkable: "the handbook covers all 12 procedures in the policy, has been reviewed by two clinical leads and scores at least 60 on a plain-language readability test" is far better than "a good handbook". Acceptance criteria apply to the project product as a whole and describe what the users and other stakeholders need before they accept the project's output. Typical acceptance criteria cover functionality, performance, reliability, security, usability, maintainability and, increasingly, sustainability.

The quality practice then plans how products will be checked: by inspection, testing, review or audit, and by whom. A quality register records the planned and actual quality activities. Product status accounts, produced through configuration management, show where each product is in its life cycle.

Products and scope control

Focusing on products is one of the strongest defences against scope creep. When the scope is defined as an agreed set of products with agreed quality criteria, any request for something extra is visible as a change: a new product, or a change to an existing product's description. It goes through issue and change control, with its impact on cost, time, risk and benefits assessed. Without product descriptions, scope expands silently because nobody can point to what was agreed.

Products in agile delivery

Agile teams often express products as user stories, epics and a product backlog, with a definition of done that functions like quality criteria. This is compatible with the principle. What matters is that the outputs are defined in terms the users understand, that quality expectations are explicit, and that completion is judged against them. In agile settings, scope is often the main tolerance: the team commits to a fixed time and cost and delivers the highest-priority products within them.

Outputs, outcomes and benefits

PRINCE2 distinguishes between outputs, outcomes and benefits. Outputs are the specialist products the project delivers. Outcomes are the changes that result when people use the outputs. Benefits are the measurable improvements that result from outcomes and that someone values. A new booking system is an output; clinics booking appointments online is an outcome; fewer missed appointments and lower call-centre costs are benefits. Focus on products concentrates on outputs, but the product descriptions should be written with the intended outcomes and benefits in mind, which links this principle to continued business justification.

Failure modes

Writing a good product description

A product description is a short document with a standard set of headings. Not every heading is needed for every product, but the core ones are: identifier and title; purpose, which explains why the product is needed and who will use it; composition, which lists its parts; derivation, which lists the sources it is built from; format and presentation; quality criteria and quality tolerance; quality method, which says how the product will be checked; and quality responsibilities, which name who produces, reviews and approves it. The skills needed to create it may also be listed.

The product flow diagram

The product flow diagram shows the order in which products must be created and which products depend on others. It is drawn from the product breakdown structure and often reveals dependencies that a task list would hide. For example, training materials depend on the final system screens, which depend on the completed design, which depends on agreed requirements. If requirements slip, the diagram shows immediately which later products are affected. External products appear in the flow diagram too, so a dependency on another team or supplier is visible and can be tracked as a risk.

Products and configuration management

Once products exist, they need to be controlled. Configuration management records the versions, status and relationships of products, so that everyone works on the right version and changes are traceable. A product status account shows the current state of products at a point in time. On a small project, configuration management may simply be a shared folder with a version naming rule and a simple register; on a large project it may involve dedicated tools and a configuration librarian. Either way, it supports this principle by making sure the products being reviewed, approved and handed over are the agreed ones.

Products beyond the specialist work

PRINCE2 distinguishes specialist products, which the project exists to deliver, from management products, such as the business case, plans, reports and registers, which exist to manage the project. Both kinds are products in the sense of this principle and can be described, created and checked. Treating management products this way is a useful discipline: a highlight report has a purpose, an audience and quality criteria, such as including forecasts against every tolerance, and a report that fails those criteria is not fit for purpose however neatly it is formatted.