Previous: CM Processes
Next: Tool Management

Configuration Management Body of Knowledge

Chapter 4: Configuration Management Planning

Table of Contents - (Generated automatically from contents below)

Configuration Management Body of Knowledge
Chapter 4: Configuration Management Planning

Overview

The planning for a Configuration Management effort is not trivial nor should it be taken lightly. This section outlines the process, procedures, guidelines and outlines used for planning a Configuration Management effort. -- SmKershaw? - 15 Feb 2003

4.1 GENERAL

Any Organisation, in order to be efficient, has to identify its core business processes.

These core business processes, used to run the business, must be clearly identified and documented. Each core process must have its assigned owner who is responsible continuously to ensure the reliability and efficiency of the owned processes.

Not only must CM be established as one of the core business process, but CM also can provide the perfect framework upon which the business process infrastructure can be effective.

Giving this new perspective, it is necessary not to see CM anymore as limited to being a pure engineering discipline. Providing a framework for the business process infrastructure lifts CM to an organizational-wide perspective.

The purpose of this section is to give an understanding about the importance of the role of Configuration Management Planning. The goal is to provide guidance of how a CM solution can be implemented and what are the key elements to be established. -- SmKershaw? - 11 Feb 2003

4.2 CONCEPT

Configuration management embodies two concepts:

The Configuration Management of products/services and their defining technical data
The Configuration Management of the business process infrastructure.

Configuration Planning can be best achieved using a four-phased approach consisting of: Preparation, Transition, Implementation and Adaptation/Continuous Improvement.

To successfully initiate a CM Planning process, Cross-functional teams need to be established. They should be organized in a hierarchy. A higher level team, comprised of members of the top-level management should act as a steering committee providing guidance, rules and regulations and decisions.

The subordinated teams usually report to the higher level team and should be constituted by collecting members from all required disciplines within the organization to perform the day-to-day business. The members of the subordinate-level team are responsible for preparing plans, obtaining approvals, coordinating implementation, problem resolution, plan maintenance and progress reports. -- SmKershaw? - 11 Feb 2003

4.3 IMPLEMENTATION STRATEGY

The preparation phase accumulates in a “12 Step” approach to prepare an effective CM Solution.

Step 1 – Top-Management Buy-in

The establishment and implementation of an efficient CM Solution and its required Business Process Infrastructure is best achieved when top-management buys the idea and backs it up. This can be achieved by using a Top-down approach.

Top-down means that the effort is driven by upper management.

If the support from upper-management is lacking, a bottom-up approach can be a viable option, but requires much more effort than the top-down approach.

Since a Top-down approach is highly preferred, it might be necessary to get better management buy-in; that is, give management an understanding of the complexity of the solution and hence the costs and tradeoffs. This enables a better commitment of resources such as tools, people, and funds to the solution.

A possible solution to get better buy-in is to perform management information sessions to inform upper management on the following points:

Overview about CM concept
A brief overview about the principles of Configuration Management and the concept to be applied
Objectives and Requirements (Goals)
Benefits and Risks.

Configuration Management provides knowledge of the correct current configuration of material, assets and services, the relationship to the associated documents and . The CM process efficiently accommodate changes, ensuring that all impacts to operation and support are addressed. The benefits of the process should be obvious but are often overlooked. CM benefits can be summarized as follows:

{The previous paragraph needs to be explain/rephrase} -- DenisRoy? - 27 Feb 2003

Product attributes are defined. Measurable performance parameters are provided. Both purchaser and contractor have a common basis for acquisition and use of the product.

Product configuration is documented and a known basis for making changes is established. Decisions are based on correct, current information. Production repeatability is enhanced.

Products are labeled and correlated with their associated requirements, design and product information. The applicable data (such as for procurement, design or servicing the product) is accessible, avoiding guesswork and trial and error.

Proposed changes are identified and evaluated for impact prior to making change decisions. Downstream surprises are avoided. Cost and schedule savings are realized.

Changes can be accommodated. Change activity is managed using a defined and fast process. Costly errors of ad hoc, erratic change management are avoided.

Configuration information, captured during the product definition, change management, product build, distribution, operation, and disposal processes, is organized for retrieval of key information and relationships, as needed. Timely, accurate information avoids costly delays and product down time, ensures proper replacement and repair and decreases maintenance costs.

Actual product configuration is verified against the required attributes. Incorporation of changes to the product is verified, authorized and recorded throughout the product life. A high level of confidence in the product information is established.

Well defined, stable and transparent business process infrastructure results.

These benefits are equally applicable to purchaser and contractor. Additionally, the effective application of CM principles to acquired products contributes to and enhances the partnering environment desired between the Purchaser and its suppliers.

In the absence of CM, or where it is ineffectual, the attendant risks are:

Customer expectation are not met
Equipment/Software fails due to incorrect part installation or replacement
Product does not comply to requirements
Product Documentation is incomplete or not correct
There are schedule delays and increased cost due to unanticipated changes
There are operational delays due to mismatches with support assets
Uncontrolled changes introduce defects implying the need for corrective action
Maintenance problems, down-time, and increased maintenance cost are caused by inconsistencies between equipment/software and its maintenance instructions
High intervention rate is required, and consequently high cost due to corrective action
Numerous other circumstances which decrease operational effectiveness, and add cost may occur

The severest consequence is catastrophic loss of expensive equipment and human life. Of course these failures may be attributed to causes other than poor CM, but effective CM may often avert these.

The overall objective of CM is to move out of the corrective action mode, which avoids preventable costs, to minimize risk, and to expedite transition into a continuous improvement mode.

Those who consider the small investment in the CM process a cost-driver may not be considering the compensating benefits of CM and may be ignoring or underestimating the cost, schedule and technical risk of an inadequate or delayed CM process.

-- DirkWessel? - 11 Feb 2003 {Dirk, can we find another word than "sensibilization"? I'm guessing that you are trying to avoid the word "education" since upper management might take affront, and I did not want to just plug in a word because the word should say exactly what you mean, not what I think you mean.} -- CarildaAThomas? - 18 Feb 2003

(Maybe "coaching" although that I like sensibilization more. Any suggestions?) -- DirkWessel? 18 Feb 2003 { How about "evangelizing"? One has to do more than just sell upper management on the idea, one has to make True Believers out of them so they will support CM over the long haul. } -- CarildaAThomas? - 21 Feb 2003

Step 2 – Establish CM Policy

Before you can start with the development of a CM policy it has to be clear which position and importance the CM organization will take within the organizational structure. So before starting with the CM policy you need to have guidance from your higher management.

The CM policy document should reflect the strategic objectives adapted to the different phases in the projects life-cycle.

Step 3 – Define Requirements

In order to produce a product/service which survives in the market an organization has to define its requirements.

The main objective during the definition of those requirements should be to establish clear, concise and valid requirements.

Clear means that they are easy to understand.
Concise means free from all elaboration and superfluous detail.
Valid means that they meet the expectations and can be tested.

In an Acquisition environment the purchaser and the contractor requirements should be congruent. During the CM Planning phase for each life-cycle, the purchaser must articulate its vision and transform it into clear, concise and valid requirements for the contractor. Before the requirements are going to be implemented, they should be coordinated with the contractor.

Business Requirements

Before starting to define the business requirements the Organisation has to establish, based on existing regulations and the Customer needs, a Mission Statement. This Mission Statement indicates the purpose of the Organisation.

Following the Mission Statement, a Strategic Business Plan has to be established describing how to accomplish the Mission Statement.

The business requirements should describe the overall organizational business infrastructure the business core processes, relationship to other disciplines and the working conditions within your Organisation.

Make sure that the employees understand and identify themselves with the business requirements.

The business requirements should be documented in a Strategic Business Plan.

Product/Service Requirements

All developmental projects are governed by requirements. For your products/services, identify all the user needs and convert them into clear concise and valid requirements. Once you have converted them, try to coordinate with the user and see if they match with the users needs.

The requirements do not have to be perfect in the first instance, it is more important that they reflect what the user expects.

The product/service requirements should be documented in a System Specification.

Step 4 – Document Requirements

ISO 9000 says:" Document what you do; Do what you documented."

CMII, for example, goes beyond this statement and says:" A Requirement is not a requirement unless it is documented, validated and released."

Once you have defined your requirements they need to be documented.

Product Requirements will be documented in the Design basis.

Business Requirements in the Strategic Business Plan, Policies, Standards, Procedures etc.

Requirements Management

Requirements Management provides visibility on behalf of project leadership. Applying familiar Configuration Management (CM) principles to a set of data that includes the comprehensive scope of work enables a systematic tracking of requirements wherever they are found and however they may have changed.

The Requirement Management approach provides a clear view of information, which enables projects to:

relate the configuration of technical baselines to corresponding cost and schedule requirements
synchronize the project-wide flow and content of requirements and changes to requirements
network all interfacing project activities at the review, approval, and distribution interfaces; and
provide a requirements visibility resource for interfacing design, procurement, production/remediation, logistics support and other activities.

The result is an integrated view of the project configuration (including cost and schedule) which provides up-to-date performance and quality measurement criteria for early warnings of off-course trends.

To keep an entire project apprised of the configuration and application of rapidly evolving requirements, it is necessary to:

Identify requirements with naming and numbering attributes that facilitate traceability to parent-child relationships, and support configuration tracking and reporting
Control the content, review and approval of changes to requirements
Describe the changes in terms of both individual requirements
Depict and maintain in hierarchical document trees the configuration baselines in which requirements are resident
Account for and report the configuration status of individual requirements and requirements
Manage the timely flow of evolving requirements and changes, across multiple functions/departments/organizations

Develop Organisational and CM policies

A Policy paper defines the requirements for interactions between individuals and groups within and outside the Organisation.

Develop Operating Standards and Procedures

Every Organisation works on Requirements. Without Requirements there is nothing to be done. Requirements to be achieved by a core business process are outlined in an operating standard. Procedures describe how to achieve such requirements. A possible documentation structure could be the one proposed by ISO 9000.

{Image added - DirkWessel? }

The Quality Manual specifies the requirements. Procedures for accomplishing those requirements are the next lower tier.

Work / Job Instructions are standard processes which reside at the third tier and which can be referenced for reuse in any number of procedures.

The “other documents” residing at the fourth tier are equivalent to “records” which provide evidence that conformance was achieved.

Step 5 – Establish a standardized Acronyms and Terminology dictionary

Some of the biggest problems within a project execution are communication problems. Very often, inappropriate words are used or words are wrongly interpreted.

To achieve a high level of efficiency it is important to standardize terminology. This is best accomplished by creating a dictionary and a glossary of commonly used acronyms, words and terminologies. Furthermore operation procedures have to be established describing how the dictionary and glossary are to be used and kept up-to-date.

Step 6 – Create a CM Plan

CM planning is a vital part of the preparation for each phase of a project life cycle. The Configuration Management plan documents the results of that planning to enable the usage of the Plan as a basis in managing the project configuration management activities.

For more details on how to create a CM Plan, please refer to the chapter X below.

Step 7 – Structuring Requirements

An organization can only operate efficiently if they manage their requirements correctly. This correlates with the ability to accommodate changes and keep the requirements clear, concise and valid.

All requirements should be uniquely identified, structured and linked. Each requirement exists in a hierarchy of requirements. This applies to the product/service requirements as well as the business requirements.

CM's primary role is to maintain those requirements.

Step 8 – Implement a Change process

In order to keep requirements clear, concise and valid, every organization needs to have an effective change mechanism in place.

A common change process shall be implemented.

Step 9 – Measure Performance

Effective measurements are a prerequisite to achieving consistent conformance and avoiding the need for corrective action.

Metrics are key to continuous process improvement and to manage the CM-related risks.

Metrics constitute the data for improvement, i.e. the facts of the process. They enable problems that need attention to be quantified, stratified and prioritized and also provide a basis for assessing the improvements, and assessing trends. A constituted set of CM metrics supports both the CM objectives and process.

Only a few critical items should be used at one time. They should be designed to positively motivate, rather than keep score, and should be forward focused (where are we going) as opposed to merely a compilation of past history.

A metric involves more than a measurement; it consists of:

An operational definition of the metric which defines what is to be measured, why the metric is employed, when, where and how it is used. It can also help to determine when a metric has outlived its usefulness and should be discontinued.

The collection and recording of actual measurement data. In the case of the CM process, this step can often be accomplished by query to the status accounting data base, which normally can provide a great deal of process flow information

The reduction of the measurement data into a presentation format (e.g., run chart, control chart, cause and effect diagram, Pareto charts, histogram) to best illuminate problems or bottlenecks and lead to the determination of root cause or largest constraint.

An effective metric has the following attributes:

It is meaningful in terms of customer relationships (where the “customer” can be any user of information that is provided.)
It relates to an organization’s goals and objective, and tells how well they are being met by the process, or part of the process, being measured
It is timely, simple, logical and repeatable, unambiguously defined, economical to collect.
It shows a trend over time, which will drive the appropriate forward focused action, which will benefit the entire organization.

Both the purchasers and the contractors CM processes should be measured and evaluated using metrics, project reviews.

Step 10 – Institute an internal CM Audit Plan and perform internal Pre-Audits

It is essential to learn from effective measurements and metrics if the process is or is not meeting objectives. We also learn which part of the process is currently the biggest contributor to detected backlogs, bottlenecks, repeat effort, or failures/errors. By focusing on that weakest link, we can isolate the problem and trace it to its root cause. Often the cause can be corrected by streamlining the process (eliminating redundancy or non-value adding steps, modifying sequence, performing tasks in parallel rather than in series) or improving communications.

Measurements should continue as is or be altered to fit the new solution for a period of time sufficient to assess if the revised process is resulting in improved performance. This measurement/improvement cycle is an iterative process. Once a weak link is improved, the process metrics are again reviewed to determine and improve other parts of the process that stand out as contributors to deficiencies or lengthy cycle time.

The key personnel involved in the process must be participants in defining the improvements. Their “buy in” is essential if the improvements are to be implemented effectively. Detailed procedures and effected automated systems must be modified and personnel must be re-trained, as required. These “total quality management aspects” of the job are best performed as an integral part of the process of managing, rather than as isolated exercises.

It is also a waste of effort to expend effort in improving processes without clearly documenting the lessons learned to leverage the efficiency of future applications. Changes made in the process, over time, should be recorded along with the reasons the changes were made and the measured results.

A suggested place to record process changes is in the Configuration Management Plan. Initially the CM plan was a projection of the expected implementation of Configuration Management over the project life cycle. As a minimum, it is updated during each phase for application during the next. Including process change and lessons learned information makes the plan a working document reflecting the transition from anticipated action (planning) to completed action (reality). It can then serve as a better reference to use in planning for the next project phase and in the initial planning for future projects.

Internal CM Audit Plan

In order to effectively analyse the current processes it is required to conduct in coordination with Quality Management internal Audits. These internal audits should be frequently conducted, planned and documented in an Internal CM Audit Plan which has to be coordinated with Quality Management.

Step 11 – CM Staffing

The CM Staffing should Consist of Individuals with technical expertise to support the Development and Maintenance of the Product. When staffing the CM area, be sure the individuals have the technical expertise to develop and implement sound processes and procedures.

CM should be staffed with technically skilled individuals who can develop methodologies for control, re-creation and release of models, product build/compile structures, subcontractor monitoring and managing, and authoring of CM-related documentation (including, CM Plan, baseline documentation, and so on.)

Be cautious when evaluating the staffing required to administer the CM system. While a mature system doesn’t require a large staff, the project should not cut CM staff simply because things appear to be going well.

The CM process must be institutionalized, not just written down. The tool set must be complete, in use, and no longer in need of constant maintenance. Several milestones — major deliveries to system integration, large test events, or audits — all become successful when supported by a fully utilized and reliable CM process.

Step 12 – Select best Automated CM System

-- DirkWessel? 18 Feb 2003

4.4 CM PLAN

According to the IEEE STD 828-1990, a plan documents what CM activities are to be done, how they are to be done, who is responsible for doing specific activities, when they are to happen, and what resources are required. It can address CM activities over any portion of a product's life cycle.

It is important to keep in mind the hierarchy where the CM Plan fits. Policies are typically at the highest level, requiring that directives be written. Directives generate Plans. Plans are implemented by procedures. Plans are not to address procedural concerns, rather they are directive, envisioning, guiding all in response to policies and directives. So when CM plans are written - regardless of style of outline - they must address the current state of the configuration and show how things need to move through into the future. -- SmKershaw? - 11 Feb 2003

4.4.1 CM PLAN - INTEGRATION WITH OTHER PLANS AND STANDARDS

Project/organizations utilizing Configuration Management will also utilize a variety of plans. These additional plans include (but are not necessarily limited to) project management plans, quality assurance plans, development plans, release management plans and software improvement plans. All of these must work together along with the CMP.

Project Plans should refer to the CMP, and describe where Configuration Management fits into Project Management. Conversely, the CMP should address Project Management needs.

Quality Assurance Plans should refer to the CMP, and describe its involvement with Configuration Management. The CMP should address quality assurance plan needs for Configuration Management.

Development Plans, regardless of the product (software or hardware), should demonstrate that the effort is configured in accordance with the Configuration Management plan and should address all CM Plan issues and concerns. The CMP should address the development plan needs for Configuration Management.

All must be auditable from a document trail perspective and be in agreement. -- SmKershaw? - 14 Feb 2003

4.4.2 CM PLAN - DEVELOPMENT

{How do you go about writing one? What determines the guidelines selections? What should be considered for inclusion and what should be excluded?}-- SmKershaw? - 11 Feb 2003

In writing a CM Plan, it is best to first to have identified and have approved a standard by which the configuration effort shall be guided. Such standards usually have a predefined outline that is to be followed - within reason - and tailored to fit the needs of the configuration effort. A few of these are provided in the sections that follow.

As a Configuration Manager you will be drawing upon your talent and skill to fill in the 'unknowns' in the plan. If you don't know the schedule, then you will need to get it. If it isn't defined, then it is your job to follow-up with management and encourage them to get one. The same can be said for any aspect of the plan for which you are missing pieces or parts.

You may put anything into the plan, as long as those inclusions do not detract from the mission of your configuration effort and the plan serving as a plan. Procedural issues should be detailed in a separate text.

-- SmKershaw? - 14 Feb 2003

4.4.3 CM PLAN - STANDARDS GUIDING DEVELOPMENT

Below are some samples of CM PLAN outlines. However, it should be pointed out, that there are some common parts of all of these outlines, and so it could be derived that at a minimum, a CM PLAN should include these sections:

Introduction
- Scope
- Definitions
- Acronyms List
- References
Configuration Management
- CM Organization
- CM Responsibilities
CM Schedules and Milestones
CM Activities
- Identification
- Control
- Status Accounting
- Auditing
Interface Management
Data Management
Sub Contractor/Vendor Control

-- SmKershaw? - 14 Feb 2003

4.4.3.1 Outline of a typical Purchaser CM Plan

   1.0 INTRODUCTION 
   1.1 Scope
   1.2 Definitions
   1.3 Acronym List
   1.4 References
   1.5 Tailoring 
   2.0 CONFIGURATION MANAGEMENT 
   2.1 CM organization 
   2.2 CM responsibilities 
   2.3 Relationship of CM to the process life cycle
       2.3.1 Interfaces to other organizations, disciplines on the project 
       2.3.2 Other project organizations' CM responsibilities
   2.4 Relationship with Purchaser CM Plan
   3.0 CONFIGURATION MANAGEMENT PHASING AND MILESTONES
       * Release and submittal of configuration documentation in respect to project events
       * Define all CM project milestones (e.g., baselines, reviews, audits) 
       * Describe how the CM milestones tie into the development process 
       * Identify what the criteria are for reaching each milestone 
   4.0 CONFIGURATION MANAGEMENT ACTIVITIES 
   4.1 Configuration Planning
       4.1.1 Configuration Management Implementation Procedure
   4.2 Configuration Identification
       4.2.1 CI Selection and Description
             * A description of the selection criteria and the associated rationale employed to select the CIs
             * A description of key lower level CIs (hardware and software) including training devices and simulators showing their relationship to the work breakdown structure of the complete project;  
             * A description of the function of the top level CI and its interrelationship to other system functions; and
             * Government Furnished Equipment/Property. (May be specified in a separate appendix, if necessary). 
       4.2.2 Configuration Documentation Identification 
             * Labeling and numbering scheme for documents and files 
             * How identification between documents and files relate 
             * Description of identification tracking scheme 
             * When a document/file identification number enters controlled status 
             * How the identification scheme addresses versions and releases 
             * How the identification scheme addresses hardware, application software system software, COTS products, support software (e.g., test data and files), etc. 
             * Configuration Control Authority designation for each configuration document
       4.2.3 Change Control Form Identification 
             * Numbering scheme for each of the forms used 
       4.2.4 Project Baselines 
             * Identify various baselines for the project 
             * For each baseline created provide the following information: 
                 * How and when it is created 
                 * Who authorizes and who verifies it 
                 * The purpose 
                 * What goes into it (software and documentation) 
       4.2.5 Library 
             * Identification and control mechanisms used 
             * Number of libraries and the types 
             * Backup and disaster plans and procedures 
             * Recovery process for any type of loss 
             * Retention policies and procedures 
             * What needs to be retained, for whom, and for how long 
             * How the information is retained (on-line, off-line, media type and format) 
       4.2.6 Engineering Release process, to include the following information: 
             * What is the structure of the Engineering Release System
             * What is in the release 
             * To whom is the release is being provided and when 
             * The media the release is on 
             * Any known problems in the release 
             * Any known fixes in the release 
             * Installation instructions 
   4.3 Configuration Control 
       4.3.1 Procedures for changing baselines (procedures may vary with each baseline) 
             4.3.1.1 Procedure for changing Contract Baseline
             4.3.1.2 Procedure for changing Functional, Allocated and Product baseline
       4.3.2 Procedures for processing Engineering change proposals and approvals-change classification scheme for both Hardware and Software.
             * Procedure for processing Notice of Revisions (NORs)
             * Change reporting documentation
             * Change control flow diagram 
       4.3.3 Procedures for processing Requests for Waivers/Deviations (RFW/Ds)
       4.3.4 Organizations assigned responsibilities for change control 
       4.3.5 Change Control Boards (CCBs) – for each, describe and provide the following information: 
             * Terms of references (TOR) or Charter 
             * Members 
             * Roles 
             * Procedures 
             * Approval mechanisms 
       4.3.6 Interfaces, overall hierarchy, and the responsibility for communication between multiple CCBs, when applicable 
       4.3.7 Level of control – identify how it will change throughout the life cycle, when applicable 
       4.3.8 Document revisions – how they will be handled 
       4.3.9 Procedure to describe rule for Parts substitution
       4.3.10 Automated tools used to perform change control 
   4.4 Configuration Status Accounting 
       4.4.1 Methods for collecting, recording, processing and maintaining data necessary to provide status accounting information via reports and/or database access.
       4.4.2 Storage, handling and release of project media 
       4.4.3 Types of information needed to be reported and the control over this information that is needed 
       4.4.4 Reports to be produced (e.g., management reports, QA reports, CCB reports), who the audience is for each and the information needed to produce each report 
       4.4.5 Document status accounting and change management status accounting that needs to occur 
   4.5 Configuration Auditing 
       4.5.1 Number of audits to be done and when they will be done (internal audits as well as configuration audits); for each audit provide the following: 
             * Which baseline it is tied to, if applicable 
             * Who performs the audit 
             * What is audited 
             * What is the CM role in the audit, and what are the roles of other organizations in the audit 
             * How formal is the audit 
             * Contents and delivery date of Audit plans
       4.5.2 All reviews that CM supports; for each review, provide the following: 
             * The materials to be reviewed 
             * CM responsibility in the review and the responsibilities of other organizations 
       4.5.3 Technical Reviews
             * Outline CMs participation and role in technical reviews.
   5.0 INTERFACE MANAGEMENT
       * Develop procedures for the identification of interface requirements
       * Establishment of interface agreements
       * Participation in Interface Control Working Groups (ICWG)
   6.0 DATA MANAGEMENT
       * Description of the methods for meeting the configuration management technical data requirements.
   7.0 TRAINING 
       * Identify the kinds and amounts of training (e.g., orientation, tools) 
   8.0 SUBCONTRACTOR/VENDOR SUPPORT 
       * Describe any subcontractor and/or vendor support and interfacing, if applicable

-- DirkWessel? 11 Feb 2003 -- SmKershaw? - 11 Feb 2003 - formatted.

4.4.3.2 IEEE CM Plan Outline

Below is an abbreviated version of the IEEE CM Plan. A complete copy of the standard is in an appendix.

   1.  Introduction
   2.  CM Management
       2.1 Organization
       2.2 CM Responsibilities
       2.3 Applicable Policies, directives and procedures
   3.  CM Activities
       3.1 Configuration Identification
       3.2 Configuration Control
       3.3 Configuration Status Accounting
       3.4 Configuration Audits and Reviews
       3.5 Interface Control
       3.6 Subcontractor/Vendor Control

   4.  CM Schedules
   5.  CM Resources
   6.  CM Plan Maintenance

-- SmKershaw? - 11 Feb 2003

4.4.3.3 Mil-STD-973 CM Plan Outline

The outline below is reproduced with modification from MIL-STD-973 Appendix A. The original is targeting the Government's relationship with Vendors and their associated Configuration Management efforts. The outline below has been modified to be more generic in use. Also, those parts of the original Plan that are no longer being practiced by the Government have been removed.

In an effort to keep the theme that Plans should Plan, and not detail procedures, it should be noted that it is sufficient (in accordance with tailoring rules of this Mil-Std) to reference procedural documentation where appropriate.

Section 1. Introduction

Includes purpose, scope and specific contractual applicability of the CM Plan and program phase(s) to which it is applied;
A brief description of the system or top level configured item, and of the component lower level configured items, using approved configuration item nomenclatures when available, to which the CM Plan pertains;
References to applicable directives or glossaries containing definitions of terminology and acronyms used in the plan; and
A description of the plan's major features and objectives and a concise summary of the contractor's approach to CM, including any special conditions (such as large number of organizations, security constraints, interoperability constraints, unique contracting methods, non-developmental items, etc.) upon which the approach is based.

Section 2 - Reference Documents - lists the specifications, standards, manuals, and other documents, including policy directives, referenced in the Plan by title, document number, issuing authority, revision, and when applicable, change notice, amendment number, and date of issue.

Section 3 - Organization - Describes and graphically portrays the organization with emphasis on the CM activities, and which shall include:

The relationships and integration of the project organization and functional organization;
Responsibility and authority for CM of all participating groups and organizations including their role in configuration control boards, and the integration of CM functions with other program activities such as technical reviews;
Identification of the CM organization and its responsibilities; and
Interfaces between the CM organization and the Project/Program Owners, subcontractors, and associate contractors.

Section 4. Configuration Management phasing and milestones. - Describes and graphically portrays the sequence of events and milestones for implementation of CM in phase with major program milestones and events, including as a minimum:

Release and submittal of configuration documentation in relation to program events (e.g., technical reviews);
Establishment of internal developmental configuration and contractual baselines;
Implementation of internal and project configuration control;
Establishment of configuration control boards;
Implementation of a status accounting information system and provision of reports/or access to the status accounting information; and
Conduct of configuration audits.

Section 5. Data Management - Describes the methods for meeting the Configuration Management technical data requirements under the computer-aided acquisition and logistic support (CALS) requirements of the project.

Section 6. Configuration Identification. Describes the procedures for meeting the requirements of Section 5, including:

Selection of Configured Items (hardware configured items and computer software configured items);
Establishment and management of developmental configuration including documents, drawing and software development libraries and corrective action process;
Establishment of the Functional, Allocated, and Product baselines, definition of the configuration documentation required for each and graphic illustration of configuration documentation relationships;
Engineering release and correlation of manufactured products;
and assignment and application of configuration identifiers including document numbers, nomenclatures, serial numbers and part numbers to hardware and software identifiers to software and firmware.

Section 7. Interface Management - Describes the procedures for identification of interface requirements, establishment of interface agreements and participation in interface control working groups.

Section 8. Configuration Control. Describes the procedure for meeting the requirements of Section 5, including:

Functions, responsibility, and authority of configuration control boards;
Classification of changes, and the level of authority for change approval/concurrence;
Processing of "Out-Of-Scope" Changes;
Processing of "In-Scope" Changes;
Processing of requests for deviations and waivers.

Section 9. Configuration Status Accounting - Describes the procedures for meeting the requirements of Section 5 including:

The methods for collecting, recording, processing and maintaining data necessary to provide contractual status accounting information via reports and/or data base access;
Description of reports/information system content related to, as applicable:
- Identification of current approved configuration documentation and configuration identifiers associated with each CI;
- Status of proposed engineering changes from initiation to implementation;
- Results of configuration audits; status and disposition of discrepancies;
- Status of requests for critical and major deviations and waivers;
- Traceability of changes from baselined documentation of each CI; and
- Effectivity and installation status of configuration changes to all CIs at all locations.
methods of access to information in status accounting information systems and/or frequency of reporting and distribution.

Section 10. Configuration Audits - Describes the approach to meeting the requirements of section 5, including: Plans, procedures, documentation, and schedules for functional and physical configuration audits; and format for reporting results of in-process configuration audits.

Section 11. Subcontractor/Vendor control - Describes the methods used by thecontractor to ensure subcontractor/vendor compliance with configuration management requirements. -- SmKershaw? - 14 Feb 2003

4.4.3.4 SEI Example of CM Plan

   1.  Overview
       * CM objectives
       * System overview
   2.  CM Organization
       * CM Responsibilities
       * CCB members
       * CCB Charter
       * Product Assurance Relationship
   3.  CM Methods
       * Baselines and Contents
       * Identification system
       * Control system
       * Auditing
       * Status Accounting
       * CM Support Tools
   4.  CM Procedures
       * Procedures manual
       * Forms and Records
   5.  CM Implementation
       * Personnel plan
       * System support plan
       * Budget
       * Key Implementation checkpoints

-- SmKershaw? - 11 Feb 2003

4.4.3.5 Outline of CM Plan following RUP model

This Outline has been modified to be applicable to any CM environment.

   1  GENERAL
      1.1   Table of Contents
      1.2   List of Tables
      1.3   List of Figures
      1.4   Document History
      1.5   Issue Control
      1.6   Authors
      1.7   Copyright Notice
      1.8   References
      1.9   Purpose of this Document
      1.10  Document Responsibility
      1.11  Change Process CM Plan
      1.12  Acronyms & Glossary
      1.13  Projects’ values
   2   INTRODUCTION
   3   INCEPTION PHASE
      3.1   Introduction
         3.1.1   Purpose
         3.1.2   Scope
      3.2   Management
         3.2.1   Organization
         3.2.2   Responsibilities
         3.2.3   Implementation
         3.2.4   Policies, directives and procedures
            3.2.4.1   Policies
            3.2.4.2   Directives
            3.2.4.3   Procedures
            3.2.4.4   Tools & OEMs
      3.3   Configuration Identification
         3.3.1   Conventions
            3.3.1.1   Labels
            3.3.1.2   Naming Restrictions
         3.3.2   Baselines
      3.4   Configuration Control
         3.4.1   Code, Hardware, Document Control
         3.4.2   Change Control
            3.4.2.1   Levels of Authority
            3.4.2.2   Change Procedures
            3.4.2.3   Review Board
            3.4.2.4   Interface Control
      3.5   Configuration Status Accounting
      3.6   Tools, techniques and methods for SCM
      3.7   Supplier Control
      3.8   Records collection and retention
   4   ELABORATION PHASE
      4.1   Introduction
         4.1.1   Purpose
         4.1.2   Scope
      4.2   Management
         4.2.1   Organization
         4.2.2   Responsibilities
         4.2.3   Implementation
         4.2.4   Policies, directives and procedures
            4.2.4.1   Component structure
            4.2.4.2   Branching and Labeling Concept
            4.2.4.3   Disk usage monitoring
            4.2.4.4   Login policy
            4.2.4.5   Profile policy
            4.2.4.6   Home policy
            4.2.4.7   New/Old user Policy
      4.3   Configuration identification
         4.3.1   Conventions
            4.3.1.1   Branches
            4.3.1.2   Label Types
         4.3.2   Baselines
      4.4   Configuration Control
         4.4.1   Code, Hardware, and Document control
         4.4.2   Change Control
            4.4.2.1   Levels of authority
            4.4.2.2   Change procedures
            4.4.2.3   Review board
            4.4.2.4   Interface Control
      4.5   Configuration Status accounting
      4.6   Tools, techniques and methods for CM
      4.7   Supplier Control
      4.8   Records collection and retention
   5   CONSTRUCTION PHASE
      5.1   Introduction
         5.1.1   Purpose
         5.1.2   Scope
      5.2   Management
         5.2.1   Organization
         5.2.2   Responsibilities
         5.2.3   Implementation
         5.2.4   Policies, directives and procedures
            5.2.4.1   Maintenance of makefiles, compilation procedures, and build procedures
            5.2.4.2   Branching/merging policies
            5.2.4.3   ConfigSpec
            5.2.4.4   Hardware Policy
            5.2.4.5   Coding processes
            5.2.4.6  Announcement of builds
            5.2.4.7  Promotion of builds
            5.2.4.8  Type of builds
            5.2.4.9  Status Build flag
            5.2.4.10  Version number
            5.2.4.11  Fault reporting systems
            5.2.4.12  Contact Points
      5.3   Configuration identification
         5.3.1   Conventions
         5.3.2   Baselines
      5.4   Configuration Control
         5.4.1   Code and Document control
         5.4.2   Change Control
            5.4.2.1   Levels of authority
            5.4.2.2   Change procedures
            5.4.2.3   Review board
            5.4.2.4   Interface Control
      5.5   Configuration Status Accounting
      5.6   Tools, techniques and methods for CM
      5.7   Supplier Control
      5.8   Records collection and retention
   6   TRANSITION PHASE
      6.1   Introduction
         6.1.1   Purpose
         6.1.2   Scope
      6.2   Management
         6.2.1   Organization
         6.2.2   Responsibilities
         6.2.3   Implementation
         6.2.4   Policies, directives and procedures
            6.2.4.1   Code Freeze Procedures (If required for the project)
            6.2.4.2   Overall Version Load Number
            6.2.4.3   Release notes
            6.2.4.4   Creation of the Release
            6.2.4.5   Patch Releases
            6.2.4.6   Release of loads
            6.2.4.7   Release to other test sites (System Test)
            6.2.4.8   Release Archive
            6.2.4.9   Incoming third parties
            6.2.4.10  New bugs process
      6.3   Configuration identification
         6.3.1   Conventions
         6.3.2   Baselines
      6.4   Configuration Control
         6.4.1   Code, Hardware, and Document control
         6.4.2   Change Control
            6.4.2.1   Levels of authority
            6.4.2.2   Change procedures
            6.4.2.3   Review board
            6.4.2.4   Interface Control
      6.5   Configuration Status accounting
      6.6   Tools, techniques and methods for CM
      6.7   Supplier Control
      6.8   Records collection and retention

DenisRoy? - 17 Feb 2003 {modified outline to be more generic -- SmKershaw? - 08 Apr 2003}

4.4.4 CM PLAN - IMPLEMENTATION

Much like the general CM Processes already discussed, the implementation of the CM Plan requires education and selling.

The first step is to get the plan reviewed and approved by members of management. It is recommended that the signatories include the managers of the project, quality assurance, development, and at least one other manager above the project manager - in addition to yourself. Once signed, the plan can then be 'rolled-out' to the team.

The CM Team should develop training materials for two different audiences. One for Management, and one for project team members. The intent is to a) show it with a positive style, b) train all players in what the plan covers and c) what it means to the audience(s) in their day-to-day work.

The Plan should be made available to all attendees in either hard copy or soft copy. The CM Team needs to invite suggestions for changes, with the caveat that the CM Team has the right to disagree.

-- SmKershaw? - 14 Feb 2003

4.4.5 CM PLAN - MAINTAINED

CM Plans need to be reviewed and updated periodically. We do this to keep our plans current with current activities, but also to assure that the 'vision' for the future is still good and still aligned with the project/organization authorizing it. Also, the CM team should keep a record of suggestions for changes to the PLAN. When the Plan is reviewed, those changes can be evaluated and if deemed appropriate, can be incorporated.

-- SmKershaw? - 14 Feb 2003

(Split and edited) -- CarildaAThomas? - 18 Feb 2003

Previous: CM Processes
Next: Tool Management