| Intro | Context | Processes | Planning | Tool Mgmt | Activities | Projects | Risks | Procurement | Metrics |
This chapter defines and explains several key terms and provides an overview of the rest of the document.
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.
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.
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.
This document provides a basic reference for anyone interested in the profession of configuration management. This includes, but is not limited to:
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:
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. --
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:
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?)
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.
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."
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.
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.
Can we make a statement like the one in this last sentence without qualifying it with an example or a reference?
| Next: Context |