Appendix A: PRINCE2® Product Descriptions

Contained in the Project Brief, Project Quality Plan and Product Descriptions

Measurable (realistic & agreed) definition of the attributes of the project’s final product(s) critical to acceptance by customers and affected staff

Realistic individually and in aggregate

Often expressed as the Quality Criteria of the Product Description of the final product

May be specified at multiple levels over a time-frame as benefits stream starts and improves over time

May only be ultimately verifiable in post-project benefits review (eg Reliability, MTBF)

Extended from A7 Customer Quality Expectations during SB4 and IP1

Senior User accountable for specification of ACs

Major functions, Operational running costs, Performance levels such as: Capacity, Accuracy, Availability, Reliability (mean & maximum time to repair, mean time between failures), Security, Ease of use or Level of personnel required to operate the product, Appearance and Timings

Development costs and Target dates

*Tom Gilb writes on the topic of attribute specification and their evolution over time **PRINCE2® view is narrower than best practice: bp is to consider all other stakeholders expectations

Describes the justification for the total business change, the estimated development, implementation and through life cost and risk versus the expected benefits

Provided to the project in the Project Mandate (maybe), checked & set-out as an outline in SU4 (as part of the A26 Project Brief), refined to an Initial version in IP3 (as Part of the A27 PID), updated at stage end (by IP3)

Considered by the Project Board at every decision point (DP1, 2, 3 and 4) to verify that the forecast effort and time remaining will be worthwhile

IE the project remains viable versus the current version of the A2 Business Case

Confirmed for alignment and consistent with corporate or programme strategy

Assessed versus project plan for alignment & realism

Reasons for the project (from Customer and Project Mandate and/ or Project Brief)

Options considered, selected, rejected and why

Benefits expected expressed in justifiable and measurable terms against today’s situation

Summary of threats and opportunities from the project A34 Risk Log

Cost & Timescale from the best current source (the A30 Project Plan after IP2)

Appraisal and evaluation of Best, Most Likely and Worst costs and B/ ML/ W benefits* together with analysis of sensitivity factors influencing costs and benefits

Possibly including Net Present Value/ Discounted Cash Flow and other financial modelling

*PRINCE2® terminology is Good Average Poor or GAP Analysis. This is in contrast to the normally understood “gap” between available and desired features in a vendors offering to an Request For Proposal

Template at A.2, explanation at 13.2

Routine communication from those executing A36 Work Packages (MP2) to the Project Manager (CS2 then CS5)

Documents the results of a Checkpoint [meeting]

Frequency defined during stage planning or Work Package allocation (MP1)

Consolidates

(probably verbal) Reports of all work of each team member versus schedule

Stage and Team Plan updates

All open topics from previous Checkpoint Reports

Date & Period covered

Products completed in the period & due to complete next period

Risks and issue (problems) summary

Follow-ups from previous reports

Activities executed in period & due to be executed next period

Quality work carried out during the period

Work Package tolerance status

Communications methods, timings, frequencies, sources and destinations to and from all project stakeholders as indicated by Project Mandate, Project Brief & Project Approach

Agreed during IP4 and planned for in PL3 (ie a resourcing provision is made for reporting activities)

Consulted during CS6

Included within the A27 PID

All stakeholders within and out-with the project team

Eg Project Board and management team, Customer and Supplier staff and users, Accounts, Internal audit and Quality assurance

Information required, who by, who from, when, how often, format(s), method(s)

Created in PL: A5 Configuration Item Record

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

CM03: A5 Configuration  Item Record

A5.1 Purpose

A record of a product’s status

A5. 3 Derivation

Product Breakdown Structure

Stage and Team Plans

Work Package

Quality Log

Issue Log

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

Project identifier + Type of product + Product title + Latest version number

Product Description

The life cycle steps for the product

‘Owner’ of the product

Person working on the product

Date allocated

Library or location where is kept

Source

Links to related products

Status

Copyholders and potential users

Cross-reference to the Project Issue(s) that caused the change to this product

Cross-references to correspondence

Part of the A31 Project Quality Plan that states the Whys and wherefores, the Who the How and the When covering controlling and protecting the project’s products via Configuration Management

Derived from customer & supplier CM practices (IE QMS) and tools

19.4.1 “part of the Project Quality Plan [defining] how and where the products will be stored, …security…identification,…[and] responsibilities”

A6.1 Purpose

To identify how and by whom … products will be controlled and protected

A6. 3 Derivation

The customer’s [suppliers] quality management system (QMS)

Specific needs of the project…, organisation structure, … configuration management software or mandated by the customer

...An explanation of the purpose [of CM]…

A description … [of the] method to be used

Any variance from corporate or programme standards should be [justified]

… systems or tools to be used …

[storage]

[security]

… versions [identification]

Where responsibility for configuration management lies

Reference or description of tools and methods to be used

Extensions or relaxations of standard methods with justifications

Description of all areas (physical & logical) where products will be stored/ filed

Entry/ exit mechanisms for Check-in and Check-out

Security arrangements for deposit and withdrawal of products

Configuration Item naming scheme

Reporting regimes for creation of A24 Product Status Accounts

CM responsibilities/ reporting lines at customer and supplier side during and after the project

Illustrates content of fields in Project Mandate and Project Brief when considering:

What elements of which Quality Management Systems and Standards are relevant to the products of the project

How will Management of Change be handled, post project, for the impact on Status Quo (staff/ procedures/ benefits assessment) of product roll-out into the business

Aspirational view of the Senior User and other customer’s view** of what makes the project end-point acceptable as provided in the Project Mandate or discovered during SU4

Basis for deriving Acceptance Criteria including:

Level of team & customer satisfaction

Capturing expectations in whatever format best communicates customer needs & wants

*Tom Gilb writes on the topic of attribute specification and their evolution over time **PRINCE2® view is narrower than best practice: bp is to consider all other stakeholders expectations

Diary of communications and actions taken plus to-do list of pending reminders

Kept by project manager (and team managers) as aide-memoir

Applies when other PRINCE2® management products do not

Used as a means to capture information to record properly later  (eg discussion of a Project Issue prior to formal entry at CS3)

Written neatly and loquaciously enough to be decipherable after the event!

Date of entry, People involved, Action taken or required/ comments made

Follow-up date/ Target end-result and date

Eg extract from Risk Log of reminders to check status with risk owners, day-to-day amendments to work allocations in the Stage Plan, follow-ups to Checkpoint Reports, Quality Log records, corridor conversations or observations

Project Manager’s summary of project performance produced in CP3 for the Project Board and corporate or programme management

Comparison of intentions recorded in the A27 Project Initiation Document, versus:

Final versions of Business Case and Project Plan

All plans (Team, Stage and Exception Plans)

All logs

Reports from Lessons Learned and End-Stages

Describes achievements, and benefits (if any at project closure) vs. project objectives, schedules, budgets and tolerances

Net effect of approved changes on A27 Project Initiation Document, especially the initial Project Plan and Business Case

Statistics

Quality activities

Project Issues handling

Includes the Post-Project Review Plan

The quality work done during the project meets the quality expectations of the customer.

Summarises overall status and progress in the stage just closing versus plan with sufficient detail for the Project Board to decide next steps

Approve the next stage, Request a revised Stage Plan, amend project scope or stop the project

Created and reworked in SB5 until agreed by Project Assurance

Current Stage Plan tracked against actual progress on completed work packages

Upcoming Stage’s plan and Updated Project plan

Reflecting progress to date, risks, issues, exceptions, quality results and lessons learned

Project Manager’s review of events that affected stage performance plus the outlook for Project Plan, Business Case and Risks

Summary of Project Issues, Performance against stage tolerances Quality statistics

*Things the project/ stage has no control over but cannot succeed without, **Unknowns whose value or state is a pre-requisite for planning so plans have been based on an ‘expected’ value, ***Things we rely upon to succeed

A plan that if approved (by becoming the new baseline) replaces a plan whose contents is no longer desired or relevant

Sets out the actions from current status/ context to currently desired team/ stage/ project outcome

Based on recommendations made in an A12 Exception Report (Stage and Project Plan) or Project Issue (Team Plan)

Resolves the concern raised in the Exception Report

Approval by the next higher level of the project management team

Requested as a result of detection and assessment of a tolerance threat*

Produced according to the product description and plan design of the relevant plan level

Team plan changes may affect stage plan (with or without impact on stage tolerances)

Stage plan changes may affect project plan (with or without impact on project tolerances)

The exception plan may be wholly new or largely the contents of the replaced plan

Includes all actions to create, quality control and accept relevant products within (possibly revised) scope, risk, benefit, quality, time or cost limits and tolerances

*Whether Mandatory (eg failure to perform) Discretionary (eg Request for Change) Certain (eg Project Issue) or Uncertain (Risk)

Record of a forecast deviation beyond tolerance levels within a

Team plan (project Issue raised at MP2?CS3)

Stage or Project Plan (CS8)

Identified from sources external to the project or any of the plans, logs and reports of the project

Description of the cause & consequences of the deviation

Response options and the effect of each on the A2 Business Case, risks and tolerances

Escalating manager’s recommended response

Provides continuity of management for ongoing risks and hand-over into operational support of open A33 Request For Change at project closure

Created in CP3 by consideration of all logs and reports

Report date

Details* of items that merit operational consideration after project closure

(all) Unimplemented Requests for Change (& other Project Issues**)

Off-Specifications for missing or incomplete products

Risks whose impact is an ongoing concern

Activities required for handover, training or product use, refinement, adaptation and evolution

Routine communication from Project Manager (CS6) to Project Board (At DP4) and other stakeholders

Summary of progress, problems, early warnings and requests for assistance

Frequency suggested in IP4/ revised in SB5, Recorded in Controls section of PID

Consolidates recent Checkpoint reports, Project & Stage plan updates, all log files and status date versus PID

Distributed as defined in the Communications Plan

Date & Period covered

Products completed in the period & due to complete next period

Risks and issue (problems) summary

Status of Budget & Schedule including impact of recent changes

Status of tolerances

Project Issue status

An ‘index’ into and summary listing of, the complete set of all Project Issues

Created in IP5

Access is controlled by the Configuration Librarian and the use of CS3 and CS4

CS3 may be used by anyone at anytime to log a new Project Issue of appropriate type

Project Issue number, Issue type & Priority

A33 Request for Change, A18 Off-Specification, general question or statement of concern)

Author, Date identified & Last updated

Description

Status (action taken – if any)

The repository (created in IP5) of all lessons observed during the project that may be useful to other projects

Added to (minimally) at end of stage (SB5) and (optimally) whenever any good or bad observation of value is made about any/ all specialist or (project) management Tool, Method or Process

Based on all logs, Completed Work Packages (MP3/CS9), Checkpoint, Highlight and End Stage Reports, Tracked actuals from Team (MP2) and Stage Plans (CS2)

Reflects observations of all project participants from Project Board and Assurance, PM, TM, Team members and Project Support/ Configuration Librarian

Describes of all events causing positive or negative deviations from expectations or tolerances Covers:

Missing guidance, Redundant processes, Useful additions

Effective and ineffectual Quality Review or testing activities with suggestions of why effect was good/ bad

Observed actual resources and other quantities from performing tasks versus estimates and estimating approaches

Corrective or consolidating/ opportunistic actions taken or possible (even with hindsight! ?)

Record of observed performance with suggestions for amendment to

Specialist methods and tools

Project management methods and tools and Controls

*All supporting documentation **Project Issues can be marked as closed once recorded as passed on in an A13 FOAR

Summary and analysis of the project performance created in CP3 for use elsewhere in the organisation

Possibly circulated by corporate quality assurance or project office for incorporation into quality management systems

Derived from A16 Lessons Learned Log, End Stage Reports, Issue Log and Quality Log

Summary of project wide results that were better or worse than expected

Recommendations for best future project performance

Summary of all Processes, Methods, Tools that were redundant in, missing from, or extra to the organisation’s QMS plus suggestions for best future performance

Includes all Specialist elements

Includes all Project Management elements & Controls

Analysis of

Estimating methods used and comparison (with conclusions) of estimated quantities and actual quantities for all tasks in the development of all products

Quality review methods (or tests) and statistics for effectiveness and efficiency in detecting errors

Project Issues raised and the results

A description of any abnormal events causing deviations

*All supporting documentation **Project Issues can be marked as closed once recorded as passed on in an A13 FOAR

Warning that a product  may/ will/ has failed to meet  its A1 Acceptance Criteria in its A22 Product Description

Often Supplier side & non-discretionary

Logged in CS3, Assessed in CS4,  Actioned in CS5?7 or CS5?8

Logged by anyone at any time

May be raised as an A28 and redefined  as A18 in CS4

23.1.4 “the Project Manager may try to solve the problem within the stage tolerance…or if the Board…accept the Off-Specification without corrective action; this is called a ‘concession’”

Date & Issue Log number

Status & Priority assessment

Description of & Impact of the fault

Decision

Allocation details, if applicable

Date allocated & Date completed

* CC02: Purpose of Change Records

Created in CP2 by reference to the A2 Business Case and workshops with affected stakeholders (including operations and maintenance/ support staff)

Incorporated into the A9 End Project Report

Performed after the products have had time to generate benefits ( post-project! )

Responsibility of the executive to carry-out the post Project Review

Defines why (reasons), how and when measurement of project benefits will be taken

Measured benefits compared with the benchmark of ‘today’ taken in IP3 and the timescale/ levels expressed in A1 Acceptance Criteria

Schedules suitably skilled and available resources for benefits reviews over time after the products have had time to create an impact

Documents the commitment required to:

Assessing the degree of each expected benefit achieved to date

Address improving benefit levels

Capitalise on unforeseen positive, and address adverse effects of the project’s impacts (including documenting why effects where not anticipated)

Assess user reactions

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

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

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

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

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

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

Products of PBP: A. 22 Product Description

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

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 a Configuration Item Record that records “owner” & status

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 Measurment

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

Selective report on the status of products from the Configuration Librarian’s store of Configuration Items

Selection normally: Entire project or Specific Product(s) or Current Stage or  Specific Work-Package(s) or team

Routinely produced in CS2, exceptionally produced in SB6 (and CS4?), required in CP1

CI Identifier = {Project name + Product type + Product identifier + Version number}

List of related products

Date Product Description baselined

Dates product baselined/ product (or copies) issued for change

Planned date for next baseline/ next release

Note of current lifespan status EG: Not started, WIP, change pending, in review

“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)

Created in SU5 by reference to the Project Brief Consideration of what is:

Technically feasible, affordable (development and through life costs), supportable, available in the market

Plus the opinions of the project board, subject matter experts & design authorities

Contents

Solution types considered

Normally includes: made-to-order, modification of existing product, design-from-scratch, ready-made/ off-the-shelf solution

Delivery methods considered

Normally includes: sub-contracted, in-house staff, contracted resources

Description of Target Operational Environment

Strategies affecting through-life ownership within which the product will be operated and maintained

Options chosen with selection/ rejection reasons for conclusions

Evolves/ extends into the A31 Project Quality Plan during IP1

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”

Ensures Project Mandate information is fully formed into a firm basis for project initiation

States (as well as is currently possible) how acceptance of finished products is determined

Created in SU4 and approved/ baselined at DP1

May be received fully formed from preceding work (EG Feasibility study or Programme)

Extended to become core of the A27 PID (the basis for ongoing direction of the project)

Background and Project Definition

Scope and objectives the project is to achieve in deliverable or outcome terms

Constraints, interfaces and exclusions

Outline Business Case & Risks* describing how the outcome supports the business, why it is needed and business risks

A7 Customer’s Quality Expectations and such A1 Acceptance Criteria as can currently be defined together with all Project tolerances

Reference to feasibility study or programme outputs (eg outline plans) where available

*Risks described in detail later-For now see Risk Log (next slide)

Aggregate of all the information to

Define the project and define a (realistic) regime of controls matched to the scale, risk and importance of the change initiative

PID held in whatever way is pragmatic to make the decisions at all and any major commitment point

Sound basis for the project’s authorisation (DP2), on-going management (CS & DP4/ DP3) and ultimate assessment of overall success (CP/ DP5/ Post Project Review)

Continuance of the project at major commitment points (DP3 & DP4) is by reference to revised versions of the Dynamic elements of the PID

Created throughout IP (assembled in IP6) from information in the Project Brief, Project Approach, Supplier Project Management standards & Customer control requirements as gathered from (senior) Users and Suppliers

Dynamic parts amended in Managing Stage Boundaries (SB), finalised and archived in Closing a Project (CP).

States direction, scope and commitments in the form of a ‘contract’ between the project management team and corporate or programme management

Project’s Aim (What), Justification/ Utility (Why), Development locations (Where), Stakeholders involved in managing the project and their responsibilities (Who), Development Approach (How) and schedule of activities (When)

Basis for the Project Board and Project Manager to assess progress, and Project Issues

Continuously maintained to assess ongoing viability and alignment of the project goal / A2 Business Case with current corporate or programme strategy

*Configuration management ‘Baseline’ that is approved for distribution and use. Approved at DP2 **Not changed during the project unless via Change Control

Stable elements*

Background, project context and history

Project definition: Aims & objectives (What), Project Approach (How), Scope (Limits to What or How), Deliverables (IE desired outcomes)

Exclusions & Constraints and Tolerances & Assumptions & Interfaces

Description of controls for normal and exception situations at team, stage (PM) and project (board) levels

Who administers each control, Monitoring & reporting flows/ timings/ contents, how control (decision making) is exercised, Relationship/ Alignment with Project Assurance duties

Organisational reporting lines and tolerances/ levels of authority

IE delegation and escalation from Team member upwards through to the Project Board’s escalation route

Dynamic elements (Expected to change during the project as a natural result of PRINCE2® management processes)

Initial (IE First Release** of the) A2 Business Case

Why and what utility is returned

Initial (IE First Release** of the) A30 Project Plan

Resource usage and timescales

Initial view of risks recorded in the A34 Risk Log

Uncertain positive and negative outcomes that have actions in the project plan to address probability and or impact

(agreed – signed) Project management team organisation structure & job descriptions

Named people per role, Role Description(s) per person, Job Titles,and justification of voids, overlaps and exceptions

A4 Communication Plan

A31 Project Quality Plan inc. A5 Configuration Mgmt Plan

*Not changed during the project unless via Change Control  **Configuration management ‘Baseline’ that is approved for distribution and use. Approved at DP2

Generic means to Raise (at CS3)

A Requests for Change, Off-Specification, Question, Statements of concern or new Risk

Impact Analysed at CS4, Considered at CS5 (and possibly also CS8 and DP4)  Actioned at CS7 or SB and DP3 ? CS1

Provides the means to raise & analyse (“in the normal manner” 20.2) a new risk outside of sub-processes dedicated to management of risk

Raised by anyone at anytime

Project Issue number, Author, Date raised & Priority

Description of the Project Issue

Analysis of positive and negative impacts on:

Any & all product A1 Acceptance Criteria

Project effort, cost, schedule and A34 Risk Log

Impact on A2 Business Case

All Plans and all tolerances

Decision from Project Manager or Project Board as dictated by authorities required

Signature of decision maker(s) & date

Triggers SU (created before any other activity occurs on the project)

Content may be of variable quality and quantity from nothing at all to a perfect Project Brief

Says what the project is to achieve

Formalised (developed) to be the A26 Project Brief (in SU4) and later  A27 PID (in IP1-6, especially IP3)

Provided by an authority able to authorise resource commitment to the idea

May be produced in a programme or by a preceding feasibility study (in which case details of earlier estimating, planning and risk analysis may be included)

Contents

Background (and reference to related documentation or products), Project objectives, Scope, Constraints and project level tolerances

Triggering Authority and perhaps suggestion of Executive and Project Manager and other interested parties (Customers, Users etc)

Reason for the project or Outline A2. Business Case and the A7. the Customer’s Quality Expectations

Interfaces

 “A mandatory plan [created from the outline in the Project Brief at IP2 and updated in SB2/ CP3] …[showing] how and when a project’s objectives are to be achieved, … the major products, activities and resources”

“It provides the Business Case with planned project costs [& timescales] and it identifies the management stages and other major control points”

It is used by the Project Board as a baseline against which to monitor project progress and cost stage by stage

Incorporated into the A27 PID

Contingency plans for how any risks that materialise will be dealt with

Plan description: textual, brief description of plan scope, all assumptions upon which the plan stands, all prerequisites that must be in place from project start to end for project success, all external dependencies

Project-level

Tolerances, change budget and contingency plans explaining how impacts of materialised risks will be managed

Product Breakdown Structure & linked Product descriptions, Product Flow Diagrams & linked activity network

Resultant graphical or other representation of schedule, financial budget/ cash-flows, tables of resourcing requirements

Gantt or bar chart with identified management stages

Requested/Assigned specific resources

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

Created In IP: A31 Project Quality Plan

A. 31 Project Quality Plan

The Project Quality Plan is the project’s policy or strategy document created in IP1

References (or defines) the techniques and standards required to achieve A7 Customer Quality Expectations and A1 Acceptance Criteria as applies to creation of the specialist and management products

State people/ roles with responsibilities for achieving target quality levels

Sets out reporting lines to the Project Board that are independent of the project manager

IDs standards from the Customer’s Quality Management System (by preference) or the Suppliers’ QMS

Included within the A27 Project Initiation Document at IP6 and may be amended in SB2

Based on/ extends the A25 Project Approach & addresses the Final Products defined in the A26 Project Brief

Should conform to corporate quality policy

A7 Customer’s quality expectations (from the Project Brief), A1 Acceptance Criteria and Quality tolerances

All standards to be applied to project activities and to be met by the project’s products (Management & Specialist)

Means of achieving/ the requirements for; quality control of Management & Specialist Activities & Products

Audit processes to be applied to Management & Specialist quality activities

Tools to be used

Standards, Procedures and plans for (approach to) Change Management (Impact analysis and approvals) Change (Version) Control, and A5 Configuration Management

 “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)”

Single project wide ‘Index’ to and summary of all quality checking documentation/ results for all products in project scope

Initially created empty (IP1), then lists intended quality reviews (SB1/MP1) and eventually holds audit trail of all checks performed (MP2)

Used to compile End Stage, End Project and Lessons Learned Reports

Responsibility for the log is allocated to a suitable individual when creating the A31PQP

Unique ID

Product & Method of quality checking

Name & role of person responsible

Planned & Actual date & Result (IE # of action items)

Target sign-off date (after review) & Actual sign-off date (after action items resolved)

Requests that a modification to a product or its A1 Acceptance Criteria be considered

Often customer led and discretionary

Logged in CS3, Assessed in CS4,  Actioned in CS5?7 or CS5?8

Logged by anyone at any time

May be raised as an A28 and redefined  in CS4

Change to a baslined product always needs the Project Board’s approval

RFC’s are funded from the project’s Change Budget or cause an Exception

Impact Analysis is funded from day-to-day project resource allocations

Date & Issue Log number

Status & Priority assessment

Description of & Impact of the proposed change

And of not doing the change

In measurable terms

Decision

Allocation details

Date allocated & Date completed

* CC02: Purpose of Change Records

A.34.1 “to contain all information about the risks, their analysis, countermeasures and status.”

Probability: estimate of the %age likelihood of the risk occurring

Proximity: the closeness in time in which the risk is likely to occur

Counter-measure(s): the actions that have been taken or will be taken to counter this risk

Owner: the person who has been appointed to keep an eye on this risk

Date of last update: when the status of this risk was last checked

Current status: for example, closed, reducing, increasing, no change

Risk identifier: unique code to allow grouping of all information on this risk

Author: who submitted the risk

Date identified: when first recognised

Description: explanation of the event(s) and its/ their outcome(s)

Risk category: from Appendix C, E.G. commercial, legal, technical

Impact: affect on time, cost, quality, scope, benefits, people/resource at project, programme, organisation level if this risk were to occur Normally assessed as Hi, Med or Low

RK03: Risk Analysis & Integration With A.34 Risk Log

Identify the risk

Id             Invent

Author   Who raised it?

Date Id’d                Dated memo?

Description           In the question?

Risk Category        From Apdx C

Evaluate the risk

Probability             H/M/L + REASON

Proximity               Clues in Question?

Impact

Time       H/M/L + Reason

Cost        H/M/L + Reason

Quality   H/M/L + Reason

Scope     H/M/L + Reason

Benefits H/M/L + Reason

People/ Resources              H/M/L + Reason

Identify suitable responses

P

R

A

C

T

Selection

Selected response and reason for selection/ rejection of others

Final Risk Log fields

Owner    Scenario person “keep an eye on it”

Date of last Update

Current status

Items in italics earn marks before you even start to answer the question

Logs the evolving description of potential opportunities and threats to the project’s benefits and conduct

First created during SU4 and added to in IP3 and SB3/ SB4 when risks to project benefits are considered based on the Project Mandate, Project Brief, project context and history to date

Added to in SU5 and PL6 when risk from project conduct and plans are included

Risks to and included in A35 Stage Plans are identified and considered in SB1 (really in PL6) and CS1/ CS2/ CS5

Reviewed (minimally) at end of stage and optimally routinely during conduct of a stage (CS5 and DP4)

The Project Board has responsibility to advise the Project Manager of risks in the wider corporate context and to decide the balance between countermeasure impacts (eg costs) and risk impacts (eg costs)

Activities to create and maintain the risk log are ‘normal’ management tasks and are budgeted and scheduled in the A35 Stage Plans

Risk identifier (possibly linked to programme and other risk management procedures), Author and Date Identified

Description of context, cause (event) & consequences (outcomes) that comprises the threat or opportunity

Categorisation from Appendix C:  Strategic/ commercial, Economic/ Financial/ Market, Legal and Regulatory, Political, Environmental,  Organisational/ Management/ Human Factor, Technical/ Operational/ Infrastructure

Impact or effects on costs, Schedules (time), Quality, Scope, Benefits, People/ Resources to the project or programme or organisation

Estimated probability in numeric or High/ Medium/ Low terms of the event occurring

Proximity expected lead time to the occurrence of the event or the outcome

Countermeasures that can be, will be or have been taken to affect context, cause or consequence

Owner: Individual with accountability for maintaining awareness of the exposure from the risk (Known as “keeping an eye on this risk”)

Current status (Eg closed, reducing, increasing, no change, (sufficient) Contingencies are in place) and Date status last checked

Baseline description of activities, reporting points and resources required to:

Create the stage’s products conformant to quality controls described in the Product Descriptions

Provide management resource to review the Issue Log

Ensure day-to-day progress control (within tolerances) of the products that satisfy the objectives of a stage

Created in SB1 by extending the detail from the A30 Project Plan to a level of detail sufficient to detect deviations in a timely manner

Created using organisational standards

Contents consistent with and supports achievement of the Project Plan within constraints of Budget/ Resource/ Schedule

Believable in the eyes of the Team Members

Tracked in CS2 based on information from A3 Checkpoint Reports, CS5 Status reviews and CS7 corrective actions

Description of the plan’s Scope, Approach, External Dependencies*, Tolerances, Assumptions**, Risk Assessment and Resource Constraints

Stage Quality Plan: IE quality control methods, timing and resources for each quality test used for major product

PBS & PFD, Activities, Critical Path Analysis (& identification of activity float) plus budget & cash-flows

Prerequisites*** that must remain in place throughout the stage

Regime for monitoring controls and reporting

 ‘Contract’ between Project Manager (CS1) and Team Manager (MP1)

Ranges in formality from verbal to legally drawn document (Always best if recorded in some form)

Agreement date, Person/ Team authorised

Reporting frequency (and amendments if any to standard Checkpoint reporting), distribution of information TO and from those executing the work package

How to escalate Exceptions & Risks (IE Via Project Issue at CS3 or alternative arrangements)

Configuration Management Procedures (see A5. CMP and A31 PQP) including team version control, access to other relevant CIs, Submission of CIs and advising of CI status changes (eg ready for review)

Constraints such as Health & Safety or Security rules, Charge Rates, Personnel, Timings

(Optionally) Performance appraisal procedures for staff and career development

Definition of work to be done covering

Techniques & processes & procedures, tools and standards to be used

Agreed limits and tolerances on the effort, cost, dates & durations and resource to be used

Relevant sections of Stage (project) plans covering the work scheduled

Product Description(s) for products in work-package scope

Technical Interface definitions completed product(s) must satisfy in operational use

Means to achieve sign-off from product recipients

Amendments to Quality Log and Product Description acceptance and quality criteria, skills and people

Sign-off authorities to be secured for completion

Means of signalling completion to Project Manager and Configuration Librarian