
1. Configuration Management Procedure
1.1. [Describe the configuration management procedure to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure should cover activities such as planning, identification, control (including storage/retrieval, product security, handover procedures etc.), status accounting, and verification and audit.]
2. Introduction
2.1. [State the purpose, objectives and scope, and identify who is responsible for the strategy]
3. Issue and Change Control Procedure
3.1. [Describe the issue and change control procedures to be used. Any variance from corporate or programme management standards should be highlighted, together with a justification for the variance. The procedure should cover activities such as capturing, examining, proposing, deciding and implementing]
4. Tools and Techniques
4.1. [Refer to configuration management systems or tools to be used and document techniques that may be used for each step in the configuration management procedure]
5. Reporting
5.1. [Describe the composition and format of the reports that are to be produced (Issue Report, Product Status Account), their purpose, timing and chosen recipients. This should include reviewing the performance of the procedures]
6. Timing of Configuration Management and Issue and Change Control Activities
6.1. [State when formal activities are to be undertaken, for example configuration audits]
7. Roles and Responsibilities
7.1. [Describe who will be responsible for what aspects of the procedures, including any corporate or programme management roles involved with the configuration management of the project’s products. Describe whether a Change Authority and/or change budget will be established.)]
8. Scales for Priority and Severity
8.1. [Document what priority & severity scales will be used to prioritise change and off-specifications. Include what level of management will approve a certain priority or severity]
9. Document information
9.1. Project Name
9.1.1. [name]
9.2. Date
9.2.1. [date]
9.3. Release
9.3.1. Draft/Final
9.4. Author
9.4.1. [author]
9.5. Owner
9.5.1. [owner]
9.6. Client
9.6.1. [client]
9.7. Document Number
9.7.1. [number]
9.8. Revision, Approvals & Distribution
9.8.1. Revision History
9.8.1.1. Revision # [....]
9.8.1.1.1. Revision Date
9.8.1.1.2. Previous Revision Date
9.8.1.1.3. Summary of Changes
9.8.1.1.4. Changes Marked
9.8.1.2. Revision # [....]
9.8.1.2.1. Revision Date
9.8.1.2.2. Previous Revision Date
9.8.1.2.3. Summary of Changes
9.8.1.2.4. Changes Marked
9.8.1.3. Revision # [....]
9.8.1.3.1. Revision Date
9.8.1.3.2. Previous Revision Date
9.8.1.3.3. Summary of Changes
9.8.1.3.4. Changes Marked
9.8.1.4. Date of next revision:
9.8.1.4.1. [....]
9.8.2. Approvals
9.8.2.1. Approval # [....]
9.8.2.1.1. Name
9.8.2.1.2. Signature
9.8.2.1.3. Title
9.8.2.1.4. Date of Issue
9.8.2.1.5. Version
9.8.2.2. Approval # [....]
9.8.2.2.1. Name
9.8.2.2.2. Signature
9.8.2.2.3. Title
9.8.2.2.4. Date of Issue
9.8.2.2.5. Version
9.8.2.3. Approval # [....]
9.8.2.3.1. Name
9.8.2.3.2. Signature
9.8.2.3.3. Title
9.8.2.3.4. Date of Issue
9.8.2.3.5. Version
9.8.3. Distribution
9.8.3.1. Distribution # [....]
9.8.3.1.1. Name
9.8.3.1.2. Title
9.8.3.1.3. Date of issue
9.8.3.1.4. Version
9.8.3.2. Distribution # [....]
9.8.3.2.1. Name
9.8.3.2.2. Title
9.8.3.2.3. Date of issue
9.8.3.2.4. Version
10. How to use this template
10.1. How to share this template with your team
10.1.1. Send an email
10.1.1.1. 1. Click Share this map
10.1.1.2. 2. Select Invite People
10.1.1.3. 3. Write a message
10.1.1.4. 4. Click Invite
10.1.2. Send a link
10.1.2.1. 1. Click Share this map
10.1.2.2. 2. Tick Link to share
10.1.2.3. 3. Copy the link to share it
10.1.3. Export
10.1.3.1. 1. Click down arrow, bottom right
10.1.3.2. 2. Select the export option you want
10.2. How to complete this template
10.2.1. Complete the sections in square brackets
10.2.1.1. [....]
10.2.2. Read these sections for help on the PID
10.2.2.1. Purpose
10.2.2.2. Advice
10.2.3. Navigate using the links in Contents
10.2.3.1. Contents
10.3. Attribution
10.3.1. Copyright © AXELOS Limited 2009. All rights reserved. Material is reproduced with the permission of AXELOS
10.4. Get this template here
11. Overview
11.1. Purpose
11.1.1. A Configuration Management Strategy is used to identify how, and by whom, the project’s products will be controlled and protected. It answers the questions:
11.1.1.1. How and where the project’s products will be stored
11.1.1.2. What storage and retrieval security will be put in place
11.1.1.3. How the products and the various versions and variants of these will be identified
11.1.1.4. How changes to products will be controlled
11.1.1.5. Where responsibility for configuration management will lie.
11.2. Contents
11.2.1. The Configuration Management Strategy should cover the following topics.
11.2.2. Introduction
11.2.3. Configuration Management Procedure
11.2.4. Issue and Change Control Procedure
11.2.5. Tools and Techniques
11.2.6. Records
11.2.7. Reporting
11.2.8. Timing of Configuration Management and Issue and Change Control Activities
11.2.9. Roles and Responsibilities
11.2.10. Scales for Priority and Severity
11.3. Advice
11.3.1. The Configuration Management Strategy is derived from the: The customer’s quality expectations; Corporate configuration management system (e.g. any configuration management software in use or mandated by the user); Programme Quality Management Strategy and information management strategy (if applicable); The user’s quality management system; The supplier’s quality management system; Specific needs of the project’s product(s) and environment; Project management team structure (to identify those with configuration management responsibilities) and Facilitated workshops and informal discussions.
11.3.2. A Configuration Management Strategy can take a number of formats, including: Stand-alone document or a section in the Project Initiation Document; Entry in a project management tool.
11.3.3. The following quality criteria should be observed:
11.3.3.1. Responsibilities are clear and understood by both user and supplier
11.3.3.2. The key identifier for the project’s product(s) is defined
11.3.3.3. The method and circumstances of version control are clear
11.3.3.4. The strategy provides the Project Manager with all the product information required
11.3.3.5. The corporate or programme strategy for configuration management has been considered
11.3.3.6. The retrieval system will produce all required information in an accurate, timely and usable manner
11.3.3.7. The project files provide the information necessary for any audit requirements
11.3.3.8. The project files provide the historical records required to support any lessons
11.3.3.9. The chosen Configuration Management Strategy is appropriate for the size and nature of the project
11.3.3.10. Resources are in place to administer the chosen method of configuration management
11.3.3.11. The requirements of the operational group (or similar group to whom the project’s product will be transitioned) should be considered.