Syllabus: Configuration Management

CM01: Purpose of Configuration Management

19.4.2 Configuration Items

Managing Configuration Identification (2 of 5!)

Example “level” of Identification: Our Stationery

CM01: Purpose of CM (Continued)

CM01: CL’s Involvement In A Product’s Lifespan

Managing The Configuration (Steps 3&4 of 5)

Managing The Configuration (5&1! of 5)

A6 Configuration Management Plan

CM02: The Reasons For Version Control

Baseline & Release

Configuration Management

Configuration Management Ch19

CM03: Products of Configuration Management

CM03: A5 Configuration Item Record

CM06: B9: Configuration Librarian Role

CM06: CL Relationships to Other Roles

CM08: Project CM & Operational CM

Applying PRINCE2®

Configuration Management Practitioner Question

CM04: Filing Structure Appendix E

Project file containing:-

Stage File

E3 Quality File

Recap & Summary

CM 01 describe the purpose of Configuration Management (p)

CM 02 understand version control and the reasons for it (p)

CM 03 identify the products of Configuration Management (p)

CM 04 understand the PRINCE2® filing structure (p)

CM 05 understand the Configuration Management responsibilities and activities of the various PRINCE2® roles within each of the eight processes (p)

CM 06 understand the Configuration Librarian role, & the relationship to the other defined roles (p)

CM 07 understand the relationship between Configuration Management and Change Control (p)

CM 08 understand the relationship between project Configuration Management and any operational configuration management (p)

CM 09 create, modify or discuss the products of Configuration Management in any given project

CM 10 apply Configuration Management to a given project scenario

CM 11 demonstrate how to integrate the requirements of project configuration management with an existing operational configuration management environment for any given project scenario

CM 12 identify the relationship between Configuration Management and other PRINCE2® components within any given project scenario

19.1 A precise discipline to control access to, control changes to, track and report status of approved products

	Key concepts (see next slides): Configuration Item 19.4.2, Baseline 19.3 & Release 19.3.1
	5 Key functions 19.4 Plan, Name things, Store Things, Report from store, Check store’s records
	Maintain communications between all parties of intentions and actions

The Project’s products are its assets

	The combined set of assets is a configuration
	Configuration of a project is the sum total of its products

Holds information on the versions of management and specialist products

	Their status, inter-relationships and the individual with responsibility for each product
	Ensuring changes are only made with agreement of appropriate authorities

A Configuration Item (CI) is:…

	Any product (or sub-product of a product) of the project
	Anything & everything the project must create, amend or acquire whether eventually delivered to the customer, archived or discarded

Anything the activities of the project modifies as a unit

	If we can change its components they are configuration items too
	A hierarchical structure with items we consider atomic at the bottom
	Final product(s) to be delivered to the customer are “at the top”
	A Bill-of-Materials structure

If I buy a car it’s a CI to me

	Air conditioning, sat-nav and alloy wheel options are also CIs
	To the dealer the light bulbs, oil-filters etc may also be CIs
	To the manufacturer the engine, pistons & spark-plugs are CIs
	To the dealer’s bulb maker the filament, glass-envelope and contacts are CIs

Key function number 2*: 19.4.2 Identification of Configuration Items

	Naming products and sub-products
	“Specifying and identifying all components of the final product” 19.4.2 “Each [version of each] product requires a unique identifier” E.G. Project + Type of product + Product title + version number May require further elements within an identifier Eg Variant: Language You are currently reading Project: 5day-PRINCE2® Type: Student Guide (Web) Title: Course Notes Version: 19.0 Live Variant: English

Products named according to a naming scheme set out in the A6 Configuration Management Plan

* Number 1 is Planning & is discussed last - When we know what it encompasses

Protect CIs

	Products are protected from the time they are ready for review onward
	Versions are never changed, always supplanted by a new version
	For controlled documents only copies are released never the masters

Keep records: the Configuration Item Record A.5

	Created as soon as the products identified in PL2
	CS1 Updates CIR’s status to “Work-in-progress” when A36 Work Package started by the team
	Updated to completed by MP3àCS9 (or MP2à CS2 if item in a Work Package completed before the whole)

Key function number 3: Control

	Accepting agreed products into baselines Products baselined when quality review records confirm fit for purpose
	Providing copy-holders access to use or modify products
	Allowing modifications only when duly authorised

Authority is requested using an A33Request For Change (RFC)

	CIR updated with details of the Project Issue affecting the product
	A15 Project Issues submitted to CS3àCS4 for Impact Analysis
	CS5àCS7 implementation within tolerance or CS5àCS8 if exceeding tolerance

Key function number 4: Status Accounting

	Recording and reporting current and historical data in the CIRs for each product Whether work is un-started, in-progress or complete
	Product Status Account A24 may be for any defined sub-set of the project 19.4.4 “A report … on the status of products, … for all … products or just [a subset]

Key function number 5: Verification (aka 19.4.5 Configuration Audit)

Checking (& correcting) that the actual status of all products matches their CIRs Normally carried out by Project Assurance at the end of each stage

Key function number 1: Configuration Management Planning

	Activities (and Documentation describing) “..[the] level of configuration management … required and how this level is to be achieved”
	Specifies the tools, methods, storage areas and responsibilities required

Part of the A31 Project Quality Plan

	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

Composition

	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

Version control provides the capability to distinguish between changes to a product

	Tracks the revision history of a product
	May (manual says “must”) provide access to every version of a product ever created, a subset or just the latest version Always allow an audit trail of the changes made and their triggers

The “Method” to be used in general is described in the Configuration Management Plan A.6

A Work Package A.36 may describe a product specific method

(Customer) Version control is carried out in in CS1 & CS9

Supplier version control carried out in MP1,2 & 3

19.5.2 “… consider whether … management products [are] under … version control

…The Issue, Risk, Quality and Lessons Learned Logs are not normally put under configuration management”

19.3 Baseline

	A snap-shot, frozen in time of a version of a product and all the versions of its sub-products
	For some purpose: often testing

19.3.1 Release

	“A complete and consistent set of products that forms a fixed reference point in the development of the end outcome”
	A base-line that has [is thought to have] also met all of its Acceptance Criteria IE has passed its Quality Reviews
	Can be passed-on to someone to use

A6 Configuration Management Plan

	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
	A6.2 Composition ...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

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

A5.2 Composition

	Project identifier + Type of product + Product title + Latest version number
	Product Description
	The life cycle steps for the product
	‘Owner’ of the product
	A5.2 Composition Continued
	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

Receive, store/ issue and report (via PSA) status of products and Project Issues

	Help identify, name and version number CIs
	(When authorised) Issue revised products and archive old version
	Help conduct Configuration Audits Often primarily performed by Project Assurance
	(Help the PM!?) Create the Configuration Management Plan

Create & administer secure, safe product storage areas

	Custodian and guardian of master copies of the project’s products
	Maintain records of copy holders and issues copies
	Prevent changes to product versions submitted for inspection
	CIs should not be issued for multiple concurrent updates (without procedures to handle clashing updates)

Monitor Project Issues

	Maintains the Issue Log and ensure information held reflects latest issue status
	Assist in identifying affected CIs for impact analysis

May be part of a Project Support Office

	CM of products outlives the project and hands-over to business as usual role
	Liaise with other Configuration Librarians
	Products may be common to other project or systems

19. 7 Configuration management and a Project Support Office

	“most final products will exist in operational use long after the project…
	[therefore] configuration management is usually carried out on an organisation-wide basis…
	Provided from a central [function such as a] Project Support Office
	If the project has been outsourced, the configuration management method used by the supplier needs to be compatible with that … [used to] look after the product during its operational life”

CM 09 create, modify or discuss the products of Configuration Management in any given project

CM 10 apply Configuration Management to a given project scenario

CM 11 demonstrate how to integrate the requirements of project configuration management with an existing operational configuration management environment for any given project scenario

CM 12 identify the relationship between Configuration Management and other PRINCE2® components within any given project scenario

Configuration Management Practitioner Question

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

Re-read the scenario S:5.1 if you need to

There is no ‘Additional Information’ specific to this question, and none of the ‘Additional Information’ specific to other questions will be relevant here

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 exam-time was looking up references in the Red Book?

3 Filing sections: Project file and Quality files plus Stage files for each stage

Original approved A27 Project Initiation Document

Project organisation chart & signed job descriptions

All versions of A30 Project Plans created at stage ends or when changes dictate together with the audit trail (content, dates & reasons, changes to assumptions & resourcing)

All parts of plans (Eg A20 Product Breakdown Structures, A23 Product Flow Diagrams etc)

All versions of the A2 Business Case from each stage and exception

Audit trail of all risks, all analysis & management countermeasures (taken or not)

All versions of all project oriented Appendix A documents from (A29 Project Mandate to A9 End Project Report)

A4 Communication Plan as amended from time-to-time to reflect changing needs and changing stakeholders

One per stage

Details of all work assignments

Including whom assigned plus their performance assessment

All versions of Stage plans as updated

Including, if used, Team and Exception Plans

All versions of all stage oriented Appendix A documents

From A36 Work Package to A3 Checkpoint Reports, A14 Highlight Reports or A12 Exception Reports, to DP3 End Stage or Exception Assessments (ESA or ExA)

Project Manager’s A8 Daily Log of actions, discussions and events

All other (significant) stage oriented records

Supports assessment of how well quality standards are being applied

All versions of the A7 Customer’s quality expectations, A1 Acceptance Criteria and supporting A31 Project Quality Plan and A6 Configuration Management Plan

All versions of the set of A5 Configuration Item Records and A22 Product Descriptions

	Covers every (significant) product of the project
	Cross-references any A28 Project Issues that caused changes to the product

Audit trail of quality inspections planned or held with their results

	Headed by the A32 Quality Log
	Itemised entry for each check, its type (eg quality review), date planned or held, the affected product, references to where complete test documentation is stored, details of participants, actions raised and (eventually) notes of corrections and proof of a positive result (or Concession)

Audit trail of all A33 RFCs, A18 Off-specifications, general queries with results

Held in the A15 Issue Log which indexes, summarises each A28 Project Issue

Any consideration to alter products or plans is a Project Issue managed via Change Control

	Capture, log, categorise (cs3) Issue Log holds any and all of Project Issue, RFC, Off-Spec
	Perform Impact Assessment (CS4) using the Change Control Technique (Ch23) or Log as Risk and perform Risk Analysis
	Take actions via CS7 or CS8-->DP4

Change Control provides control over of changes to management & specialist products

	Resulting work, costs, timescales and thus business case and risk
	Change authority may be delegated by the board (IP1)
	Change budget established to match uncertainties (IP2/PL4 and IP4 -->DP2)

Changed products kept safe by Configuration Management

	Provides identification scheme for all versions of all CIs according to CMP in the PQP CI may be a set of CIs,
	Configuration Librarian creates storage areas and stores products safely, issue products, report on product status and check records are accurate all as required
	Baseline: A preserved CI
	Release: a baseline that has passed it Acceptance Criteria and can be "handed-out"

Filling Structure: 3 parts

1 & 2 Project & Stage: All versions of Organisation, Business Case, Plans, Controls, & Communications on either a project-wide or stage specific basis

3 Quality File: All Quality checking and Issue [handling] Log records, the PQP and all CIRs