JSP 886 DEFENCE LOGISTIC SUPPORT CHAIN MANUAL VOLUME 7 INTEGRATED LOGISTIC SUPPORT PART 8.12 CONFIGURATION MANAGEMENT

JSP 886 DEFENCE LOGISTIC SUPPORT CHAIN MANUAL VOLUME 7 INTEGRATED LOGISTIC SUPPORT PART 8.12 CONFIGURATION MANAGEMENT THE MASTER VERSION OF JSP 886 IS PUBLISHED ON THE DEFENCE INTRANET. FOR TECHNICAL REASONS, EXTERNAL LINKS ON THIS INTERNET VERSION HAVE BEEN REMOVED. Version Number Version Date Version Description 1.0 23/06/09 Supersedes JSP 586 Volume 4. 1.1 15/07/11 Updated contact details. 1.2 14/02/13 Minor Changes to Format and POC. 1.3 24/06/13 Policy Statement and updated guidance to support the application of Configuration Management (CM) principles for contractual product development and In-Service configuration change. Addition of CM Support Maturity Levels and Domain CM Standards / Processes. 1.4 07/03/14 Part 5: Identification of CM activities for program review and ILS support. 1.5 16/02/15 Chapter 1, minor conceptual change (page 4 paragraph 1) and change to POC.

Contents Contents... 2 CHAPTER 1: CONFIGURATION MANAGEMENT... 4 Context... 4 Precedence and Authority... 4 Mandated Requirement... 5 Policy... 5 CM Policy Statement... 5 Key Principles... 5 Ownership and Points of Contact... 6 General... 6 Definitions... 7 CHAPTER 2: CONFIGURATION MANAGEMENT PROCESS... 8 Configuration Management Responsibility... 8 Configuration Management Planning... 8 CM planning Concept phase (Support to Initial Gate)... 8 CM planning Assessment, Demonstration, Manufacture Phase (Support to Main Gate)... 9 CM planning - In-Service and Disposal (Support to Modification programmes)... 10 Configuration Identification and Documentation... 12 Serial / Lot Numbering... 13 Commercial off-the shelf (COTS) and Non-Developmental items... 13 Product Configuration Information... 13 Configuration Baselines... 14 Configuration Change Management... 18 Change Control - General... 18 Change Control - Responsibilities through life... 18 Change Control - Initiation, Identification and Documentation... 19 Change Control - Evaluation... 20 Change Control Disposition (Approval / Rejection)... 21 Change Control - Implementation and verification of change... 22 Change Control - Categories of Change... 22 Change Control - Concessions... 23 Configuration Status Accounting... 23 Concept phase CSA... 24 Assessment Phase CSA... 24 Demonstration Phase CSA... 24 Manufacture Phase CSA... 25 Delivery to the Authority... 25 In-Service Phase... 26 Disposal Phase... 26 Configuration Status Accounting - Records and Reports... 27 Configuration Audit... 28 Delivery Team interaction with Supplier Configuration Audit... 29 Functional Configuration Audit... 29 Physical Configuration Audit... 30 Software configuration Audit... 31 Final Conference... 32 Configuration Audits of (Non-contracted) In-Service Change... 33 Physical Configuration Audit (PCA) - Checklist... 34 CHAPTER 3: CONFIGURATION MANAGEMENT GUIDANCE... 35 Part 1: Configuration Management Plan Recommended Contents... 35 Part 2: Selection Criteria - Configuration Items... 39 Part 3: Configuration Change Management Responsibilities (Example)... 42 Objectives... 42 Configuration Change Authority... 42 Responsibilities... 42 Composition... 43 Configuration Manager... 44 Part 4: Configuration Management (Support Maturity Levels)... 45 Success Criteria... 45 JSP 886 Volume 7 Part 8.12: Configuration Management Version 1.5 dated 16 Feb 15 2

Part 5: Configuration Management Activities for Program Review and ILS Support... 48 Support Maturity Level 1 User Requirements Definition, Concept Phase and Concept Technology Review... 48 Objectives... 48 Supporting Activities... 48 CM Activities... 48 Objective... 49 Supporting Activities... 49 CM Activities... 49 Support Maturity Level 3 - Preliminary Design Review & Support to Main Gate... 50 Objective... 50 Supporting Activities... 50 CM Activities & Contract Considerations... 50 System Design Review (Non-Support Maturity Level)... 51 Objective... 51 Supporting Activities... 51 CM Activities... 51 Support Maturity Level 4 - Critical Design Review... 52 Objective... 52 Supporting Activities... 52 CM Activities... 52 Integrated Logistic Support... 53 Manage Logistic Configuration... 53 Acceptance of Support Recommendation... 53 Support Maturity Level 5 and 6 Support Solution Validation, Logistic Support Date and Test Readiness Review (TRR)... 54 Objective... 54 Supporting Activities... 54 CM Activities... 54 Support Maturity Level 7 - In-Service Date & Deliverable Product Acceptance... 54 Objective... 54 Supporting Activities... 55 CM Activities... 55 Integrated Logistic Support and Acceptance... 55 Support Maturity Level 8 - In-Service Support Review - Responsibility for revised capability and design integrity (Modification of Configuration Baselines)... 55 Objectives... 55 Supporting Activities... 55 CM Activities... 56 Configuration Status Accounting (CSA)... 57 Functional & Physical Configuration Auditing... 57 In-Service Contract Considerations... 57 Support Maturity Level 9 - Product / System Disposal... 57 Objectives... 57 CM Tasks... 58 Part 6: Definitions... 59 Figures: Figure 1: Configuration Management Process... 9 Figure 2: Example of Product Structure... 12 Figure 3: Configuration Information... 14 Figure 4: Baselines and the CADMID Cycle.... 15 Tables: Table 1 Contractual CM Standards and Domain In-Service Processes for CM (Example)... 10 Table 2: Typical Status Accounting Information throughout the CADMID Cycle.... 27 Table 3: Functional Configuration Audit Checklist... 33 Table 4: Physical Configuration Audit Checklist... 34 JSP 886 Volume 7 Part 8.12: Configuration Management Version 1.5 dated 16 Feb 15 3

CONTEXT CHAPTER 1: CONFIGURATION MANAGEMENT 1. The MOD acquires products which may be subject to alterations and updates throughout a project life-cycle. Therefore, it is essential that the product or system performance, physical and functional attributes can be compared with the design and operational requirements at any time. 2. Configuration Management (CM) is a management activity that enables the documented status of the product or system to be known at any time. The application of through life CM can ensure a disciplined approach for product development and maintain design integrity through life. 3. The identification of Configuration Items (CIs) within a product breakdown structure and associated product configuration information can provide the framework for structured arguments that underpin the product / system safety case. 4. Configuration Management supports the Requirements Management role for control, monitoring and administration of capability requirements; by tracking the implementation of the requirements. The evaluation of CI Configuration Baseline information against requirements documentation and use of Functional and Physical Configuration Audits can help to assure that capability requirements are met. 5. Configuration Management supports the Management of Design through life in JSP 886, Volume 7 Part 10 and the configuration of Integrated Logistic Support products as expressed in JSP 886 Volume 7 Part 2, Chapter 2. 6. CM strategies and planning by the Delivery Team and Supplier can be used to provide the basis for the assurances required by the Support Solutions Envelope (SSE), Governing Policy 2.5: Configuration Management; see JSP 886 Volume 1 Part 3. 7. The lack of Baseline configuration information can lead to the need for costly corrective action to establish the required information for the continued use, or further development, of a particular product or system. The investment for CM is returned by reductions associated with the costs for intervention, corrective action, risk and possible liability. PRECEDENCE AND AUTHORITY 8. When ever there is a conflict between this document and the contractual standards identified in Paragraphs 13 and 14, the requirements of the contractual standards take precedence. 9. One of the roles of the MOD Quality Assurance Authority (QAA) is to define CM Policy requirements, for MOD organisations or individuals in the Acquisition of defence equipment through life. 10. Quality and Configuration Management (Policy) as the executive arm of the MOD QAA sets a framework of CM policy, contractual standards and guidance for the Acquisition community. CM Policy is detailed within this JSP 886 Volume and within the Acquisition Operating Framework. JSP 886 Volume 7 Part 8.12: Configuration Management :Chapter 1 Version 1.5 dated 16 Feb 15 4

11. The Delivery Team Leader is ultimately responsible for the implementation of Configuration Management Policy for the duration of the project lifecycle and must appoint competent personnel to ensure effective application of through life CM policy. MANDATED REQUIREMENT 12. To meet the MOD duty of care obligations, product configuration information shall be provided or made available with all products, systems and equipment Configuration Items. POLICY 13. UK National programs requiring contractual product design and development should invoke Defence Standard 05-57: Configuration Management of Defence Materiel within Invitations to Tender (ITT) and subsequent contracts. 14. To fulfil the agreements in STANAG 4159 and STANAG 4427, Joint International programmes requiring contractual product design development should invoke the Allied Configuration Management Publications (ACMP - 1 to 6) in ITT and contracts. 15. Although Configuration Management may be contracted with a Supplier - Design Organisation, the Authority s role as the Decider with an Industry role as the Supplier must be maintained through out the life of the contract, including availability type contracts where airworthiness and duty holder responsibilities must be fulfilled. 16. The aims of the following CM Policy Statement must be considered through life: CM POLICY STATEMENT 17. All requirements generated by the Authority for output based specification are to be developed under a change management system for contractual baseline. 18. All platform systems and components that are to be owned and operated by the Authority and designated as Configuration Items (CI)s; shall be designed, developed and produced under a formal configuration change management system and delivered against a formally recorded and approved configuration baseline. 19. Product CI configuration information is to be made available for the Authority s In- Service requirements. 20. Change to the delivered product Configuration Baseline is to be established under a formal configuration change management system to ensure the integrity of design In- Service. KEY PRINCIPLES 21. Configuration Management is a management activity that applies technical and administrative direction, focusing upon the product physical and functional characteristics to ensure conformance with requirements and to control the change of formally approved Configuration Baselines. Operational information is contained in Configuration Documentation and realised in the product or system design and supporting information. The use of the inter-related CM principles is detailed in Chapter 2. 22. The Acquisition process usually requires an Industry Design Organisation to be responsible for product or system development; therefore CM is often managed by JSP 886 Volume 7 Part 8.12: Configuration Management :Chapter 1 Version 1.5 dated 16 Feb 15 5

Industry under contract, on behalf of the Authority. Within this arrangement the Delivery Team must ensure that the delivered product / system will have a formally recorded and approved Configuration Baseline. OWNERSHIP AND POINTS OF CONTACT 23. The owner of this Policy is Director Joint Support Chain (D JSC). Head of Supply Chain Management (Hd SCM) is responsible for the management of JSC policy on behalf of D JSC. The policy sponsor for this document is. DES TECH-QSEP QCM-Pol-SkC4. 24. Enquiries concerning the content of this instruction should be addressed as follows: 25. For enquiries on the Technical content to the policy sponsor: DES TECH-QSEP QCM-Pol-Int6 Tel: 07760 990522 26. For enquiries on accessibility and presentation: ACDS LOGOPS-Def Log Pol-JSP886 (MULTIUSER); Tel: Mil 9679 Ext 80953. Civ: 030679 80953Associated Standards, Guidance and References GENERAL 27. The following Associated Standards, Guidance and References apply: a. Defence Standard 05-57: Configuration Management of Defence Materiel Issue 5, dated June 2005. b. STANAG 4159, Edition 2 Amendment 1: NATO Configuration Management Policy and Procedures for Multinational Joint Projects. c. STANAG 4427, Edition 2: Introduction of Allied Configuration Management Publications. d. BS ISO 10007:2003: Quality Management System: Guidelines for Configuration Management. e. DEFCON 117: Supply of Documentation for NATO Codification. f. Defence Standard 05-10: Product Definition Information. g. Defence Standard 05-61 Part 1: Concessions. h. JSP 886, Volume 7 Part 2: Chapter 2: ILS Management. i. JSP 886, Volume 7, Part 10; Chapter 2: Manage Design Through Life. j. JSP 886, Volume 7 Part 8.14: Management of Items Requiring Special Identification. Air Environment: k. MAA Regulatory Articles: 5000 Series. JSP 886 Volume 7 Part 8.12: Configuration Management :Chapter 1 Version 1.5 dated 16 Feb 15 6

l. Maintenance Airworthiness Process (MAP) 01, Issue 4 dated Sep 12. Maritime Environment: m. BR 1313: Maintenance Management in Surface Ships: Chapter 4: Configuration Management and Ship Fit Definition. n. BRd 8593(17): Addition and Alteration (A&A) Procedures and Modifications in Surface Ships. Land Environment: o. JSP 886 Volume 5, Part 2A: Configuration Management, Land Modifications. DEFINITIONS 28. See Definitions and Abbreviations in Chapter 3 Part 6. JSP 886 Volume 7 Part 8.12: Configuration Management :Chapter 1 Version 1.5 dated 16 Feb 15 7

CHAPTER 2: CONFIGURATION MANAGEMENT PROCESS CONFIGURATION MANAGEMENT RESPONSIBILITY 1. A Configuration Change (Dispositioning) Authority 1 must be identified at all times throughout the product lifecycle to make decisions on product configuration as defined in the requirements for design, realisation, verification, operation and support. 2. The Configuration Change Authority can also be known as the Configuration Control Board (CCB) and should include interested stakeholders. CONFIGURATION MANAGEMENT PLANNING 3. Configuration Management (CM) planning should identify the processes, procedures, responsibilities and authorities for the effective application of the CM principles within the context of the contractual and project lifecycle requirements. 4. The programme complexity and nature must be considered by CM planning to enable the effective and efficient application of the following CM principles: a. Configuration Identification and Documentation. b. Configuration Change Management. c. Configuration Status Accounting. d. Configuration Audit. 5. CM planning should be controlled and approved. 6. The requirement for typical CM Plan in Chapter 3, Part 1 should be followed while considering the planning guidance below. The interaction of the CM principles indicated by the CM Process, Figure 1, should also be considered. CM PLANNING CONCEPT PHASE (SUPPORT TO INITIAL GATE) 7. Concept Phase planning should identify the CM processes required from project initiation to the beginning of Assessment Phase. At this stage of the project lifecycle, this planning should include a CM strategy of management intent for the subsequent Assessment Phase through to product delivery. 8. The CM strategy should include the relevant CM contract standards for Invitation to Tender (ITT) together with supplier assessment criteria that may include the need for high level CM planning from the ITT respondents. 9. CM planning should identify the process / procedure(s) to approve and authorise the release of the User Requirements Document (URD) for development of the System Requirements Document (SRD). 1 Dispositioning Authority - A person or group of persons, assigned responsibility and authority to make decisions on product configuration as defined in the requirements for product design, realisation, verification, operation and support (ISO 10007). JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 Version 1.5 dated 16 Feb 15 8

f. The requirements for disposal and the need to uniquely identify product CIs (eg Part number + Serial number) during manufacture to enable through life tracking and disposal management. g. The need to identify and record the Configuration Items (CIs) for System of Systems integration, where capability is to be achieved by the Systems of Systems approach. h. A requirement for a deliverable CM plan from the Supplier, dependent upon the complexity and nature of the programme. CM PLANNING - IN-SERVICE AND DISPOSAL (SUPPORT TO MODIFICATION PROGRAMMES) 12. During the In-Service phase when the Authority has accepted the product / system from the initial development contract the Delivery Team Leader has responsibility for configuration change management. Examples of In-Service Change Management procedures specific to each domain are identified in Table 1 below. 13. CM Planning should include: a. The contractual CM policy and advice contained in this JSP. b. The relationship between the In-Service Configuration Change Authority and the subsidiary change management committee(s), see Chapter 3, Part 3 for guidance. 14. Where a Supplier is contracted for In-Service changes to the product, the Delivery Team should ensure that Supplier s CM planning identifies the interaction between the Supplier and the Authority s In-Service Configuration Change Authority and configuration change management processes. Table 1 Contractual CM Standards and Domain In-Service Processes for CM (Example) Generic Contract Standards for CM UK National Contractual Requirements. Joint International Contractual Requirements (NATO Nations) Air Sector Contractual and Regulatory Articles JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 Version 1.5 dated 16 Feb 15 10 Defence Standard 05-57 Configuration Management of Defence Materiel Issue 5 dated Standard 05-10 Product Definition Information Allied Configuration Management Publications 1 to 6 Air Domain Standards for CM RA 5221 - Traceability of Aircraft Identifiable Parts. RA 5301 Control of Designs. RA 5302 Design Records. RA 5303 Local Technical Committee. RA 5304 Configuration Control Board. RA 5305 Modification Classification. RA 5306 Draft Modification Leaflets. RA 5307 Identification and Recording of Design and Modification States of Materiel. RA 5308 Service Modifications. RA 5308 Annex A Overview of Service Modification Process. RA 5311 - Configuration Management - Project Team (CM planning). RA 5312 In Service Design Changes. RA 5313 Design Modifications. RA 5602 Control of Engine Critical Parts.

In-Service Processes Contractual Standards Key Processes In-Service Submarine In-Service Submarine (ISM) Business Processes (BP) (Examples) Note: See ISM Controlled Document Index for full list Key Processes Surface Ship RA 5603 Design Change Approval an Validation of Modifications. RA 5721 Systems Integrity Management. RA 5722 Propulsion Integrity Management. RA 4350 Technical Information Management RA 4353 - Amendment to Technical Information (MAP) 01, Chapter 10 - Maintenance Airworthiness Process Configuration Control. Maritime Domain Standards for CM DEFSTAN 21-12 Master Record Index DEFSTAN 21-13 Combat System Interface and Link Documentation Including use of SiCA database for sharing of interface information between products when used on a single platform. DEFSTAN 02-38 Requirements for the Preparation, Identification and Management of Datum Pack Drawings and Photographs for Swiftshure, Trafalgar and Vanguard Class Nuclear Submarines. DEFSTAN 02-41 (NES 41) - Requirements for Configuration Management of Surface Ships. DEFSTAN 21-88 - Policies and Procedures for Combat Integration of Surface Ships. DEFSTAN 02-28 - CM- Nuclear Submarines - In Service Support. Maritime Domain Processes for CM Key Process 2.20 Preserve Design Intent Key Process 2.30 Manage Design Change Key Process 2.31 End to End Design Change processes Key Process 2.32 Implement a Design Change Key Process 2.34 Unauthorised Design Changes (Amnesty process) Key Process 2.41 Manage Requirements Key Process 2.50 Manage Design Information ISM Authorisation Condition 22 Modification or experiment on existing plant. BP 1.11 287 Control of Organisational change and production of submissions BP 2.30.400 Change Impact Assessment Procedure (CIAP) BP 230.817 Completion of Safety Requirements - Proposed Change BP 232.505 Obtain Clearance for use of Design Change Equipment BP 232.713 Process an Submarine Alteration and addition to Approval BP 232.714 Process a Class Modification to Approval BP 2.5.401 - Requirements for the Exchange of Information with CRISP and Maritime Information Group. BR 1313 Maintenance Management in Surface Ships Chapter 4 Configuration Management and Ship Fit Definition. BRd 8593(17) Addition and Alteration (A&A) Procedures and Modifications in Surface Ships. Land Domain - In-Service Process for CM JSP 886 Volume 5 Part 2A: Configuration Management, Land Modifications. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 Version 1.5 dated 16 Feb 15 11

22. CIs are usually identified by part numbers and naming convention. The Supplier Designer will usually use its own numbering system and maintain traceability between the Supplier s identification numbering and the NATO Stock Number (NSN). 23. Where CIs are designated for the MOD Supply System, a NSN must be established for each item of supply. The contractual requirement for NSN support is invoked by DEFCON 117: Supply of Documentation for NATO Codification. Note: When a change to a CI affects the fit, form or function, it will affect the Configuration Baseline. The revised CI must be identified with a new NSN to differentiate this new CI from the earlier CI version. SERIAL / LOT NUMBERING 24. Serial / Lot Numbers must be unique, consecutive, and non-duplicating for all items with a specific nomenclature. The original Serial Number of a unit / item / CI must not be changed even when a change affecting interchangeability may require rework and reidentification. Once assigned, Serial Numbers must not be reused for the same item / CI. (ACMP 2). Further information regarding the use of serial numbers is contained in JSP 886, Volume 7 Part 8.14: Management of Items Requiring Special Identification. COMMERCIAL OFF-THE SHELF (COTS) AND NON-DEVELOPMENTAL ITEMS 25. Commercial off-the-shelf items are not to be considered as CIs unless these COTS items are to be the subject of re-development under contract. 26. Suppliers must not develop COTS items supplied as Government Furnished Equipment / Assets (GFE / GFA), unless the Supplier seeks the approval of the Authority s Representative who is to ensure that the revised COTS item is identified as a CI with unique identification to differentiate from the original COTS item. PRODUCT CONFIGURATION INFORMATION 27. The illustration at Figure 3 shows the generic categories of product CI information and how they relate. The two major sets of information for each CI are the product definition (physical and functional requirements) and the operational information that must be traceable. All physical and functional information necessary to define a CI must be documented. (ISO 10007). 28. Defence Standard 05-10 Product Definition Information should be considered when Drawings are contractually required from the Supplier. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 Version 1.5 dated 16 Feb 15 13

Figure 3: Configuration Information. CONFIGURATION BASELINES 29. Configuration Baselines should be established as a reference for further activities / future change. A Configuration Baseline consists of the approved configuration information to satisfy the requirements for design, verification, operation and support. (Reference ISO 10007) 30. Configuration Baselines provide stakeholders a mechanism for common understanding and an assurance that the product or system meets the contractual requirements. The level of detail for Configuration Baseline depends upon the degree of control required. 31. The recognition of a contractual deliverable Configuration Baseline provides the basis for In-Service configuration change by the Authority and contractual arrangements for Modification. 32. Before any product configuration documentation or data set is considered for baseline, it must be reviewed to ensure that the document is complete and valid for use. 33. Traditional CM practices can recognise the following product documentation baselines shown in Figure 4: JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 Version 1.5 dated 16 Feb 15 14

e. Critical Design Review (CDR). To baseline System design for production / manufacture. The CDR assesses the technical solution to ensure it has an expectation of meeting the URD and the SRD. A CDR normally occurs during the Demonstration phase prior to the transition to the Manufacture phase. f. Test / Trials Readiness Review (TRR). Agreement to commence System testing. At the TRR the whole system is assessed for readiness to undergo trial or test in the appropriate environment. A TRR can take place at any time but usually only once the whole system can be brought together. 35. Product configuration information established for the design reviews described above can also be used to evaluate the Support Maturity Levels (SML), see Figure 5 and the configuration management measures of effectiveness for each SML in to Chapter 3 Part 4. 36. The measures of effectiveness for each SML should be agreed with the supplier and included in the development or support contract. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 Version 1.5 dated 16 Feb 15 16

Figure 5; Configuration Management Relationship and Baseline Support to Product Requirements, Acceptance and Design Review JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter Version 1.5 dated 16 Feb 15 2 17

CONFIGURATION CHANGE MANAGEMENT Change Control - General 37. Configuration change management is applied through the process of establishing baseline reference points from which to control change. A Baseline reference point consists of a documented product definition baseline, which can include but not limited to; design information, software version documentation and associated validation and operational information. 38. A change to a Baseline can be initiated by the need to implement regulatory, safety, quality, or performance improvements including supportability arrangements or a need to meet new requirements for improved capability. 39. The purposes of configuration change management are to ensure: a. Control of Configuration Baselines. b. Consistency between product and product configuration information. c. Communication of change information. d. Change decisions understand the impact of change. e. Changes are necessary or offer significant benefit. f. Stakeholder interests are considered. g. Product interfaces are controlled. h. Concessions - are recorded and managed. i. Products are supportable after change. 40. Classified data, essential to the evaluation and disposition of change, should be submitted separately in accordance with the approved security procedures. CHANGE CONTROL - RESPONSIBILITIES THROUGH LIFE 41. A Supplier Design Organisation will be required, under the terms of the development contract, to ensure that configuration change management is applied to product / system development up to the delivery of the product baseline for In-Service use. 42. Once the product design drawings are completed under contract and sealed (design freeze) the supplier relinquishes Configuration Change Authority control, and therefore can no longer make changes unilaterally. At this point, the responsibility for configuration change decisions is transferred to the Authority s Delivery Team Leader responsible for In- Service design integrity. 43. The Delivery Team Leader is supported by a Configuration Control Board (CCB), subsidiary committee (s) and personnel with configuration management responsibilities. Note: Examples of Configuration Change Management responsibilities for the CCB, subsidiary committee (s) and configuration manager are contained in Chapter 3 Part 3. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 18

g. Insertion of new technology. h. Correct defects (both preventive and corrective). i. Improve product support. 49. Prior to submission for valuation to the Configuration Change Authority all Change Proposals should be identified and documented. 50. ISO 10007 advises that Change Proposals should typically include the following information: a. Configuration item(s) and related information to be changed, including details of their title(s) and current revision status. b. A description of the proposed change. c. Details of other configuration items or information that may be affected by the change. d. The interested party preparing the proposal, and the date it was prepared. e. The reason for the change. f. The category of the change. 51. To support the evaluation of Change; additional details can include: a. Design, development and testing involved. b. Operational and maintenance documentation updates. c. Training requirements. d. Products affected, ie products in build and / or retrofit to existing product. e. Effects on spares and replacements. f. Interfaces with other equipment. 52. Further change management considerations during the In-Service phase are identified in Defence Standard 05-57, Annex D: Example Modification Proposal Form. The MOD Delivery Team and the Supplier may utilise or develop this Example Modification Proposal Form. Completion details are contained in Defence Standard 05-57. 53. In-Service configuration change across the MOD Domains is usually managed using the Modification and Alterations & Additions processes detailed within the Contractual Standards and processes identified in Figure 1. CHANGE CONTROL - EVALUATION 54. Evaluations of proposed changes must be documented and consider the risk / potential impact. The extent of an evaluation will depend upon the product complexity and change category, see paragraphs 61 to 66. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 20

c. Who will incorporate the change? (Reference ISO 10007). CHANGE CONTROL - IMPLEMENTATION AND VERIFICATION OF CHANGE 59. Considerations when implementing and verifying authorised change are: a. The release of product configuration information to relevant stakeholders. b. To ensure that action is taken by relevant stakeholders affected by the required change. c. Establish records of compliance with the authorised change. (Reference ISO 10007). Figure 8: Implementation and Verification of Change. Approved Change Proposal Plan verification and implementaiton Update product configuraiton information Update baseline (CSR) Update affected support elements Arrange retrofit to existing products Verify change Modified Product Updated configuration baseline 60. Stakeholders responsible for the change implementation must verify with the In- Service Configuration Control Authority or subsidiary committee that required change is implemented. This verification must be recorded to allow traceability. CHANGE CONTROL - CATEGORIES OF CHANGE 61. The categorisation of Alterations & Additions and Modifications for Surface Ships is detailed within BRd 8593 (17) Addition and Alteration (A&A) Procedures and Modifications in Surface Ships. 62. The Air Domain modification classifications are detailed within the Military Air Authority (MAA) Regulatory Article 5305 and MAP 01, Chapter 10 - Maintenance Airworthiness Process, Configuration Control. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 22

63. The Land Domain In-Service modification categories are detailed in JSP 886, Volume 5 Part 2A. 64. Supplier s proposing engineering changes, may wish to classify an Engineering Change Proposal (ECP) as either a Class I or Class II. An ECP shall be a Class I if the product Configuration Baselines, once established, are affected to the extent that the contract requirements are not met, or change to the Product Baseline, once established, impacts one or more of the following: a. Government Furnished Equipment (GFE). b. Safety (to include safety critical software). c. Security. d. Deliverable computer software. e. Compatibility or interoperability with interfacing items. f. Delivered operational and maintenance manuals. g. Interchangeability or replace-ability. or h. Skills, manning, training, biomedical factors or human engineering design. 65. Class I changes must be agreed by the Authority s representative and communicated to the Configuration Change Authority- CCB. 66. Class II ECP addresses all changes not classified as Class I. The Delivery Team Leader should have the ability to review Class II changes for concurrence of Class 1. (Reference ACMP 3) CHANGE CONTROL - CONCESSIONS 67. Concessions are contractual non-conformities and do not affect the product or system configuration baseline. A concession is generally limited to the delivery of the product that has nonconforming characteristics within specified limits for an agreed time or quantity of that product. (Reference ISO 10007). 68. Concessions form part of the Status Accounting records for a particular baseline, the management of Concessions should be contractually invoked in accordance with the Defence Standard 05-61, Part 1 Concessions. CONFIGURATION STATUS ACCOUNTING 69. Configuration Status Accounting (CSA) is the activity that results in records and reports that relate to product configuration information. (ISO 10007) Effective configuration management relies upon the availability of the up-to date product configuration information and the communication of change(s) to relevant stakeholders in a timely manner. Examples of through life CSA information is shown in Figure 9 below. 70. The depth and range of the information captured in the CSA should be based the nature of the product, the environment in which the product will be operated, the JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 23

b. Manufacturing. c. Testing and verification procedures. d. Change activity and history of the proposed and incorporated change requests. e. The effect of any change. f. Status and history of variants. 74. If the design of the product evolves, a record of the release of each product configuration information document, and subsequent revision to update the design baseline, is entered into the configuration accounting system. The accompanying data of this record s release will detail the applicability of the updates. 75. The following documented,configuration management information can require updating and implementation to reflect the evolving design of the product; a. SRD. b. Maintain URD. c. Configuration Management Plan. d. Requirements acceptance criteria. MANUFACTURE PHASE CSA 76. The information produced during the previous stages should be available for the manufacture phase. The information recorded in the database from the manufacture phase should include: a. The as built configuration of each product CI (by Serial number) including installation and removal of serialised and lot numbered components. b. The identities and product unit Serial numbers, which constitute the applicability of each approved major engineering change; the identifiers of the changes that have been released for any specific Serial numbered unit of a product. c. Superseded configuration records that reflect prior configurations of the product. DELIVERY TO THE AUTHORITY 77. The delivery of a product to the Authority should meet the requirements of the Contract Data Requirements. Other considerations during the delivery of a product may include: a. Delivery dates. b. Installation configuration. c. Warranty expiration dates for each unit delivered or installed. d. Service agreement type and expiration. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 25

e. Training requirements. IN-SERVICE PHASE 78. Configuration status accounting during the in-service phase will vary greatly depending on the support implications / requirements; and any legal requirements placed on the type of product to support capability to fulfil operational requirements. The additional information shall be maintained on the configuration status accounting system during the in-service phase: a. As-maintained and as-notified baseline of the product. b. Product operation and maintenance information revision status. c. Information change requests and change notices. d. Restrictions or concessions on use of the product. e. Product performance degradation. f. Training requirements. DISPOSAL PHASE 79. Configuration status accounting during the disposal of a product in a cost effective and safe manner will depend on: a. If disposal of the product has adverse environmental implications. b. If the product requires a replacement. c. If the product is to be salvaged. Note: The disposal of some product will have legal and contractual implications that must be considered. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 26

80. Typical status accounting throughout the CADMID cycle is shown in Table 2: Table 2: Typical Status Accounting Information throughout the CADMID Cycle. Life Cycle Phase C A D M I D Typical CSA Information And Activity Which Is Tailored To Suit Product And Project User Requirements Document (URD). System Requirements Document (SRD). Product structure / hierarchy information. Functional baseline. Design baseline. Product baseline. Configuration documentation. Configuration documentation change proposals. Configuration documentation change records. Change request proposal. Change request records. Product change request proposal. Product change request records. Concession and variance records. Verification / audit reports and actions. Usage records. Shelf life records. Product operation information / records. Product maintenance information / records. Restrictions (operational / facilities / etc). Product replacement information. Product interchangeability information. Product interface information. Product safety restrictions. Product environmental restrictions. Product salvage information. CONFIGURATION STATUS ACCOUNTING - RECORDS AND REPORTS 81. Configuration status accounting records are created during the configuration identification and change management activities. These records capture the process of configuration change and the product configuration information associated with contractual deliverable configuration Items; and continues for all subsequent In-Service baseline changes. 82. Throughout the product lifecycle the integrity and retrieval of configuration status records are to be protected from corruption / un-authorised change and retained in systems that permit retrieval and provide a means for disaster recovery. (ISO 10007). 83. Configuration status accounting reports provide the details and status of the configuration items (CIs) that are associated with the contractual deliverable product / system baseline. Records and reports are required for In-Service configuration management. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 27

84. The Configuration status accounting records for the deliverable Product Baseline (PBL) should be certified for accuracy by the Supplier / Design Organisation responsible for each CI, prior to the approval for production and before acceptance of the Authority s Representative. 85. A complete product Configuration status accounting record should provide an overview of the constituent CIs by means of a family tree, to a level of detail agreed by the Delivery Team Leader and as defined in the contract conditions. 86. Commercial database package output should be compatible with the Authority s data import requirements. The format of the deliverable CSR should be compatible with the Authority s data import requirements, as specified in the contract. 87. The Configuration status accounting records and reference systems should: a. Provide a record for each CI by reference to part numbers, drawings lists and specifications of the planned, current and all earlier approved baselines including, where applicable, those of variants and those of ancillary items such as change / modification sets and kits, special tools, handling equipment, special to type test equipment and packaging. b. Identify any feature in the product with safety or operational implications that may require special tests or examinations. c. Provide a product breakdown structure showing the relationship of all the CIs making up the product by reference to drawings list numbers and/or an illustrated parts catalogue. d. Identify Non-Development / Commercial-off-the-shelf (COTS) & Government Furnished Assets (GFA) Items. e. Enable higher level CIs to be cross-referred to the subsidiary and associated CIs. f. List all items used in support of the product, such as special tools, design tools and models, special to type test equipment, handling equipment and packaging. g. Provide a baseline for each CI from which to define the subsequent as-fitted and future modification states of the product throughout its service life. h. Record the change status of the product by providing a reference to the change record of each CI, for all authorised modifications, amendments and system changes. CONFIGURATION AUDIT 88. Configuration Audit is a formal examination to verify that the requirements of the product configuration information are realised by the product / system Configuration Items (CIs). There are two types of audit: a. Functional Configuration Audit (FCA). b. Physical Configuration Audit (PCA). JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 28

89. Benefits of Configuration audit include: a. Validation for the integrity of the configuration documentation. b. Verification of consistency between a product and its configuration documentation. c. Determination that an adequate process is in place to provide continuing control of the configuration. DELIVERY TEAM INTERACTION WITH SUPPLIER CONFIGURATION AUDIT 90. The need for configuration audit is part of the contracted CM conditions; see MOD Policy in Chapter 1. The review of Supplier configuration audits reports of product or system CIs can help to obtain assurances for product verification. 91. The configuration audit schedule should be compatible with the availability information. eg engineering data, specifications, manuals, hardware / software product design information and reports. FUNCTIONAL CONFIGURATION AUDIT 92. A Functional Configuration audit (FCA) consists of the formal examination of test data and quality assurance records for a CI, prior to acceptance of the Product Baseline, to verify that the CI has achieved the performance and functional characteristics specified in the associated requirements configuration documentation. 93. An FCA should be conducted for each CI, or group of CIs, for which a separate development / requirement specification has been baselined. 94. By the end of the Assessment Phase and during the Demonstration Phase; Functional Configuration Audit (FCA) of CIs should be established, the results of which should be recorded and any action required taken. 95. During development a product usually goes through a series of builds, each version being progressively built towards the production model. Each model is tested against the conformance requirements as the functionality is progressively developed. During this development the following points may be considered: a. If a prototype or pre-production models are not to be produced, then the test data can be collected from the testing of the first production item. b. For complex System CIs, the FCA may be completed in increments. In such cases, a final FCA can be conducted to ensure that all the requirements have been satisfied. c. In cases where CI verification can only be completed after system integration and testing, the final FCA can be conducted along with the PCA. 96. The FCA can include a requirement to review the following test information: a. Compliance test procedures. b. Results from the compliance tests. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 29

c. Test plans, specifications, descriptions, procedures and reports for the CI. d. A complete list of the successfully accomplished tests during which preacceptance data is recorded. e. A complete list of tests required by the test requirements but not yet performed, ie, to be performed as a system or subsystem test. f. Pre-production test results. g. An audit of formal test plans, specifications and procedures and compared against official test data. The results will be verified for completeness and accuracy. h. Interface requirements and the testing. i. All changes to product design and to test equipment to ensure that they have all been incorporated and completed. j. Design Reviews and Critical Design Review minutes; to ensure that all findings have been incorporated and completed. 97. An FCA audit report should be produced to detail the findings that should include: a. Test procedures and reports viewed and any deficiencies found. b. Completion dates for all discrepancies for agreement at the post audit meeting. PHYSICAL CONFIGURATION AUDIT 98. A Physical Configuration Audit (PCA) is the formal examination of the as-built configuration of a CI against its design documentation to ensure that the CI conforms to its specified physical requirements. 99. PCA should be established against the proposed production CI, (First Article Inspection) to assure that the requirements are met, prior to the Product Baseline. The PCA should not be started unless the FCA of the CI has already been successfully completed or is being carried out concurrently with the PCA. 100. During the PCA any differences between the physical configurations of the selected production CI and the development CIs used for the FCA should be evaluated to assure no degradation of the functional characteristics of the selected CI. 101. The Configuration Change Management control mechanism should be considered for audit to ensure that it correctly controls all internal and external changes. 102. The PCA should: a. Determine that the acceptance testing requirements prescribed by the documentation is adequate for the acceptance of CI production units by quality assurance activities; b. Include detailed audit of product design documentation, specifications, technical data, and tests utilised in the production of the CI, and consider operation and support documentation. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 30

c. Include an audit of the released product configuration documentation and quality control records to make sure the hardware as built or software as coded configuration is reflected by this documentation. d. For Computer Software CIs (CSCIs) the product specification, Interface Design Document and Version Description Document should be considered by the PCA. 103. PCA considerations should assure that: a. Product design information and associated manufacturing processes are incorporated into the CI. b. Release records identify all relevant product design information. c. Outstanding changes to the product is recorded within relevant product design information. 104. CI configuration information and audit reference information can include: a. FCA report. b. CI specification / design information drawing Part Number. c. Identification - Part Number with possible Serial Number. d. Identification - approved nomenclature / nameplates. e. A list of CI approved and outstanding changes. f. List of concessions against the CI. g. Acceptance test procedures and associated test data. h. Operating and support publications, including all Maintenance manuals. i. Quality Assurance records for each CI. j. Complete shortage list. k. Recommended Spares List. l. Release documentation. m. Proposed Certification of Design. n. Draft Configuration Status Records. SOFTWARE CONFIGURATION AUDIT 105. The CM principles apply equally to hardware and software development and change management. The following software considerations should also be considered by CA: a. Compare detailed design descriptions with the software listing for accuracy and completeness. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 31

b. Examine CSCI delivery media (disks, tapes, etc.) to ensure conformance with the software requirements specifications. c. Review the annotated listings for compliance with approved coding standards. d. Review all required operation and support documents for completeness, correctness, incorporation of comments made at critical Design Review, and adequacy to operate and support the CSCI(s). e. Ensure that configuration documentation details the relationship of the CSCI to the parts, components or assemblies and that executable data is properly described. For Firmware, ensure that the information completely describes the requirements for installation of the CSCI into the programmable parts or assemblies and that this information has been properly implemented. Where follow-on Acquisition of the firmware items is intended, ensure that the documentation has been accomplished to the level of detail necessary for the intended procurement. f. Using deliverable or Authority owned support software, assure by demonstration that each CSCI can be generated. The regenerated CSCI shall be compared to the actual CSCI delivery media to ensure that it is identical. FINAL CONFERENCE 106. The Authority s Authorised Representative should summarise the findings of the PCA from their perspective, and should identify all relevant remedial actions and corrective action (Discrepancies). A summary report should be available to all Authority s and Supplier team members. 107. All outstanding contractual requirements should be reviewed and any liability issues resolved. 108. The Supplier representative should summarise the Supplier s reactions and acceptance of the Authority actions on the Supplier in respect of: a. Certification of the CI. b. Outstanding contractual issues in respect to the CI. c. Outstanding liability issues (if any). 109. Post PCA actions: a. The Supplier should be notified in writing by the Authority of acceptance or rejection of the PCA, the PCA status and comments, criticisms to be corrected, or rejection of the PCA and requirements for re-accomplishment. b. The Supplier should, after completion of the PCA, publish and distribute copies of the PCA as specified in the contract. 110. The Product configuration management design and operational information should be sealed for Production initiation. JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 32

CONFIGURATION AUDITS OF (NON-CONTRACTED) IN-SERVICE CHANGE 111. When not contracted with a Supplier / Design Organisation, the Delivery Team Leader is responsible for Configuration Audit of In-Service changes affecting the CI functional, physical and operational characteristics. In addition to the configuration audit guidance given above, see the Functional Configuration Audit Checklist in Table 3, and the Physical Configuration Audit Checklist at Table 4 below. Table 3: Functional Configuration Audit Checklist Functional Configuration Audit (FCA) Checklist CI Description Date: CI/CSCI Identifier: Release No. Requirements Yes No NA 1. Facilities for Conducting FCA Available. 2. Audit Team members have been identified and informed of audit. 3. Audit Team members are aware of their responsibilities. 4. General Requirements Specification (GRS) or all of the following two documents: Software Requirements Specification (SRS), System Specification (SS). 5. Waiver or Deviation List Prepared. 6. Verification Test Procedures Submitted (Test transactions). 7. Verification Test Procedures Reviewed and Approved (Test transactions). 8. Verification Testing Completed and results available (System Qualification Test). 9. Verification Test Data and Results Reviewed and Approved. 10. Test Results submitted (if available or applicable). 11. Verification Testing Witnessed. 12. Test Readiness Review I and II (TRR I and TRR II) completed. 13. Test Readiness Review I and II (TRR I and TRR II) minutes and open action items from past reviews available. 14. Copy of baseline and database change requests with their associated status accounting records along with all design (Problem Reports and Deficiency Reports (PRs and DRs), etc.) provided. 15. Other inputs as specified by the functional requirements and planning documents. Signature of FCA Team Members: Date: Results reviewed satisfy the requirements and are accepted (See attached comments). Results reviewed do not satisfy requirements (See attached comments and list of deficiencies). Approved by: Date: JSP 886 Volume 7 Part 8.12: Configuration Management: Chapter 2 33