Configuration Management Body of Knowledge The Complete Text

$ This page is automatically generated from the CMBoK page and its corresponding CMBoK chapter pages
for the purpose of conveniently viewing and printing as a single document
-- BradAppleton^? - 13 Mar 2003 :

---

Table of Contents #TopOfPage

---

Section I: The Configuration Management Framework

---

Chapter 1: Introduction

Overview

The Configuration Management Body of Knowledge (CMBoK) is an inclusive term that describes the sum of knowledge within the profession of Configuration Management. It includes what is known as Software Configuration Management and Hardware Configuration Management. As with other professions, the body of knowledge rests with the practitioners, technicians, and academics that apply and advance it. The full Configuration Management Body of Knowledge includes knowledge of proven traditional methodologies that are widely applied, as well as knowledge of innovative and advanced practices that have seen more limited use. It includes both published and unpublished material.

This chapter defines and explains several key terms and provides an overview of the rest of the document.

-- SmKershaw^? - 07 Feb 2003

(It seems redundant to include the sections here when they are generated automatically just above) -- NealFreeman^? - 13 Mar 2003 {I'm not sure what Neal is driving at here. This section works the same as the others. -- SmKershaw^? - 09 Apr 2003 }

1.1 PURPOSE OF THIS GUIDE

A project’s success is highly dependent on effective Configuration Management (CM). CM is necessary to enable a large team to work together in a stable and controlled environment, yet still have the flexibility needed for creative work. All too often, CM is viewed only as a costly and time-consuming effort to be either ignored or thrown together at the last minute. However, not doing CM guarantees that a project will be plagued by chaos, errors, permanent damage, low productivity, and unmanageable product evolution. A project in this sense is the sum total of all work carried out to create a product, whether software or hardware. Projects are normally organizationally defined and established to create, develop, deploy, and maintain products. -- SmKershaw^? - 15 Feb 2003

Configuration Management concerns the whole life-cycle, which may or may not involve several consecutive and parallel projects. Many projects fail because Configuration Management is not taken seriously enough as an intrinsic factor. It is placed too low organizationally in the project/organization and not given enforcement authority. The purpose of CM is to ensure that the controlled items have life beyond the project. This also has an impact to the way CM activities are organized; CM responsibility is often carried by the line organization, because it cannot be left for each project separately.

Naturally, CM implementation that does not provide any support to the project's work is doomed to fail. CM cannot be added on top after the project is finished. CM activities must be carried out throughout the project, from beginning to end. Those activities must be meaningful and reasonable to all project members. This is the key to the success of CM, and also an ingredient of the success of the project. Constricting the mission of CM to portions of the project/organization scope rather than the whole can be an expensive mistake.

Above to paragraphs Edited and incorporated into text - -- SmKershaw^? - 15 Feb 2003 { Edited and slightly reworded. } -- CarildaAThomas^? - 15 Feb 2003

There are numerous industry and military standards (i. e., US industry standards ANSI/EIA-649 “National Consensus Standard for Configuration Management,” EIA-836, “Consensus Standard for CM Data Exchange and Interoperability”, military standards like MIL-STD-973 “Configuration Management” or MIL-STD-2549 “Data Management”, MIL-HDBK-61 ”Configuration Management Guidance” or the NATO Allied Configuration Management Procedures “ACMPs 1-7” and ISO 9000 standards) that can be referenced as guides for establishing an effective and efficient CM process. Instituting CM Best Practices is the key to the successful development and maintenance of a product.

The primary purpose of this document is to identify and describe that subset of the CMBoK that is generally accepted. Generally accepted means that the knowledge and practices described are applicable to most configured environments most of the time, and that there is widespread consensus about their value and usefulness. Generally accepted does not mean that the knowledge and practices described are or should be applied uniformly on all configuration efforts; the Configuration Management team is always responsible for determining what is appropriate for any given configuration effort. -- SmKershaw^? - 15 Feb 2003

This CMBoK was created to provide information to those interested in Configuration Management and/or those assigned the responsibility for Configuration Management, to implement and maintain the application of product and data Configuration Management to hardware, software and firmware materiel items, as well as the respective documentation, in each phase of their life cycle, by consolidating Best Practices from the most common Configuration Management documents.

-- DirkWessel^? - 09 Feb 2003 {edited by -- SmKershaw^? - 15 Feb 2003 )

This document provides a basic reference for anyone interested in the profession of configuration management. This includes, but is not limited to:

• Executives
• Project Managers
• Team members
• Other managers
• Educators
• Consultants

This document is also to be used by the Configuration Management community as a basic reference about Configuration Management knowledge and practices for its professional development programs including:

• Certification of Configuration Management Professionals (CM Cert)
• Accreditation of educational programs in configuration management.

-- SmKershaw^? - 07 Feb 2003

1.2 WHAT IS CONFIGURATION?

According to The Random House College Dictionary (1980), configuration is defined as "1. the relative disposition of the parts or elements of a thing. 2. external form, as resulting from this; conformation." A configuration is established through analysis performed by people. A configuration is constrained by limited resources. A configuration is identified, controlled, reported, and audited. Configuration environments are often established as a means of achieving an organization's strategic plan or an organization's project plan. -- SmKershaw^? - 07 Feb 2003

The PMI PMBOK® states that "projects are undertaken at all levels of the organization." Configuration efforts are as well. Unlike projects per se, configuration efforts do not involve thousands of configuration professionals. Rather, configuration efforts may involve a single person or perhaps a dozen being led by a configuration professional. Configuration efforts can have durations from a few months to several years. The time required to set up a configuration environment does take time and it is best to plan on having one at the beginning of a project as compared to attempting to establish one part way through a project.

Configuration efforts may involve a single entity or project within an organization or may cross organizational boundaries. Configuration efforts are critical to the realization of the performing organization's business strategy because it is through configuration efforts that strategic plans and projects are implemented. Here are some examples where configuration efforts are used:

• Developing a new product or service
• Effecting a change in structure, staffing, or style of an organization
• Designing a new transportation vehicle
• Developing or acquiring a new or modified information system
• Constructing a building or facility
• Building a water system for a community

-- SmKershaw^? - 07 Feb 2003

1.3 WHAT IS CONFIGURATION MANAGEMENT?

There are many different potential definitions. The IEEE Standard 828-1990 defined Configuration Management "as a formal engineering discipline that, as part of overall system configuration management, provides the methods and tools to identify and control the (hardware/)software throughout its development and use." But in today's fast paced world, this definition falls short.

("Configuration Management" is included as part of the definition of "Configuration Management" here - is this a definition of Software Configuration Management - the brackets around the word hardware would suggest so - in which case the IEEE Standard must contain a complete definition somewhere else?) -- NealFreeman^? - 17 Mar 2003 {Neal, are you suggesting that we should define the word 'hardware'? Or am I missing your point (again). Perhaps if you offer an alternative to consider...-- SmKershaw^? - 09 Apr 2003 }

Like PMI's Definition of Project Management in the PMBOK®, Configuration Management is the application of knowledge, skills, tools, and techniques to configuration activities to meet project and organization requirements. But unlike Project Management, Configuration Management is accomplished through the use of processes such as: Planning, Identification, Controlling, Communicating, Executing, Negotiating, Reporting, and Auditing. Like Project Management, Configuration Management has a lot of processes that are iterative in nature, too. This is in part due to the existence of and the necessity for progressive elaboration in a Configuration Management effort throughout the life cycle; i.e., the more you know about your configuration, the better you are able to manage it. -- SmKershaw^? - 07 Feb 2003

Knowledge about Configuration Management can be organized in many ways. This document, has two major sections and __ chapters. -- SmKershaw^? - 07 Feb 2003

Configuration Management is the process of managing the full spectrum of an organisation's products, facilities and processes by managing all requirements, including changes, and assuring that the results conform to those requirements. A project’s success or lack thereof, is highly dependent on CM, the way CM is performed and the affects on risks regarding those projects.

Samaras and Czerwinski in the preface to their text Fundamentals of Configuration Management, published in 1971, define Configuration Management as "the discipline of ensuring that equipment or hardware meets carefully defined functional, mechanical, and electrical requirements and that any changes in these requirements are rigidly controlled, carefully identified, and accurately recorded." -- NeilSteeman^? - 16 Feb 2003 {Edited by -- SmKershaw^? - 23 Feb 2003 )

(Contribution moved to Appendix A -- CarildaAThomas^? - 24 Feb 2003)
-- NeilSteeman^? - 22 Feb 2003

1.4 HOW DOES CONFIGURATION MANAGEMENT RELATE TO OTHER MANAGEMENT DISCIPLINES?

Much of the knowledge needed to perform Configuration Management is unique to the profession (e.g., version control, builds, parts identification). However there is overlap into other management disciplines.

The relationship between Configuration Management and Quality Assurance has oscillated back and forth over the last 20 years. Nearly 20 years ago, Configuration Management was limited primarily to version control, library maintenance, builds all within a predefined set of Standards, Plans and Procedures. Back then, Quality Assurance was put in the position of monitoring the activities of Configuration Management while assuring that the library contents were legitimate for engineers to use.

As recently as 1990, the roles began to change as the Standards changed. Configuration Management began to take a more vital role in the scheme as compared to Quality Assurance. Eventually, the standards and practices changed to have Configuration Management responsible for most things relating to a project, while Quality Assurance declined in perceived importance.

Today, Quality Assurance is still responsible for the monitoring of the process, the identification of problems, providing guidance for change, and to assure that the documentation agrees with the configured items. One might ask how does Quality Assurance differ from Quality Control or Quality Test. It is simple. Quality Assurance doesn't test or control - it assures that all appears to be proper and going according to plan. Quality Control and Quality Test are self defining and don't assure, they identify problems when they exist.

Project Management and Configuration Management have some common areas of responsibility. Project Management is hard pressed to be successful without good Configuration Management. And it is largely because of the work of the Project Management Institute that the scope of Configuration Management has been made to encompass so much more than it did 20 years ago. Now, projects have to configure requirements, design, project planning records, processes, problem reports etc. It is Configuration Management that facilitates and services the needs of project managers. -- SmKershaw^? - 07 Feb 2003

1.5 RELATED ENDEAVORS

There are, obviously, lots of organizations without any official resource dedicated to Configuration Management. There are those organizations that establish Configuration Management on only the sub-project level. There are organizations that elect to establish Configuration Management at the project level, and then there are those organizations that address Configuration Management at the corporate level. It is also obvious that Configuration Management can exist in any number of organizational levels.

In recent years, the official standards of the past have been made obsolete. Projects are frequently in the unfortunate position of having to set standards without any guidelines. Therefore, each configuration effort is potentially radically different. There is a need for a common approach to Configuration Management, not just at the knowledge level, which this document is attempting to establish, but a common methodology across projects in a given organization. This has many benefits. Start-up cost savings of new projects in environments where both the methods and the tools are identical to existing efforts is huge. -- SmKershaw^? - 07 Feb 2003

Can we make a statement like the one in this last sentence without qualifying it with an example or a reference? -- NealFreeman^? - 17 Mar 2003 {As an example you would like me to site a source of a survey or something like that, right? I cannot site a specific survey, because I have not looked for one. However, I believe there are mountains of evidence in 'common' that shows that standardization saves time, resources and costs. It borders on common sense. Doesn't it?-- SmKershaw^? - 09 Apr 2003 }

1.6 TAILORING

The effectiveness, and therefore the success of a CM implementation relies very much on the adaptation of the different CM requirements to the specific project. The main CM functions cannot be used independently. Each main function should be used; however, the details have to be tailored to suit the life-cycle phase, the complexity, the size, the intended use, the degree of criticality, and the ability to support of the configured itesm. -- DirkWessel^? - 09 Feb 2003 {-- NealFreeman^? - 17 Mar 2003} {Deleted phrase "joint and combined interoperability" and edited just a bit at Neal's suggestion. Hope you don't mind. -- SmKershaw^? - 09 Apr 2003.

(Chapter split) -- CarildaAThomas^? - 18 Feb 2003

---

Chapter 2: The Configuration Management Context

Overview

In this chapter the Configuration Management context is explored. Two examples, acquisition and development life cycle diagrams are illustrated and discussed. The phases of the life cycle are identified with discussions concerning impacts upon it by Configuration Management. The key players in the configuration organization are described along with how the organization can influence configuration activities. Certain general management skills are required and described. -- SmKershaw^? - 11 Feb 2003 added which life cyle diagrams are discussed. KjMangan^? - 18 Feb 2003

2.1 ACQUISITION LIFE CYCLE PHASES AND CONFIGURATION MANAGEMENT

Configuration Management operates in all phases of the product’s existence, starting from the Conception to disposal of the hardware, software and firmware items.

The framework in which the different phases occur is called the “Acquisition life cycle”. The generic model for this process is illustrated in Figure 1.

* Acquisition Life Cycle Phases:

Figure 1 Acquisition Milestones and Phases

The life cycle process consists of decision points, or milestones, and periods of time, or phases. The project will approve passage from one phase to the next by officially accepting the phase upon completion of a successful milestone review.

2.1.1 Phase 0, Concept Exploration Phase

The concept exploration phase, Phase 0, is the first phase of a product’s life cycle. If it occurs at all, it typically consists of competitive, parallel short-term concept studies performed to investigate alternative operations and design concepts. The purpose is to identify, define, and evaluate the advantages/disadvantages, risks, costs, etc. of promising operational concepts and product design alternatives. The studies result in project characteristics and costs of total systems as reflected by their conceptual designs. The results are reviewed at the Milestone I decision point where promising candidates may be selected for further definition and development. The design characteristics of the selected alternatives generally provide a functional baseline of the system.

This phase is also considered as the Inception phase or Business Opportunity Feasibility Study and Business plan phase. -- DenisRoy^? - 17 Feb 2003

2.1.2 Phase I, Program Definition and Risk Reduction Phase

Phase I is used to further define and refine the operational concept or concepts and those alternative design approaches determined by the Milestone I decision process to be the most promising. The functional baselines are further decomposed into their lower-tiered subsystems. The performance requirements of the product are then allocated down to the lower level functions (allocated baseline).

This phase is also know as the Analysis and is part of the Elaboration phase. -- DenisRoy^? - 17 Feb 2003

2.1.3 Phase II, Engineering and Manufacturing Development Phase

Phase II of the acquisition process is used to complete a stable design for a product which meets the performance requirements and is producible, supportable, and affordable. Product capabilities are demonstrated through testing to validate design assumptions, and deployment planning is initiated. Low rate initial production is begun during this phase to provide the minimum quantities required to support operational testing and other design validation activities and to establish an initial production base for the product. The allocated baseline of a product is transitioned into a full product baseline during this phase.

This phase is also known as the Design phase and is defined as the Elaboration phase with the Analysis phase. -- DenisRoy^? - 17 Feb 2003

2.1.4 Phase III, Production, Fielding/Deployment, and Operational Support Phase

Phase III includes all design activities needed to:

• Correct deficiencies identified during Phase II test and evaluation activities and low-rate initial production.
• Produce and deploy a product.

Support activities respond to changes resulting from correction of noted deficiencies and other product baseline changes made to enhance producibility or otherwise improve the product. Additionally, they prepare for transition of the product to operations. Phase III is used to achieve and sustain an operational capability that satisfies mission needs.

This phase consist of the Construction and Transition phases together or Implementation and test phases. -- DenisRoy^? - 17 Feb 2003

-- DirkWessel^? - 09 Feb 2003

2.1.5 Pros and Cons of this Cycle

This model is great for static projects such as building a submarine or an airplane, and it is probably well suited to projects based primarily on acquisition rather than creation. Although these types of projects (generally government-funded) may consume the bulk of money spent. Organizations that manage these types of projects generally have a well-defined, if not entrenched, concept of CM with a large force reasonably well-trained in the particular CM implementation. This Life Cycle Model does not port well to today's dynamic development environments. -- CarildaAThomas^? - 12 Feb 2003 {Edited. -- SmKershaw^? - 18 Apr 2003 }

2.2 DEVELOPMENT LIFE CYCLE STAGES, TRANSITIONS AND CONFIGURATION MANAGEMENT

The traditional description of System Life Cycle, often known as the Waterfall model, is characterized by specific stages, generally summarized as:

1. Concept exploration
2. System architecture and risk definition
3. System detailed design and documentation
4. Development and unit testing
5. Integrated testing
6. Deployment
7. End of life

Each stage has a definite completion point, a Milestone, at which the current stage is considered finished and the next stage is entered. If the integrated testing stage fails, it may be necessary to back up into one of the earlier stages, or the project may have to be abandoned.

This type of project is expected to span years, and, according to sources such as Archwise Architectural Consulting and AntiPatterns author William J. Brown:

• Almost one third of all software projects are cancelled
• Two thirds of all software projects have cost overruns greater than 200%
• 80% of projects are deemed failures because they have not met one or more major goals

In contrast, the competitiveness of the various industries may demand a turn-around time measured in weeks, not years, and even firmware-based hardware projects may expect to have revisions to ship before End-Of-Life. These demands cannot be satisfied by a Waterfall model; instead they require a continuous development model comprised of Stages with Transitions. Traditional projects can be mapped onto this model, but it also allows for incremental development, quick release schedules, and it demands tight integration with Configuration Management at every Stage and Transition. A diagram of such a model is given in Figure 2. {Edited to make more generic -- SmKershaw^? - 18 Apr 2003 }

Figure 2 - Life Cycle Model

{You included End-of-Life or product retirement in the list of stages for the Waterfall model, but not in your diagram nor below in your Stages description. There are CM tasks associated with product retirement so for completeness it should be included. -- HelenHogan^? - 20 Feb 2003}

In the incremental model, different increments of the overall project can be at different stages in the Life Cycle, and transitions take place according to the defined Configuration Management process.

2.2.1 Life Cycle Stages

Each Stage has some subset of the project team working on it, some set of Configurable Items to manage, and will follow certain processes of the Configuration Management plan that is in place.

2.2.1.1 Stage 1: Requirements Definition and Validation Criteria

A requirement is a well-defined statement of a testable or provable desired result that will cause the creation or change of some element(s) of the project. Requirements need to be documented, often by a Subject Matter Expert(s) on the project team. Validation criteria must be determined for each requirement so that its fulfillment can be tested, a function of either QA, The SME or both. Requirements and validation criteria are the Configurable Items that need to be managed at this stage.

2.2.1.2 Stage 2: Architecture and Design

Traditional models may split these two functions, while many Agile and RAD methodologies envision them as proceeding more or less in parallel. Project team members will be architects, analysts and designers. The Configurable Items will be the models and the detailed design documents. Some UML tools produce executable (testable) models; in this case, the test results will also be Configurable Items.

{Use case documents, from which QA tests are derived, are also generated during this stage and are also Configurable Items. -- HelenHogan^? - 20 Feb 2003}

2.2.1.3 Stage 3: Development and Unit Test

At this stage, the different development methodologies diverge radically. At one pole, Extreme Programming dictates that each developer should create incremental tests corresponding to requirements (strictly, story outcomes) and perform them regressively as the development proceeds. At the other pole, unit tests will have been developed, probably by QA, in Stage 1, and will be executed in a development "sandbox" different from the individual developer's workspace and containing the most current development versions, possibly after a nightly (or regular) build. This sandbox is maintained by the CM team, and it is here that development check-ins will reside. There probably exists every imaginable permutation in between. The project team members are the developers and possibly QA. If there is a nightly build, this may be the responsibility of QA, or of the CM team. Configurable Items will be the developed entities (code, firmware, components, etc.), and results of the nightly/regular build.

{Configurable Items also include any compilers, applications, tools used to create the nightly/regular builds, as well as any third party components linked into or packaged with the build output. -- HelenHogan^? - 20 Feb 2003} {I put an etc. in the list, because the term is already defined in the glossary. I hope that's acceptable. -- SmKershaw^? - 09 Apr 2003 }

For smaller projects, or for defect fixes, this Stage may sometimes be bypassed in an effort to keep costs down, but there is a risk. {How is this possible? -- HelenHogan^? - 20 Feb 2003} {modified to address your concern. Is this ok to you? -- SmKershaw^? - 09 Apr 2003 }

In most cases, this Stage should also include rudimentary integration, installation and configuration testing performed by the developers. Stage 4 QA testing validates that the product works as designed, not that it works at all. -- HelenHogan^? - 20 Feb 2003

2.2.1.4 Stage 4: QA Build, Integration/Regression Testing

Where Stage 3 had a "dev" sandbox, this Stage has a "QA" or "test" sandbox. Any components not previously integrated will be integrated here. Unit tests will be regressed, system tests (integration tests) will be performed, and the system will be both verified and validated. That is, it will be proven to perform correctly and according to specifications. Performance testing, destruction testing, non-functional requirement testing (such as security) belong to this stage. The team members will be QA, and the Configurable Items will be any tests not already configured, and all relevant test results.

2.2.1.5 Stage 5: Deployment/Production

Deployment results in an actual release version; there must be a Release Description that enumerates all Configurable Items from the previous stages, as well as the versions of any tools used to create the deployed product, where applicable. Team members for deployment will vary according to the actual product.

2.2.2 Life Cycle Transitions

Transitions of development sets, which may be software or a combination of software and hardware, should occur according to and controlled by the processes within the Configuration Management plan.

Traditional development models can be emulated by only recognizing the forward moving arrows in Figure 2 (those pointing downward), and inserting a "Milestone" event next to each arrow. Any time an upward-pointing path is followed, the whole development effort is brought back to that stage, and a serious project problem is likely.

Upward-pointing arrows in Figure 2 represent an action by some team member at the Stage where the arrow originates. The project manager or some part of the project team will determine the transitions from Stage 1 to Stage 3, but thereafter, forward-moving transitions (3 to 4 and 4 to 5) are managed by the CM team.

2.2.2.1 Transition A: Original Requirements

This is a transition in the sense that, before there were requirements, there was no project. It is included here for completeness.

2.2.2.2 Transition B: Enhancement/Modification Request

This transition is triggered by one of two events. A deployed product may have planned enhancements (revisions, project release phases, increments in development). Or, the existing requirements definition as embodied in the architectural models may be incomplete or inconsistent, necessitating redefinition (modification) of the requirements. It is up to the Change Control Board (or its equivalent) to determine whether the request will be honored, rejected or deferred.

2.2.2.3 Transition C: Defect Report

A defect report may stem from:

• A build error in the nightly/regular build in Stage 3
• An integration error or test failure in Stage 4
• A user-reported defect in a deployed product

The defect report will be reviewed, assigned a status (accepted, rejected, deferred), and other characteristics such as severity, criticality, impact, and possible assignment, by the CM CCB.

(Bullet 1: Most Stage 3 build errors are handled very informally by direct discussion with the responsible developer. Very few require design modification and need to be elevated to a defect report as described here. I interpret your wording to mean every build error results in a defect report. -- HelenHogan^? - 20 Feb 2003 {Dirk, please address this. -- SmKershaw^? - 23 Feb 2003 }

2.2.3 Summary

Configuration Management is necessary and important at every stage of a project's Life Cycle. For very complex projects, Figure 2 may be an oversimplification. Other projects will require fewer stages than it depicts. However, the diagram is general enough that it can be expanded as necessary, compacted when feasible, and even mapped onto a project which is entirely or almost entirely acquisition.

-- CarildaAThomas^? 13 Feb 2003 (Excellent Software CM Life-cycle model. You are also absolutely correct concerning the Acquisition model. I hope that we can maybe find something general which can be used for software and hardware or we have to separate -- DirkWessel^? 13 Feb 2003 )

{I hope to have us create a general model with illustrations how it can be adapted to fit hardware, acquisition, software, integrated products. The CMMI is supposed to do just that, and I am going to troll it for ideas. } -- CarildaAThomas^? 14 Feb 2003

2.2.4 Pros and Cons of this Cycle

2.3 WHO ARE THE KEY PLAYERS?

A CM plan should designate certain roles that assume particular responsibilities within the CM team. In a large project, each role may be assigned to a distinct individual. Smaller projects may merge some roles within a single individual. Nevertheless, the roles and responsibilities are distinct and should be defined, however the roles are implemented in practice.

2.3.1 Media Librarian

The Media Librarian is responsible for the entire media library, its completeness, its integrity, its procedures, and the acquisition of the material retained therein. A media library or media storage area is a physical location - not storing them magnetically or electronically. While said library can contain magnetic material, the physical devices or media upon which it resides must be retained. Thus the term 'media' was selected. Anything referencing the term "configuration repository" means a soft-repository such as a repository kept through a vendored tool. A Media Librarian serves a different function from a Repository Manager. Specifically, the librarian:

• provides a method by which media can be checked in and out of the Library
• provides for and maintains an automated Library record listing all items on file
• logs new documents into the Library and database records
• prepares reports of Library contents as necessary
• notifies members of the project team when new media items are available
• controls baseline media with proper version control

A media librarian, manages items which pertain to, but do not precisely belong to, the configuration effort. This could be training material, including reference books on tools used, standards manuals, even the media (CDs) containing the version(s) of the tools used for development and/or deployment.

-- SmKershaw^? - 10 Feb 2003 -- KjMangan^? - 18 Feb 2003 -- CarildaAThomas^? - 21 Feb 2003 -- SmKershaw^? - 23 Feb 2003

2.3.2 Tool Technician

The Tool Technician (DBA) supports all database needs for the CM group. This includes:

• making authorized changes to tools
• facilitating the automation of various functions
• taking direction from the Software Configuration Manager

The responsibility for the automation of build processes and other CM processes falls first to the CM Manager, but it could be delegated to the Tools Technician to facilitate, and then to the Build manager to use them in accordance with procedures that would be developed. -- SmKershaw^? - 20 Feb 2003 -- HelenHogan^? - 20 Feb 2003}

2.3.3 Data Manager

The Data Manager:

• supports all Problem Reporting functions
• monitors and provides problem report assessments
• facilitates the CCB(s)
• carries responsibility for the integrity of all CM databases and tables

2.3.4 Release Manager

The Release Manager is responsible for proper execution of the process, and controls releases by:

• tracking all STRs assigned to a release as they move through the process
• having the capability of reporting the status of any one problem report to Management regarding its position in the process queue
• generating reports on the overall status of any given release (a collection of problem reports)
• determining when milestones have been met
• being able to anticipate and notify interested parties that an event is pending for one problem report or an entire release
• monitoring and maintaining the release cycle through automated routines and databases

The Release Manager has the responsibility to assure that there is a deployment plan, a complete Release Description, and that the deployment/release is done accordingly for each Release.

-- CarildaAThomas^? - 21 Feb 2003 {agreed and added. -- SmKershaw^? - 23 Feb 2003 -- ElisabethEk^? 11 Feb 2003

2.3.5 Build Manager

The Build Manager is responsible for creating the final deliverable and its documentation. The Build Manager is also responsible for creating the ‘as-built’ prior to initial testing by Quality Test and Evaluation, and any "nightly" or regular builds in a development sandbox. The Build Manager, with coordination from the Configuration Manager assists in the final production and packaging efforts of approved deliverables. Depending on the magnitude of the effort, these duties can be delegated to other groups in the organization, but the CM team is ultimately responsible for it. {Incorporated Helen's ideas into this paragraph. -- SmKershaw^? - 20 Feb 2003 -- HelenHogan^? - 20 Feb 2003}

2.3.6 Configuration Manager

The Configuration Manager ensures that answers are always available for such questions as: What product/version is this? What changed? What tests were run? What were the test results? and Where is the product located? The Configuration Manager is the central point for system change and has the following responsibilities:

• Develop, document and distribute the CM procedures, policies and plans
• Establish the system baseline, including backup provisions
• Ensure that no unauthorized changes are made to the baseline
• Provide the focal point for exception resolution
• Provide leadership and guidance to CM team

2.3.7 Director of Configuration Management

The Manager/Director of Configuration Management is obviously required only in large environments where there are multiple projects to guide. This person is responsible for the processes, procedures, tools, training, etc. to be streamlined and standardized. The Manager/Director of CM has responsibilities for budget and personnel, too.-- SmKershaw^? - 10 Feb 2003 -- CarildaAThomas^? 15 Feb 2003 -- SmKershaw^? - 23 Feb 2003

2.4 WHAT ARE THE ORGANIZATIONAL INFLUENCES?

There are many forces that influence Configuration Management. There are favorable influences and influences that hinder. This section will describe some of those influences and provide some information concerning organizational structures. -- SmKershaw^? - 10 Feb 2003

2.4.1 What are some of the hindering influences?

There are any number of things that can hinder a Configuration Management effort. Some of those things include funding, training, schedule, lack of management savvy, poor customer service attitude, and territoriality.

Some of these things in the list have a fairly obvious cause and effect. For instance, it is obvious that if the project is underfunded, the Configuration Management team may be the third group reduced or eventually eliminated to save costs (after the process improvement and documentation teams). Also, like new businesses that are undercapitalized - they don't last long - and CM efforts don't either.

When it comes to Training, one can look at the training of the Configuration Management team just as easily as the entire project team. Without proper training in processes, procedures, tool usage, etc, there will be problems, albeit not as catastrophic as a lack of funding, but troublesome at best.

Scheduling is listed because all too often, projects are ruled and governed by schedules, and CM is rarely in a position to alter them. Therefore CM efforts and CM personnel are hard pressed to comply. Working too quickly and cutting corners, while not advised, is often required and encouraged of CM Professionals. CM Professionals must be ready for these demands and address them in a way that minimizes the negative impact on the Configured Item(s).

The lack of Management Savvy is another road block all too frequently encountered. If upper management has not been convinced of the role of CM in correct and timely delivery, it will not be supportive of CM, and the CM team's efforts will be difficult. The role of the CM Professional in this case is to educate, sell, and persuade key members of the management team in an effort to gain their support. Another problem with management when they are not very CM savvy is that management tends to make choices and decisions without consulting CM. As CM Professionals, we must be aware that this can happen and to be prepared for those times.

Poor Customer Service Attitude, apart from the funding concern, is perhaps one of the worst things that can happen to a CM team. It used to be called the "Total Quality Concept": the notion that everyone on your CM Team must treat everyone with whom they work (bosses and peers alike) as customers. A bad attitude can drive a team and a project down faster than a bad rumor.

Lastly, territoriality is the sense that some people have that their job is theirs and their work is theirs and no one shall interfere. It is also known as a strong sense of 'ownership'. The problem with this is that when members of your CM team have this isolationist attitude, the team relationships will be strained and will eventually break down. For efficiency, CM teams cannot abide this personality/practice/style in team members.

-- SmKershaw^? - 10 Feb 2003

2.4.2 What are some of the favorable influences?

The aforementioned hindering influences all have opposites that apply here, and there are some specific favorable influences that can be mentioned. These would be good planning, common practices, and knowledgeable team members.

Good Planning from the beginning that includes Configuration Management will help ensure that a Configuration Management effort will succeed.

Having common practices between configuration efforts within an organization has great benefit not just from a cost savings perspective, but from an employee portability perspective, too. Those involved in development also enjoy unparalleled benefit from standard methods across projects.

Having team members aware of Configuration Management concerns makes the job of CM easier in that fewer problems will arise. Also, having CM team members aware of the development arena, the nature of the project, etc., makes for better communication and keeps favorable things happening.

-- SmKershaw^? - 10 Feb 2003

2.4.3 What are some common organizational structures?

There are at least three organizational structures in use by Configuration Management teams and organizations.

The traditional hierarchical organization chart would put a Director of CM at the top. Then each Configuration Manager reporting to the Director would be on the second level followed by each Team member reporting to the configuration manager on the third.

There are smaller firms that have only one Configuration Manager and there isn't any true CM organization within which he/she fits.

The third is a matrixed organization where a Director of CM is responsible for the assignment of Configuration Managers (and associated teams) to projects out of a "pool" of Configuration Managers. A single CM may be responsible for multiple projects.

-- SmKershaw^? - 10 Feb 2003 (Minor editing, grammar and rewording for all of Section 2.4) -- CarildaAThomas^? - 17 Feb 2003

There is a fourth organization structure. It consists of one manager of a CM group with team members reporting directly to him. This team handles all projects. The responsibility is distributed by functionality instead of projects. -- DenisRoy^? - 17 Feb 2003

(Chapter split) -- CarildaAThomas^? - 18 Feb 2003

---

Chapter 3: Configuration Management Processes

Overview

Configuration Management processes describe, organize, and complete the work of the project. Configuration-oriented processes specify and create the configuration's product. -- SmKershaw^? - 08 Feb 2003

The best CM process is one that can best (1) accommodate change, (2) optimise the reuse of standards and best practices, (3) assure that all requirements remain clear, concise and valid, (4) communicate (1), (2) and (3) to each user promptly and precisely and (5) assure conformance in each case. {Moved from above - written by Dirk Wessel--- SmKershaw^? - 14 Feb 2003 }

3.1 ESSENTIAL CM PROCESSES

There are some common processes that are essential to initiate, plan for, execute, control, and to close Configuration Management efforts. Because every organization's environment is different, even the best intentions have difficulty coming to fruition. With proper managerial support, the processes required are much easier to develop and implement. -- SmKershaw^? - 08 Feb 2003 {Ref to PMBOK®}

3.1.1 What does it take to initiate CM?

There are some things that must be in place prior to consideration for the initiation of CM processes. The first and foremost is funding and the second is management support and direction.

Once management selects a Configuration Manager for the project at hand (CM per project) or a new project is created (CM for the whole enterprise), the Configuration Manager begins to be actively engagedin the project's planning and scheduling. This task is a lot easier if performed at the start of a project. Coming in after the fact, the Configuration Manager's effort will be constrained by existing plans and schedules without much hope of modification.

The CM will need to understand the environment of configuration effort, the nature of testing, who the primary players are, and what are the processes for development.

Once these are understood, the CM can begin to develop appropriate Configuration Management Plans, operational charters for review boards, desk level procedures, automation routines for builds and deliverables, etc.

3.1.2 What Planning processes should be used?

There are three methods for such planning. One is where the Configuration Manager develops the entire set of processes in a vacuum without involvement from other team members. Sometimes this works, but only because the selling job which follows is extraordinary.

A second approach is where project team members are encouraged to contribute and evaluate plans for the processes. The developers and other team members will be the ones using these processes the most, and so have a vested interest in establishing good and functional ones.

A third is applicable to large organizations where the Configuration Management approach and the processes therein have been standardized. Only minor tailoring would need to be addressed by the Configuration Manager, making the planning effort very minor.

-- SmKershaw^? - 10 Feb 2003

3.1.3 Executing the CM processes - What works Best?

Executing or implementing the proposed CM processes that have been developed can be done in two different ways. First is the dictatorial approach which requires the deployment of the processes with very little fanfare. The second is generally more satisfactory.

Prepare presentations at two levels. Create one presentation with the managers in mind. Create a second with the developers and other non-management project team members in mind. Demonstrate and 'train' the team members and explain the transition from current methods to the new one and tell when the transition will take place. Also be prepared to take suggestions for changes and implement those changes as appropriate.

Once presented, make the switchover to the process quick and as painless to the team members as possible.

-- SmKershaw^? - 10 Feb 2003

3.1.4 How are the processes controlled?

Processes are tough to control in practice, while easy to control physically. The documentation for the processes can be easily versioned and controlled. The hard part is where the Configuration Manager is unaware that processes aren't being followed until it is too late - if at all. One way to mitigate a perception of lack of control is to keep the training effort current, and repeat it for all team members periodically. Another way to mitigate this perception is to encourage and support an active Quality Assurance Team and/or an active Process Improvement Team to monitor processes. The reasons why processes break usually are because they are not used properly, they are not understood, or they were circumvented without CM knowledge. This is why CM must be constantly and actively involved in the project's efforts at all levels.

-- SmKershaw^? - 10 Feb 2003 { Edited and slightly reworded. } -- DenisRoy^? - 18 Feb 2003

3.1.5 What process should be followed for closure?

Just as there are processes used during the life of the project, processes for closure must also be developed. Most of the time, projects just stop being funded and they end very abruptly. The proper closure incorporates the storage of at least the last release of the product, support equipment, documentation, databases, etc. The main objective of a good closure is to allow the project to be restarted where it was halted if required. This makes for a potentially costly closure effort which a lot of projects probably do not enjoy. -- SmKershaw^? - 10 Feb 2003 { Edited and slightly reworded. } -- DenisRoy^? - 18 Feb 2003

3.2 CONFIGURATION PROCESS INTERACTIONS

Configuration Managers coordinate the planning of their processes with other key project personnel. The persons include project, quality, and development leads. Once the processes are defined, CM, along with project personnel, coordinate the deployment of the processes. CM will maintain control over the processes, making modifications where appropriate.

At the end of the life of the project, Configuration Management must also define how the project will be closed out. Working with project management staff, CM determines what material/information shall be retained, eliminated or stored. -- SmKershaw^? - 11 Feb 2003

3.3 MAKING IT HAPPEN

Putting a process for configuration into action, as described above requires training, coordination, and cooperation. One method for implementing requires that training materials be developed and project personnel be semi-formally trained in the process. As soon as training begins, the configuration management team should be ready to put it into action immediately. Each team member should be given a copy of the process - even if it simply an outline. The entire process should eventually be written down and published to the team.

Some of the problems that can be expected include a lack of willingness on the part of team members to comply with the processes, or to even attend the training classes.

Sometimes, management forgets their original commitment to the effort and may need to be reminded.

3.3.1 Case Study: US Armed Forces

Here is how it was originally caused to happen in the US armed forces.

CM has been employed to control changes to products used in the defense of our country for many years. It has evolved from typed documents, handwritten logs and punched cards to use of sophisticated databases and networks.

During all these years of evolution, the basic core criteria have not been altered.

The criteria involves four (4) activities which are performed separately but in parallel.

• Identifying the product. This activity involves four steps, three of which you probably haven't done this way before now.
  • Write the customer's requirements for your product into a document that you and the customer agree on.
  • Identify your product by establishing a number for each item in it. This is the step you may already be doing.
  • Create an address for each item which relates each item number to every other item number in the product. The address is similar to your home address. It does not change even though the item number that resides there may change.
  • Relate each document that is used to design, develop, produce and support each item to the same address as the item.

• Controlling changes to the product: Each change is described in relation to the four steps in the first activity:
  • The impact on the customer's requirements document
  • The item number of the changed item
  • The address of the changed item
  • The documents related to that address

• Accounting for the changes when they are made to the items and the related documents: Each change is accounted for by identifying the revised documents which relate to the changed item.
• Auditing: Auditing the product for compliance with customer requirements before it is delivered. Each item in the product is compared to the documents that relate to it.

-- As related by NeilSteeman^? - 13 Feb 2003

3.3.2 Case Study:

{Need some more case studies here -- a good writeup on problems encountered, or problems averted, maybe a top-down (corporate process -> CM process) or bottom-up (CM process as a first step into Enterprise process management) -- CarildaAThomas^? - 18 Feb 2003

(Chapter split and minor formatting and editing) -- CarildaAThomas^? - 18 Feb 2003

---

Section II: The Configuration Management Knowledge Areas

---

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:

1. The Configuration Management of products/services and their defining technical data
2. 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 
             * Wha