The Four Configuration Management Functions:

The Relationships

Configuration Management: Functional Relationships

The four major configuration management (CM) functions, (1) Identification, (2) Control, (3) Accounting, & (4) Auditing are integrally related to one another and to the raison d'etre for CM. So, what is the raison d'etre for CM; i.e., why do organizations pay people to do this function?

As stated previously in this page and website, the CM function, is not an end it itself, but is a tool which can be used as a means to an end, which is a product that meets the customer's requirements, and which can be sustained throughout its planned lifetime. The four CM functions interact and interface with each other to help achieve a successful product. Below is an example of an extremely successful product.

B2 Bomber

Here is a product that is a great success story. The B2 Bomber was the result of diligent program management and careful, coordinated configuration management. Today, it is indispensible for America's efforts to combat terrorism.

Interaction of the Four CM Functions

In as few words as possible, the four CM functions interact as follows: The Identification function defines the product over its lifetime, from conception to retirement. The Control function manages changes to the product identification, from conception to retirement. The Accounting function records the history and current status of the CM Identification and all proposed changes, including those approved, partially approved, and disapproved. The Audit function verifies that the actual physical product agrees with and is accurately described in and depicted by the CM Identification documents. These functions are the four links in the CM chain. A weakness in any link can make the entire chain void.

Planning and Executing for success

The CM process can be an indispensable tool when planning and executing for success in the acquisition process, whether it be military or commercial. Here is an example of how the four CM functions could work together to support a successful end-product. In the year 2010, the U.S. Army needs a new tank-like vehicle for ground operations. The Identification function would document the requirements of the vehicle in a system specification. This specification would document the required capability of the vehicle, such as speed, fuel type and efficiency, armor rating, required weapons, operating environment, and required interfaces (e.g., interface with the Army's communication system, interface with the Army's ammunition of choice, etc.) This specification would be added to the development contract at the time of award. Throughout development, the Control function would be used to approve/disapprove proposed requirements changes. Approved changes would be added to the specification and the contract itself. The Accounting function would record the action taken on each proposed change and would document the current version of the specification. Finally, the Audit function would be used to ensure that the as-built, as-tested version of the vehicle actually met the specification requirements. Mistakes in any one of these functions could result in a vehicle that failed to meet its intended requirements.

Common mistakes would include a failure to add approved changes to the specification itself. This could result in an auditor not having the information to properly check required system performance during the Audit function. Likewise, a mistake in the Accounting function could result in the wrong version of a specification being used as a baseline from which to evaluate and approve or disapprove a proposed requirements change. A failure in the Identification function to include all required interface requirements could lead to many expensive changes be required and a great burden of activity for the Control function. Conversely, a specification which was overwritten (one that contained too much design detail, instead of functional requirements) could also lead to a burdensome and expensive level of activity for the Control function.

These concepts also apply to full scale production. For example, a failure to document approved changes in the drawing package (aka Technical Data Package) could result in actual mistakes to the assembled end product (A failure to include required parts; using the wrong parts; incorrect assembly; etc). Likewise systems or equipment being used in the field (e.g., on the road, in the sea, in the air, etc.) require configuration management. Hardware or software changes to actual end-products (automobiles, planes, PCs, etc) must be documented so that the user or maintainer of the item can do his/her job. For example, installing a retrofit into an item requires that the current physical status of the item be correctly identified. Otherwise, the retrofit might not be possible or might be done incorrectly. E.G., trying to install a new software application into a non-compatible operating system.

Back to Homepage