PP 01 understand the steps involved in product-based planning (p)

PP 02 understand the benefits and uses of product-based planning (p)

PP 03 understand where in the eight processes product-based planning is used as described PRINCE2® (p)

PP 04 describe the purpose and content of the four product-based planning products, and be able to describe which PRINCE2® roles should be involved in their production and use (p)

PP 05 relate the product-based planning technique and products to the sub-processes of the Planning process

PP 06 create, modify or discuss a Product Breakdown Structure and Product Flow Diagram, for a given project scenario

PP 07 create, modify or discuss a Product Description for a product identified in any given project scenario

Final product: A served cup of tea. A22 Product description:...

	Tea with milk & sugar in a China cup with saucer
	Water 100o, English Breakfast tea, 7g white sugar, fresh (skimmed) milk

Product based planning: Applicable to all levels of plan

	A key technique in PRINCE2® (activity based planning is necessary but not key)
	Products required to meet business case dictate activities required Activities are identified (PL3), estimated (PL4), resourced & scheduled (PL5) Baseline for cost & time management and input to Business Case (IP3 & SB3)
	Each product’s required dictate quality activities Identified in PL2, Done in MP2, Checked CS2 & CP1
	Unambiguously defines the products (activities) within each management stage

*FP: Final Product

Product based planning supports explicit allocation of technical scope to management stages

Technical stage (lifespan phases) often overlap for schedule optimisation

Technical stage often delimited by skill used or product created

1. [Produce] A Product Description of the final products of the project

   	22.3 Written by the customer so the supplier knows the required outcome
   	May be in the Project Mandate, workshop details in SU4 for Project Brief
   	Required in IP1 for formulation of Project Quality Plan

2. [Decompose into] A Product Breakdown Structure

   	Know the constituent parts that must be produced
   	Carried out in PL2

3. [Create a] Product Descriptions of each (sufficiently significant) product

   	Describe the quality characteristics of every sub-product
   	Created in PL2 as soon as possible after each product is discovered

4. [Sequence in a] A Product Flow Diagram

   	Define the sequence of sub-product production & use
   	Performed in PL2

5. AsBDF: The world’s snappiest mnemonic

The single most important part of any project: capturing what will satisfy the customer

	Captures customer’s & user’s description of all (sufficiently significant) products in the PBS* Enables identification & management of activities to develop & quality control all products in project’s scope
	Unique Identifier from or compatible with the configuration management method in use
	Product’s Name/ Title, Purpose, Function, Appearance/ Format/ Presentation standards
	Decomposition as expressed in or exists below that provided in the A20 PBS (eg the chapters in a book)
	Quality Attributes/ Criteria and tolerances (eg Size, Complexity, Robustness etc specifications that will be used when inspecting the finished product) - see A1 Acceptance Criteria and A31 PQP May be a cross-reference to common standards, other documents such as customer or supplier Quality Management System or a full description of any ‘yardstick’ applied Tolerance ranges: may be a time-based series of improvements that continue post project closure Acceptance criteria must define what makes the product fit/ unfit for purpose Product acceptance criteria must be compatible with project acceptance criteria
	Quality checking method/ people and skill to be used to validate function and acceptance criteria Specific people may be identified in stage planning or earlier if known
	Description of the skills (or specific people) required to develop and check the product Clear, unambiguous, agreed single point accountability of who the development and checking tasks have been allocated to (when known)
	Source or derivation of the product or of product information Eg Specification, Purchased from…/ Supplied by…
	*And all management products – some of which are partially defined in Appendix A X-Ref to standards may be in Derivation-eg process std, Format-eg Look&Feel or Quality Criteria-eg Measurement

Products may be simple or intermediate

	Simple may be: Internal or external
	Intermediate may be: Collective or integrative Made up of lower level intermediate or simple (internal or external) products

PRINCE2® does not differentiate between “green” and “blue” simple products. A product is either internal (box) or external (ellipse). The convention in these notes is purely to aid illustration of rules governing translation from PBS to PFD

A simple product is the lowest level of any branch

	Does not need to be further broken down for control, or cannot be broken down
	No difference whether parent is collective or integrative
	Internal shown in a box Project manager responsible for [correct] acquisition, creation or amendment Work under PM’s control; may be performed by a sub-contractor
	External shown in a ellipse Project dependent on a product, often pre-existing that is outside of the PM’s authority & accountability (22.4.6) Have no predecessors in a Product Flow Diagram (p.312 PFD bp 4) Eg An advertising campaign requires existing logo & corporate brand standards
	External dependencies, but not resource are modelled as external product dependencies
	Resource dependencies are modelled in scheduling (PL5) using classic tools: Prince2 assumes knowledge of activity based planning tools and so omits description

22.4.5 States required when:-

	Each state needs its own Product Description Testing may need to be spelt out for state changes
	Responsibility may change as states change

Each state is shown below a 'collective'

States not required when a product’s development activities can be adequately described and managed during activity planning in PL3

Hierarchical model of the “content and function*” of all products to be developed and quality controlled to fulfil the business’ needs

	Shows ‘is composed of’ relationships for the decomposition of the project’s Final Products Final Products are fully described in the A26 Project Brief and A31 Project Quality Plan Ie All Specialist and Management products (mostly listed in Appendix A) are included Products of quality activities related to Specialist and Management products are included Decomposition is to the level that: A22 Product Descriptions establish the A1 Acceptance Criteria applicable to the associated allocation of work via an A36 Work Package Project activity can be in the view of management, auditors and assurance staff be cost-effectively managed to plan
	Identifies ‘internal’ (developed by the project’s activities) products Conventionally drawn in boxes
	Identifies ‘external’ (pre-requisite products not developed within the project’s activities) Drawn in ellipses by convention
	Identifies groupings of internal and external products Integrative products drawn in boxes and collective groupings drawn as a rhomboid by convention

*Red-Book explicitly says “function” but the PBS simply & only shows composition: the A22 Product Description can state function

Encourages ‘structured thinking’ to clarify all necessary work

	Products viewed / grouped visually as an aid to understanding
	Avoids overlooking products
	Includes all products created, modified or acquired
	Includes all [intermediate] products needed to create or support the final product
	Includes all external product dependencies

Defines the composition/ derivation of product’s required

	An aid to specifying quality criteria more specifically
	An aid to more accurate estimating (effort, resource and timescale)

Product Descriptions (PD) ensure common understanding

	A clear, complete, unambiguous description Aids understanding Aids estimating
	Given to product creators and checkers Build in required quality criteria Confirm quality is present using agreed methods and measures Quality Criteria distinguish between an acceptable and unacceptable product
	Minimum of 1 per project (for the final product) Created as soon as a product is identified Advisable to create one for each (sufficiently significant) simple [or integrative] product in the PBS
	Identifies how products are presented

Answers the question ‘what comes next?’:…

	Helps in risk assessment associated with dependencies
	Helps decide placement of control points such as stage boundaries
	Natural lead-in to activity planning using networks and Gantt charts

Model (Activity on the Arrow directed graph) of the sequence of use of products and dependencies between products

	Contains all and only the simple and integrative products shown in A20 PBS External and internal products differentiated
	Flows represent all dependency/ derivation information from A22 Product Descriptions Final Products of the project are at the end of the Product Flow Diagram (PFD)

The PFD must be consistent with the PBS & Product Descriptions

	PBS/ PD are specified at a suitable level of detail for control by the users of the relevant planning level
	Ie Project Board, Project Manager, Team Manager

A. 5 Configuration Item Record

	Evolving record of each product’s status from Not-Started, through Work In Progress to Complete
	Created at PL2 when the product is identified in the A20 PBS, Updated to Work in Progress when the A36 Work Package is agreed at CS1 and set to Work Completed at MP3/ CS9 on evidence from the A32 Quality Log
	Reported against when producing A24 Product Status Account and verified for accuracy when performing a Configuration Audit or Verification

Composition

	Configuration Item Key = {Project identifier + Type of product + Product title + Latest version number}
	Product’s owner, Users and (for document CIs) Copyholders
	Source (EG in-house, or purchased from a third-party), Storage location and if relevant person working on the product & Date allocated
	Current Status
	X-reference to the Life cycle steps appropriate to the product*
	X-reference to Related products, A22 Product Description**, & all A28 Project Issue(s)** triggering changes to this CI
	X-references to CI related correspondence

*Chief examiner says “Project’s stages” for filtering purposes
**With appropriate consideration of versioning of the A22

Created in PL: A21 Product Checklist

	A table of milestones (product related achievements) with status dates expected and achieved
	Basis for progress monitoring supplementing or replacing Critical Path Networks, Gantt charts or other representations
	Started in PL2 (based on the PFD & updated in PL7 with planned dates Updated in CS1, CS2 & CS7 with actuals

Composition

	Plan identification
	Product names (and/ or CI Identifiers from Configuration Management)
	Planned and actual dates (as calculated in Project, Stage and Team Critical Path Networks and scheduled in Gantt charts & resource profiles)
	Eg: Draft ready, Quality check, Approval

4 Steps: Final Product Described (SU4/ IP1), PBS, PD, PFD (all in PL2)

Then the activity planning we are assumed to know about (PL3,4,5)

PBS

	Hierarchical or rooted tree structure showing "Is composed" relationship between products
	Simple products have no breakdown in the hierarchy (leaf nodes)
	Intermediates are a collection of grouped items that (Integrative) have to be assembled and probably deserve a Product Description to say how to test (Collective) don't assemble and don't require any tests, thus no work associated wit them and will not appear in the PFD
	‘Externals’ shown in ellipses: outside the PM's responsibility ("no line-item in the project's budget") but is a pre-requisite for successful completion

PD

What the product is and everything about how to test it Link to quality component

PFD

	Directed graph showing "comes before" or "is dependent on" relationships
	Contains all and only the simple and integrative products from the PBS
	For the exam "following the rules" is most important consideration
	Traceability between diagrams, correct use of drawing conventions

PL2 is the home of Product Based Planning

PL3 takes the PFD and adds activities to the arrows as a prelude to creating a precedence diagram for Critical Path Analysis

SU6àPL2

Initiation stage products of the project identified

IP2àPL2

Specialist products of the project defined by Senior Supplier, Senior User and other experts

Requires input of product description of final product from the Senior User

IP6àSB1àPL2

Specialist products of the 1st stage

Uses project PBS & PD/ PFD as start point

CS5àSB1àPL2

Specialist products of the next stage

CS8àSB6àPL2

Configuration audit of status of products in containing plan, Specialist product changes

MP1àPL2

Products of the Work Package

A technique for drawing a PBS and PFD from a Statement of Work* is to list all the products (suggested in the example below by emboldened text) down the middle of a page
[products may be inferred by reference to tasks in the SOW]

2nd (see illustration 2 sections hence) group list items that either assemble into something larger (integrative products), or are similar in some non-integrated way (collective groupings)

On the RHS add intermediate products (integrative and collective)

3rd indicate the sequence of product usage/ creation (suggested below by italics where explicit & underline where implicit) to show what will be the content of the PFD

	On the LHS indicate all “before”, “after”, “then”, and other sequencing words from the scenario
	While the resultant lay-out is not the official standard the intellectual content should be correct

*From SOW or an exam question in order to find errors in a given PBS/PFD such as Qn5 S:5.2

It is not always clear what counts as a product to be included

The general rule is if in doubt add it in now

	You can always ignore it later if it proves irrelevant
	Prepared system (integrative or state), Converted data, Transferred data (states), Design of System (External), Specification of changes, Minor Conversion Routines, Local Practices description, Small adjustments

Signed Purchase order

Pretty clearly another product given in the example in order to show “states of a product”

Other Possible Products

System or New system Synonyms for each other? Synonyms for SSIS system?

Software

Maybe a grouping for application and database software

Powerful Machine

Synonym for hardware?

Marginal products, could be argued about

3 Removed admin staff?

Probably (or definitely not specialist) products

	PID Management product
	Impact or outcome of project success Operating Economies Automatic data collection
	Impact of project failure Fines
	Existing “things” or circumstances not a product in the project’s scope Small computers Costly mistakes

PP 06 create, modify or discuss a Product Breakdown Structure and Product Flow Diagram, for a given project scenario

PP 07 create, modify or discuss a Product Description for a product identified in any given project scenario

Turn to Section:5 Sample Practitioner questions and try question 3

	Re-read the scenario S:5.1
	This question has extensive ‘Additional Information’ and a PBS diagram

Note the diagram contains errors that you are expected to identify

	Consider how much reading time does this question require!
	Did you make-up enough on other questions?

How many over-time questions could you handle in the exam?

Answer the question using a blank answer grid from S:5.3 then mark your answer using S:5.4

Research any questions where you disagree with the marking scheme

Note Part A has one question with two right answers, one of which is ‘best’ worth 2 marks and one not so good only worth 1 mark