Figure: the ISO Pyramid
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
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.
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.
4.4.2 CM PLAN - DEVELOPMENT
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.
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
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
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
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 the contractor to ensure subcontractor/vendor compliance with configuration management requirements.
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
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
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.
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.
| Previous: Processes | Next: CM Tool Management |