Action to establish which members of the Product breakdown structure are to be changed, including new production and existing products.

Manage change is the CM interrelated process that addresses the systematic proposal, justification, evaluation, co-ordination and disposition of proposed changes, and the implementation and verification of all authorised changes into the applicable configurations of a product and associated product configuration information.

The purpose and benefits of the Configuration Change Management process are to:
·enable change decisions to be based on knowledge of complete change impact;
·limit changes to those that are necessary or offer significant benefit;
·facilitate evaluation of cost, savings and trade-offs;
·ensure customer interests are considered;

The activities necessary neccessary to provide the context and environment in which to manage the configuration of the product

Specify Configuration is the CM interrelated process that is the basis from which, the configuration of products is defined and verified, products and records are labelled, and accountability is maintained.

Specify Configuration, (Configuration Identification), is a set of processes, which occur throughout the product life cycle and is the basis of all subsequent configuration management of a product and its constituent elements.
Specify Configuration includes:
·selecting Configuration Items (CIs) (if required) at appropriate levels of the product structure to facilitate the recording, management and support of the items and their information;
·determining the types of product definition information required for each CI to define its performance, functional and physical attributes, and internal and external interfaces. Product definition information provides the basis to develop and procure products, fabricate and assemble items, inspect and test items, and maintain systems;
·determining the configuration management authority for each configuration record;
·issuing identifiers for the CIs, all lower level items and the product configuration information;
·assigning serial and lot numbers as necessary;
·maintaining the configuration identification of CIs to facilitate logistic support of products in service;
·releasing product configuration information;
·establishing configuration baselines for the configuration management of CIs.
Specify Configuration begins during the concept stage of the product life cycle with the definition of the product and its product definition information. As the product evolves through its life cycle, configuration identification activities will support the configuration management interrelated processes of configuration change management, configuration status accounting and configuration audit and verification.

Implement and verify a change to ensure consistancy with its released Product Configuration Information and the changed product.

Audit Configuration is the CM Interrelated process that establishs that the performance and functional requirements defined in the product configuration information have been achieved by the design and that the design has been accurately recorded in the product configuration information.

The process:
.ensures that the product design provides the recorded performance capabilities;
·verifies the consistency between a product and its product configuration information;
·determines that an adequate process is in place to provide continuing management of the configuration.

Successful completion of verification and audit activities results in verified CIs and a product configuration information set that may be confidently considered a Product Baseline. It also results in a validated process to maintain the continuing consistency of product with its product configuration information.
Verification is a continuous activity embedded in quality control, development, testing, manufacturing, modification and maintenance processes. Audit represents an explicit event: it is a final, comprehensive check of a design including examination of recorded outputs from the verification process.
The more confidence the customer has in the contractor's configuration verification process, the easier the audit process becomes.

This process defines the execution of an audit - the act of undertaking the audit activity

This process identifies the generic structure (product breakdown structure) that you wish to use for a project.

A product breakdown structure is a means for representing the composition of a product in a hierarchical fashion from the top-level product down to the lowest level item . It is an output of the system design process iterated through the various tiers of system decomposition. Each level references product definition information such as user requirements and system specifications, models, drawings, bills of material, software requirements and design records, process specifications and operating procedures. The PBS, which evolves through the life of the programme, shows the interrelationships of the various items that constitute the product and the quantity of each and is only complete when all items and product configuration information is approved and baselined.

The process "define configuration structure" is where individual configuration items are selected. It is the establishment of a hierarchical Product Breakdown Structure (PBS) as an outcome of the user requirements and system design activity. This PBS is linked to each item's identifier and product definition information
Configuration Items [CI] are the basic unit from which the configuration of a product can be managed. A CI can be an item of hardware or software (or a combination of both), and its product configuration information is designated for Configuration management. Initial CI selection should reflect an optimum management level during the concept and development phase and will typically be the deliverable and separately installable items of the system. During the production and subsequent support phases, individual items required for logistic support and designated for separate procurement may also be designated as CIs. The view of what is designated a CI may depend on where in the contracting tree the view originates

This process addresses the identification of any items and associated records that have been created so that they may be referred to precisely and retrieved when necessary. This activity includes the re-identification of records and items whose identity has changed as a result of update or the application of a change.
Clearly identified information and items are essential for effective CM throughout the product life cycle, particularly during the in-service support phase when the item identifier is key to installing a correct replacement item and satisfying the relevant operation and maintenance instructions.
A record identifier, a revision identifier and a date clearly identifies a specific issue of a record. A record can have many representations in many media, all of which must be under configuration management. Product Definition Information is formatted and identified in accordance with the programme CMP.<br><br>A record is a wider definition that covers documents and documentation in any recording media

This process establishes a baseline for the product configuration.

A baseline identifies an agreed description of the attributes of a product at a point in time and provides a known configuration to which changes are addressed.
The concept of defining and applying baselines to a product as a means of exercising management is not unique. For example, for a programme to be managed an understanding of the planned cost and schedule ; a baseline plan ; is required to form the reference for subsequent achievement monitoring. Similarly, in order to define and implement a development or a modification to a product, a reference product definition against which that development can proceed, or modification can be defined, is required.
A Configuration baseline is a snapshot of an item's configuration at a point in time. More specifically, it is a fixed reference configuration established by defining and recording the approved Product Configuration Information (PCI) describing the object of interest at a point in time. While it is theoretically possible to establish a baseline for a component at any level of a PBS, it is rare, and indeed in the CM sense there is seldom any value, in establishing a formal configuration baseline for an object below the level of CI.In a system development, configuration baselines may be established hierarchically as the Product Breakdown Structure [PBS] evolves. For example, the Allocated Base Line [ABL] at the highest system level may be interpreted as a series of Functional Base Lines [FBL] for each constituent system-level CI; some or more of these CIs will, in turn have an individual ABL which may define a series of FBLs for next-tier CI products. The CMP must be continually reviewed to reflect the evolving PBS over the life cycle of a product.
The above baselines represent an example of reference points that will provide a known configuration to which changes are addressed; once established, they remain under configuration management throughout the product life cycle. Within the development phase of the product life cycle a series of ;Design; reviews are undertaken. Each of these design reviews creates a baseline of approved product definition information. These baselines are referred to as ;Development; Baselines (DBL) and remain relevant and under configuration management for only so long as the reason for their establishment remain.

This process authoirses draft baselines and relaeses them.
Configuration Baselines released during the product life cycle, the products comprising them and the product configuration information describing them shall be recorded in accordance with the programme CMP.

This process verifies that a product&aposs attributes have been met and the product design meeting those attributes has been accurately recorded, in order to baseline the product configuration information.

Configuration Verification establishes that the performance and functional requirements defined in the product configuration information have been achieved by the design and that the design has been accurately recorded in the product configuration information). The process:
ensures that the product design provides the recorded performance capabilities;
verifies the consistency between a product and its Product Configuration Information;
determines that an adequate process is in place to provide continuing management of the configuration.

Action to develop a plan for the tasks required to validate, verify or audit a change.

Such plans should be based on the decision taken concerning the introduction point and effectivity of the change. It will cover both production embodiment and retrospective embodiment, before or after the
delivery of the product as appropriate. An approved change is planned and scheduled for implementation in all documents, facilities, hardware and software impacted change. The implementation is carried out in accordance with the plan. Implementation of a change involves the release of new or revised configuration documentation including requirements and design information. The implementation may involve changes to operation and maintenance information, build and test information, and sales information (such as catalogues, marketing literature). The new or revised information is identified and released as PCI. The release process should correlate the document revisions to the change or changes incorporated. A common method of disseminating document change is by means of document change notices, which establish a permanent record of specific changes and facilitates distribution.

This process executes the verification activities specified by the verification plan in accordance with programme procedures detailed in the CMP

NOTE - Once the initial configuration of a CI or system has been verified, changes to that configuration must be authorised through the configuration change management process.If the change is being introduced to a production line and all future products will have the change incorporated via the production process, it is sufficient to ensure that: manufacturing instructions contain the change and are released for use; the first articles produced are inspected for compliance (First Article Verification ; FAV).

If support processes are impacted or the change requires retrofit,implementation and verification of the change can be a lengthy process. Implementation planning will define the extent to which the change to each item and support process is to be verified and recorded

This process consists of evaluating an verification and creating an verification report from the findings

This activity establishes the scope of the information set that is to be audited.
Configuration audits provide the framework for verifying that the development effort has achieved the requirements specified in the configuration baselines. It is the auditing activity that has the responsibility to ensure that all action items are identified, addressed and resolved before the design activity can be deemed to have fulfilled the requirements.

This process establishes the schedule, agenda, facilities, and the rules for audit conduct and identifies the participants for the audit Action to develop a plan for the tasks required to validate, verify or audit a change.

Such plans should be based on the decision taken concerning the introduction point and effectivity of the change. It will cover both production embodiment and retrospective embodiment, before or after the
delivery of the product as appropriate. An approved change is planned and scheduled for implementation in all documents, facilities, hardware and software impacted change. The implementation is carried out in accordance with the plan. Implementation of a change involves the release of new or revised configuration documentation including requirements and design information. The implementation may involve changes to operation and maintenance information, build and test information, and sales information (such as catalogues, marketing literature). The new or revised information is identified and released as PCI. The release process should correlate the document revisions to the change or changes incorporated. A common method of disseminating document change is by means of document change notices, which establish a permanent record of specific changes and facilitates distribution.

This process defines the execution of an audit - the act of undertaking the audit activity

NOTE - The audit team record discrepancies or anomalies and recommend courses of action. The Chairperson reviews audit findings and determines appropriate actions. Affected parties agree to action items and the plan for effecting their closure. Audit minutes provide a record of auditfindings, conclusions and recommendations and action items. Follow-up occurs until all action items are complete.

This process consists of evaluating an audit and creating an audit report from the findongs.

It establishes the courses of actions required to follow-up and close down the audit actions.
NOTE - Once an audit has been performed and follow-up actions have been agreed it is necessary to evaluate the audit results. The audit team will report on the execution of the audit and provide where necessary a "lessons learned" report for the benefit of future audits.

audit feedback -A post audit process in which systematic follow-up of the audit action items takes place.
NOTE - establishes the courses of actions required to follow-up and close down the audit actions.

This process organizes the product configuration information and makes it available, as required, to support all programme activities such as systems engineering, manufacturing, hardware and software development and production, logistic support, modification, and disposal

The review of the preliminary impact assessment, determination of the required change effectiveness, the cost / price assessment and the approval, rejection or deferral for more research of the change, together with reasons for the decision.

Action to establish the business case for change, select a preferred solution and authorize the change by approval of appropriate change orders to enable the change to be implemented and verified

Carry out a preliminary assessment of the impact of the change.

The sponsor of the change is the person who has the authority to initiate the assessement of the proposed changes. This is usually the individual with responsibility for the affected product(s) and may be the originator.

In consultation with the originator, the sponsor analyses the issue for merit on the basis of its nature and likely impact. This can be a fairly informal and intuitive process, but it often requires careful weighing of alternatives and cost benefit trade-offs. If the issue appears to be unwarranted, it can be closed, with a brief description of the reason for rejection recorded.

Action to determine those configuration items that will be affected by the possible solutions.

Action to assess the risks associated with a quantified solution to a valid need for change

Action to evaluate the cost of a change by subjecting the most beneficial solution to a commercial pricing exercise, creating a price that meets the implementation and effectivity requirements

Action to review the total change package and complete a justification for the implementation requirements with a recommended classification and priority.

Action to establish the business case for design change, selection of a preferred solution (if appropriate) and authorisation the design to be changed and verified.

Authorization, rejection or deferrment of a recommended change based on the associated justification.

If the change is authorized a change order will be issued for implementation. If the change is rejected a further review can be initiated.

This function provides visibility into, and control over a product's performance, functional and physical attributes for the product life cycle.