PRINCE2® has two chapters amongst the many elements it
contains that are related to quality.
Presented first here is the Quality Review Technique: it
tells us how to administer a walkthrough. That is the roles involved and what
they should be doing in each of three (really four) timeframes. Quality Review
Technique is provided in case you don't have your own procedure (EG Fagin
Inspection). Quality review of specialist products is conducted in
Executing a Work Package (MP2)
and of Management Products one might argue in the the SU, IP, SB & CP
processes in preparation for acceptance of management products in DP. The
Red-Book never says so explicitly.
Presented second is the over-arching description of how
quality starts with
(A.7)
Customer’s Quality Expectations
which arrive with the participants, become enshrined in
(A.1)
Acceptance Criteria,
(A.22)
Product Description
and
(A.36)
Work Package and are confirmed to have been met in
Executing a Work Package (MP2)
and Decommissioning
a Project (CP1)
. In PRINCE2® terms the whole set of high-level intentions is described
in the
(A.31) Project Quality Plan. The PQP would be better titled
Policy than Plan as it is not the same in form, intent or structure
of most of the elements PRINCE2® labels Plan.
Top
of Page
Top
of Page
 |
QR01 understand the purpose and benefits of a
Quality Review |
|
QR02 understand the three steps of a Quality Review
as described in PRINCE2 |
|
QR03 understand the purpose and content of the
products used in a Quality Review |
|
QR04 understand where in the 8 processes Quality
Reviews are planned & conducted, & the roles of the project management team
involved in their planning and conduct |
|
QR05 understand the roles used in a Quality Review,
and how these relate to the standard PRINCE2 roles |
|
QR06 create, modify or discuss the products of
Quality Review in a project scenario |
|
QR07 apply the Quality Review technique to any given
project scenario |
|
QR08 discuss in detail the links between a Quality
Review, the processes & project management team roles, & show how this could
be applied to a project scenario |
|
QR09 understand where the planning and resourcing of
a Quality Review takes place
Top of Page |
Top
of Page
Top
of Page
|
24.1 “A structured procedure to
assess a product’s fitness for purpose”**
 |
A technique for checking quality of products
 |
All PRINCE2® techniques are optional (although the
USE of a Product Based Approach isn't(?)) |
|
|
Also known outside PRINCE2® as a “walkthrough”, or
“inspection” |
|
Any form of examining and making comments upon a
product for response by the producer |
|
A means of error detection, not correction |
|
|
24.2 “Early identification of defects…
|
An objective measurement* for management progress
control … |
|
…all vested interests contribute to improved product
quality… |
|
…helps build the team approach to development |
|
… user(s), who are represented … are more willing to
commit to that product.” |
|
|
Results in a signed-off (approved) product safely frozen
in the CM system |
|
* Actually a bunch of people agreeing is not “objective”
but a product completing QR is the basis to recognise value earned or progress
made |
|
** Actually the review is probably only able to confirm
the product conforms to its specification, which is quiet a different state
and the cause of many project problems |
Top
of Page
|
Review consists of three steps
|
Preparation, Review meeting and Follow-up |
|
|
Before the 3 steps (the 0th step)
is Quality Planning p326
|
Conducted during stage and/or team planning (SB1, SB6
or MP1 via PL2, 3 & 5) |
|
Identify and describe the products in PBS, and Product
Descriptions (PL2) |
|
Define the testing and review activities (identified in
PL3 and carried out in MP2) |
|
Assign team members to review roles (PL5)
|
4 Primary roles: Chair-person, Producer, Reviewer &
Scribe |
|
|
Schedule reviews for specific dates (PL5) |
|
Add empty records to the quality log to hold the
results of intended checks (SB1/6) |
|
Top
of Page
|
Preparation (carried out in MP2)
|
Chair: Confirm the
product and reviewers are ready as scheduled in stage plan |
|
Producer:
Make the Product Description & product available for
inspection*
|
Prepare responses to Question lists and advise chair
for setting of agenda |
|
|
Reviewers:
Assess product and send comments/ questions
lists to the chair
|
Annotate (mark) minor document errors on the product
itself |
|
Add all other comments to a Question List and
submit to the Chair |
|
|
Chair: Plan the
meeting & establish agenda covering all questions |
|
*The (B.9) Configuration Librarian probably does the
actual distribution |
|
Note the lucky scribe normally gets delegated to do
everyone else’s leg work in every stage |
|
Top
of Page
|
Review meeting (MP2)
|
Chair: Move meeting
through the agenda to raise questions & comments
|
Postpone the meeting if insufficient people attend or
are not adequately prepared |
|
|
Reviewers & producer:
Discuss, clarify and agree Follow-up Actions
to product
|
Note the review should specifically avoid designing
solutions |
|
|
Scribe: Note
agreements and any Follow-up Actions |
|
All: Agree review
outcome and next action (eg Sign-off, minor fixes & sign-off, Complete
Re-work & Re-review) |
|
Chair:
Update Quality Log to show the actual
results & inform PM
|
Raise Project Issues for faults found in any product
not under review or any tolerance threats identified |
|
|
Note the lucky scribe normally gets delegated to do
everyone else’s leg work in every stage |
|
Top
of Page
|
Follow-up
|
Producer: Carry out
remedial work (MP2) and secure sign-off
from reviewers |
|
Reviewers: Advise chair of agreement to fixes or of
on-going concerns |
|
Chair: Record results to
Quality Log for agreed changes and to
Project Issues for on-going concerns
|
Raise a Project Issues for any concern in a product
other than that under review |
|
|
|
Remedial actions within work package tolerance conducted
in MP2
|
Amendments within stage tolerance require
MP2->CS2->S5->CS7 to assign corrective actions |
|
Out with stage tolerance requires CS8 to raise Project
Issue to the Board (DP4) for guidance
|
May trigger premature closure (CP) or exception
handling (CS8->SB6,2,3,4,5->DP3 then CS1 or CP) |
|
|
Top
of Page
|
Suitably qualified individuals
compare a product to it’s A22 Product Description
|
Product description states
|
Quality criteria:
Acceptance Criteria specific to this product |
|
Quality Method:
How the ACs will be proved to be present |
|
Quality tolerance:
Any ranges to measures of ACs and improvements required over time
(somebody knows the work of Tom Gilb!) |
|
Quality checking skills or
people: Either the qualifications or actual person needed to
confirm the ACs |
|
|
|
As identified in the Stage/ Team
Quality Plan (a subsection of the Stage Plan)
|
States “Who does what checks”, “on what dates”, “using
what resources” |
|
|
Quality Review Meeting is run to an
agenda and Question
List
|
Agenda structures meeting |
|
Question lists allow producer to prepare responses pre
meeting |
|
|
Results are recorded to the
(A32) Quality Log |
Top
of Page
|
4 roles specific to the Quality Review plus 4 roles whose
day-job encompasses the quality review 22.4.2 |
|
Specific roles described earlier: Review Chairperson,
Product producer(s), Product reviewer(s), Scribe |
|
Roles whose day-job includes Quality Review involvement
|
PM: Plan the
reviews in outline and actions to address remedial work while preparing
Stage Plans and contained Stage Quality Plan
|
Project Support:
Arrange meeting rooms, distribute products, act as scribe etc |
|
|
Team Manager: Plan
reviews in detail, appoint people to review roles, monitor review results
and report to PM |
|
Project Assurance:
Voice opinion on chosen reviewers (their technical suitability and
familiarity with the Quality Review technique)
|
Check procedures are followed, standards used,
results recorded and followed-up |
|
Liaise with Quality Assurance on the improvement of
standards & procedures |
|
|
Top
of Page
|
How these relate to the standard PRINCE2® roles
|
Project staff members are appointed to quality review
roles based on skills and availability during stage planning (or team
planning) |
|
|
Review chairperson: e.g Project Support, Senior User, Senior
Supplier or other capable person
|
“…[Chairs] the quality review [not the project board!] |
|
…Check that the product is ready … |
|
Ensure that the quality review
is properly organised (venue, date, time, attendees, duration) |
|
Gather in the question lists and
set the review meeting agenda… |
|
Provide final review sign-off [or] Institute exception
procedures [for problems that cannot be resolved in Quality Tolerance]” |
|
|
Scribe (May be a Project Support resource)
|
“Assist the chairperson … administrative” |
|
Top
of Page
|
QR 06 create, modify or discuss any of the products of
Quality Review in a given project scenario |
|
QR 07 apply the Quality Review technique to any given
project scenario |
|
QR 08 discuss in detail the links between a Quality
Review, the processes and project management team roles, and to show how this
could be applied to any given project scenario |
Top
of Page
Top
of Page or
Top of
Section
|
Candidates are not required to have any detailed
understanding of ISO 9000:2000 |
|
QU 01 describe the purpose of Quality Management (p) |
|
QU 02 identify the products of Quality Management, and
understand their purpose and content (p) |
|
QU 03 describe the importance of the Customer’s Quality
Expectations (p) |
|
QU 04 understand the part played by a possible quality
management system from the user or supplier in contributing to a Project
Quality Plan (p) |
|
QU 05 understand the Quality Management responsibilities
and activities of the various PRINCE2® roles within each of the eight
processes (p) |
|
QU 06 understand the quality path through a project as
illustrated by PRINCE2® (p) |
|
QU 07 understand the relationship between quality
assurance and the Project Assurance role (p) |
|
QU 08 discuss the role played by Project Assurance in the
various PRINCE2® processes, components and techniques |
|
QU 09 create, modify or discuss the products of Quality
Management in a given project scenario |
|
QU 10 apply Quality Management to a given project
scenario |
|
QU 11 identify the relationship between Quality
Management and other PRINCE2® components within any given project scenario |
Top
of Page or
Top of
Section
|
18.3 Quality Management is “the process of ensuring that
the quality expected by the customer is achieved”
|
Quality Management
is a corporate capability that encompasses PRINCE2®
as the project management component |
|
Quality is achieved using a Quality Management System (QMS)
|
QMS may be constructed to the ISO 9000 standard (The
“Requirements specification” for a generic QMS) |
|
|
|
QMS Includes
|
Quality Policy: the company’s attitude to quality |
|
Procedures, processes and responsibilities
(Organisation structure)
|
Used to conduct normal business in accordance with
Quality Policy |
|
|
Processes cover tools, techniques and working
practices. |
|
|
Project Quality is owned by the
Project Board
|
QMS is owned and operated by
corporate Quality Assurance |
|
Quality Assurance
are NOT part of the project |
|
Top
of Page or
Top of
Section
|
18.4.1 p270 “The quality organisation structure indicates
the responsibilities for quality
|
Who sets the quality policy |
|
Who sets the standards to meet the policy |
|
Any external body imposing quality constraints |
|
Who monitors use of the standards |
|
Any quality training group |
|
Much of this work is often done by a central quality
assurance function” |
|
Top
of Page or
Top of
Section
|
Project’s quality responsibilities lie with the Project
Board
|
Often delegate to those with necessary skills and time
|
Known as “Project Assurance” |
|
|
Project Assurance often drawn
from ranks of & work closely with
Quality Assurance |
|
|
Project Board
|
Ultimate responsibility for quality |
|
Specify quality required and ensure/ confirm quality is
being achieved
|
Via their (possibly delegated) project assurance
responsibilities |
|
|
|
Project Assurance
|
Police all aspects of project and product quality |
|
Ensure the right people do the right things at the
right time
|
Staff have the skills (are properly trained) and the
time |
|
Quality Review Follow-Ups Actions are completed |
|
|
Top
of Page or
Top of
Section
|
Senior Users
|
Define requirements
and test products (represents those who...) |
|
Specifications are complete, accurate and reflect needs
of all users (SU/ IP) |
|
Confirm products are being
built to specification (MP2) |
|
Confirm products are acceptable and accepted (MP3 &
CP1) |
|
Interested in “Fitness for Purpose” |
|
|
Senior Supplier
|
Ensure products are built to
specification* |
|
Specifications are complete, understood and achievable
to known cost and timescale (SU5/ IP & PL) |
|
Ensure use of correct product oriented standards and
quality of workmanship (MP1&2) |
|
(only) Interested in “Conformance to Specification” |
|
|
Executive
|
Concerned that specification exactly matches purpose |
|
|
Project Manager
|
Ensure the project is producing products of suitable
quality (CS) |
|
|
Team manager
|
Follow standards when producing products |
|
Follow quality control process |
|
Update the Quality Log with Quality Review results |
|
|
Project Support
|
Administer the Quality Review process |
|
|
Quality Review Chairperson: See
Quality Review Chair above |
|
Quality responsibilities documented in the Project
Quality Plan |
|
* Note references to Conformance-2-Sec & Fit-For-Purpose.
Quality Reviews are conducted in Executing a Work Package (MP2) where the
product is compared to its (A22) Product Description - thus a Quality Review
is a supplier side conformation of Conformance to specification |
Top
of Page or
Top of
Section
|
Quality Assurance are
a corporate function outside the PRINCE2®
project
|
Receive project’s A17 Lessons Learned Report from CP3 |
|
Apply experiences from using the QMS to improve future
projects |
|
|
Project Assurance are
the people with roles within the project
|
Reviews team plans and the work of all project members |
|
May have been recruited from Quality Assurance |
|
Advise the project board on the reliability of results
reported to them
|
Answer the board’s question “Can we trust the
information we receive from the PM is true, complete and a fair view” |
|
|
Top
of Page or
Top of
Section
|
Projects are temporary
|
Project quality approach must be created for each
project |
|
Required in advance of specifying tasks, timescales,
costs and resources
|
Will drive activities and resourcing described in
project and stage plans |
|
|
Approach or policy documented in Project Quality Plan
A31 (IP1?IP6?DP2)
|
Part of the Project Initiation Document (PID) |
|
Describes project’s policy or philosophy towards
quality (not truly a plan) |
|
|
Creating the PQP should merge customer’s policy and QMS
with supplier’s
|
Customer policy takes precedents |
|
|
Top
of Page or
Top of
Section
QU01: The Purpose of Quality Management
|
IP1 performs Project
Quality planning
|
Answers “How quality will be achieved on this project”
|
Selection of standards for project management and
product development activities |
|
|
Driven by A25 Project Approach plus A7 Customer Quality
Expectations as translated to A1 Acceptance Criteria in SU4
|
CQEs taken from the Project Mandate and/or captured
in SU4 |
|
|
IP1 and PQP say “Who, what and how” at highest level |
|
|
SB1/6 and MP1 perform Product Quality Planning
|
Specifies activities to build and check products based
on product standards (PL3) |
|
Assigning staff with checking skills to dated Quality
Reviews (PL5)
|
Driven by Product Descriptions created in PL2 |
|
|
Stage and Team Quality Plans
say
|
“Who what and how to validate products” at lowest
level |
|
True plans! part
of Stage Plan or Team plan |
|
|
Top
of Page or
Top of
Section
|
A31 Project Quality Plan (Not a Plan but a
Policy Document)
|
Identifies the techniques and standards required to
achieve quality |
|
Quality responsibilities |
|
Control and audit process for both specialist and
management work |
|
Change management procedure and configuration
management plan |
|
Customer Quality Expectations and Quality tolerances |
|
Acceptance Criteria |
|
Any tools used to ensure quality |
|
Top
of Page or
Top of
Section
|
A.22 Product Description
|
Provides a detailed description of product’s
derivation, appearance, quality, construction & acceptance considerations |
|
Identifier: unique
key, probably from configuration management (minus version number) |
|
Title: name by
which the product is known |
|
Purpose: background
to such ideas as robustness, complexity etc |
|
Composition and Derivation:
May link to a PBS/ PFD and other sourcing information |
|
Format and presentation |
|
Allocated to:
skills or people needed to create the product |
|
Quality criteria,
Quality method,
Quality tolerance and
Quality Checking skills or people required:
How the Acceptance Criteria will be demonstrated |
|
|
Note there may be many products per Product Description
|
Intermediate (Integrative) and simple products in the
PBS may have a PD |
|
Each product will have an (A5) Configuration Item
Record that records “owner” & status |
|
Top
of Page or
Top of
Section
|
A25 Project Approach
|
“Define the type of solution to be developed by the
project and/or the method of delivering that solution” |
|
Must match A1 Acceptance Criteria (and A7 Customer
Quality Expectations) |
|
|
A.25.2 Composition
|
Options considered |
|
Chosen option and reasons for selection/rejection, for
example, part of programme approach |
|
Operational environment (identification of any
environment into which the solution must fit) |
|
|
Options considered are typically combinations of
|
“buy or build”/ “in-house or outsourced”/ “from scratch
or by adaptation”/ “tailored or off-the shelf” |
|
Top
of Page or
Top of
Section
|
A 32 Quality Log
|
“Summary of all the quality checks that are planned
(1st) and have (2nd) taken place“ |
|
Reference number |
|
Product |
|
Method of quality checking |
|
Staff responsible, name, role |
|
Planned date and Actual date |
|
Result |
|
Number of action items |
|
Target sign-off date (as defined when agreeing
Follow-Up Actions) and Actual sign-off date |
|
|
A 32.3 “Entries are made when a quality check or test is
entered on a Stage Plan. The remaining information comes from the actual
performance of the check. The sign-off date is when all corrective action
items have been signed off
|
An initial, blank Quality Log is created during
Planning Quality (IP1)” |
|
Top
of Page or
Top of
Section
|
Planning is dependant on knowing the Customer’s Quality
Expectations A.7
|
Meeting CQE’s depends on having agreed, measurable,
prioritise definitions |
|
|
SU4 extracts CQE from the Project Mandate A.29
|
Senior User specifies and confirms agreement |
|
Translated to agreed, measurable Acceptance Criteria
A.1 |
|
Recorded in the Project Brief A.26 (p.329 & p.331) |
|
Project Approach A.25 matched to the Acceptance
Criteria (in SU5) |
|
IP2 creates Project Plan A.30 based on Acceptance
Criteria, Project Approach and the Project Quality Plan |
|
|
Acceptance Criteria
|
A prioritised list
of criteria that the final product(s) must meet
before the customer will accept them; a measurable
definition of what must be done for the final product to be
acceptable to the customer. They should be defined as part of the Project
Brief and agreed between customer and supplier
no later than the project initiation stage. They should be documented in the
Project Initiation Document - (Note the definition makes AC supplier
centric, Statement of Work centric, conformance to spec centric, NOT
Statement of Outcome, fit-for-purpose oriented) |
|
Top
of Page or
Top of
Section
|
Customer’s
quality expectations §18.4.1 & Glossary
“A statement from
the customer about the quality expected from the final product. This should be
obtained during the start-up of a project in Preparing a Project Brief (SU4)
as an important feed into Planning Quality (IP1), where it is matched against
the Project Approach and the standards that will need to be applied in order
to achieve that quality” |
|
Expectations are initial thoughts
|
Often ill-defined |
|
Customers CQEs may be in conflict at the start of the
project |
|
Acceptance Criteria are the result of work to define
and align CQEs Acceptance Criteria may require compromises to arrive at an
agree state |
|
|
Acceptance Criteria A1
|
Criteria may be objective (preferred) or subjective
|
It is almost always possible to define objectively
measurable criteria. But it is not always worth the effort - p274 slightly
paraphrased |
|
|
Project performance AC are Target dates, Costs,
Interfaces to be maintained, Control of changes, Scope, Timings |
|
Top
of Page or
Top of
Section
|
QU 08 discuss the role played by Project Assurance in the
various PRINCE2® processes, components and techniques |
|
QU 09 create, modify or discuss the products of Quality
Management in a given project scenario |
|
QU 10 apply Quality Management to a given project
scenario |
|
QU 11 identify the relationship between Quality
Management and other PRINCE2® components within any given project scenario |
Top
of Page or
Top of
Section
|
Part A is a convergence of quality and product based
planning |
|
Part B gives 4 questions and 16 marks and all ask for two
selections – Ie they carry 2 marks each – should be possible to catch-up some
time for slower questions |
|
Re-read the scenario S:5.1 if you need to
|
There is ‘Additional Information’ specific to this
question |
|
|
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
|
How much time was looking up references in the Red
Book? |
|
Top
of Page or
Top of
Section
|
Turn to Section:5 Sample Practitioner questions and try
question 9
|
Do the question against the clock. Your target is circa
15mins |
|
|
Re-read the scenario S:5.1 if you need to (surely not!)
|
There is no ‘Additional Information’ for this question |
|
|
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 |
|
|
Let us know you have got to here by mailing prince2@LogicalModel.Net |
|
You may wish to redo all the exam questions again
|
You should gain new insights by re-doing questions you
are familiar with |
|
We will do and thus discuss underlying rationale of
these and others on the course |
|
Top
of Page or
Top of
Section
