The adventures of CM Man.

Faster than a speeding Engineering Change Proposal. More powerful than a Document Template. Able to leap different Product Versions in a single bound. Look! Up in the sky. It's a bird! It's a plane! It's CM Man!

Yes, it's CM Man (or CM Woman, but for the sake of simplicity, let's go with CM Man)--strange visitor from another planet who came to Earth with powers and abilities far beyond those of mere mortals. CM Man--who can change the course of mighty configuration items, bend risks in his bare hands, and who, disguised as Mark Trent, mild-mannered configuration manager in a great DoD program office, fights a never ending battle for Truth, Justice, and Change Control Management.

Superheroes abound in comics, TV, and the movies. It's too bad that they don't exist in real life. Or do they? There may be a superhero in your organization, protecting you from all sorts of evil villains. That person is your configuration manager, your CM Man. Okay, enough of the hyperbole. Configuration management doesn't really produce superheroes, but it can save you and your project from many problems. The CM team may seem like visitors from another planet, but their guidance and their requests are there for good reason. Let's take a look at some basic CM so we all have a better understanding.

While CM is absolutely critical to software development projects, it is important to all projects. According to Anne Hass in Configuration Management Principles and Practices, configuration "derives from the Latin com-, meaning 'with' or 'together,' and figurare, 'to form.'" Loosely interpreting that, she says, configuration means "to form from a relative arrangement of parts." Hass defines configuration management as the "unique identification, controlled storage, change control, and status reporting of selected intermediate work products, product components, and products during the life of a system."

I like the simpler definition of "looking after what you've got so far."

Functions of CM

There are five basic functions of CM, which apply to any project. They are:

[ILLUSTRATION OMITTED]

* Planning and management

* Identification

* Change management

* Configuration status accounting

* Verification and audit.

Planning and Management

Planning and management is just what it says. It covers the normal planning to define and establish organizational responsibilities, in this case, the CM Team's responsibilities as well as the CM-related responsibilities of others. It includes determining the necessary resources and facilities that are needed. It also ensures that the appropriate CM tools, processes, and activities are available and applied. Continuous improvement is another sub-function under planning and management, as is the responsibility for writing, maintaining, and following the configuration management plan. With a slight change of wording, those responsibilities could apply to the planning and management function of any group in an organization or the organization as a whole. The one area that is different or unique is the responsibility to ensure data preservation and interoperability.

Data preservation and interoperability means that all of the configuration items and documentation are stored, correct, and available when needed. In other words, the CM library is maintained with all the appropriate material, and that material is up-to-date (correct versions) and accurate.

Configuration Identification

Configuration identification determines the structure of all products and their associated documentation; defines performance, interface, and other attributes for items; provides unique identity to products, components, and documentation; prescribes identification markings (if required); modifies product and document identifiers to reflect incorporation of major changes; maintains release control and baseline definition; provides reference for changes and corrective actions; and correlates document revision level to product configuration, which enables users to distinguish between product versions, allows people to correlate a product to the appropriate instructions, and correlates items to warranty/service life. Whew! What that long, complex sentence boils down to is that configuration identification determines how document control numbers and version numbering are applied and used so that everything is labeled correctly and understandably. This article will not describe any of the numbering schemes. I will leave that to the CM Man in your organization.

Change Control Management

During the lifecycle of a product, many changes take place. Change control management is usually a shared function of both CM and the Change Control Board. Change decisions need to be based on knowledge of the complete change impact to the project and the eventual user. That helps limit changes to those that are necessary or offer significant benefit to the project, the user or--it's to be hoped--both. The CCB will normally facilitate the evaluation of cost, savings, and trade-offs, ensuring that everyone's interests are considered. On the CM side is change control management. CM helps maintain consistency between the products and all relevant documentation. The CM process also documents and limits variances in a given product. Finally it provides for continued supportability of the product after a change.

Configuration Status Accounting

This is a fancy name for having information on products and processes. Having the right information available enables anyone to retrieve data and background concerning change decisions and change impacts. It can answer enquiries concerning design change planning, design problems, warranties, shelf- and operating-life calculations. It provides people with access to complete configuration information on your products and processes. It is a source for configuration history and accurate identification of each delivered product. Having that information improves the project's or the user's capability to identify, produce, inspect, deliver, operate, maintain, repair, and refurbish products. All of these actions are necessary. Without CM, that information might or might not be available, and its accuracy would certainly be questionable. And it can save you (or ruin you) with your boss or your boss's boss when there are questions.

Verification and Audit

The final function is verification and audit of project office activities. Sometimes this is partially shared with quality assurance. For instance, CM and QA together ensure the product design provides the agreed-to performance capabilities. Other activities may fall solely under CM, such as validating the integrity of the configuration documentation and the consistency between a product and its documentation. CM is responsible for establishing a product baseline and making sure that an accurate configuration is the basis for operation and maintenance instructions, training, spares, and repair parts.

CM Man and the Hordes of Evil

CM Man has to face many evils in projects across DoD. Below are a few examples that are typical of the problems when CM and CM processes are not used properly.

A technician flies across country to install new equipment. The equipment is there and the room is ready, but he has the wrong version of the installation guide and doesn't know it. After all the work to get everything installed, it doesn't work. After trouble shooting, he finally discovers the problem. After getting the right version of the guide, it's all fixed--but it has taken extra time and effort. It could easily have been prevented with the right version first time around.

A programmer takes what he believes is a module of source code that is part of the latest version of software and begins to make significant changes. When he tries to integrate it back into the main software program, it won't work. Why? Not because he did poor work or made a programming error, but because the version that he was using was not the latest, and his changes were incompatible with others already made. Version control is critical, especially in software.

In the 1970s, a number of C-130s were converted to AC-130 gunships. The modifications were major. One of the changes was the installation of racks of electronics in the fuselage. However, the equipment was installed in different places in the racks on many of the aircraft, creating a maintenance nightmare. Standardization makes maintenance and safety much easier.

[ILLUSTRATION OMITTED]

Two people begin to work on the same source code at the same time. Each goes in a slightly different direction with the work. Neither knows that the other is working changes, and there is, therefore, no coordination. The work of one (or both) is wasted. A good CM library and strict checkout procedures can prevent wasted efforts and conserve resources.

The Army Reserve buys a different type of server from that of the Army National Guard but plans to use the same software applications for mobilization and related activities. The applications don't work on the new servers, and significant rework on the applications is required resulting in two versions of the applications that have to be updated and tested every time there's a change. Coordination and standard equipment purchases could have saved significant dollars.

CM Man can help with these and other, similar problems. A good CM program will have:

* Procedures for placing items in the CM library

* Procedures for checkout of items for further work

* Procedures for release of items for production

* Templates for item approval

* Templates for release requests

* Templates for standard documentation

* Identification of standard equipment, software, and processes.

Benefits, Benefits, Benefits

The benefits of a good CM process are manifold. One of the biggest is resource savings. Those savings come from a number of areas, such as economies of scale in purchases (100 identical servers are cheaper than 100 unique servers); ease of maintenance (maintenance information, training, and spares for that one type of server are much cheaper than for the different servers); updates and changes are less time consuming (testing a few components or builds is much faster than testing for many); and the development work is faster and cheaper without all the rework and errors generated when CM is poor. It is also much easier and faster to generate the documentation using templates and leveraging previously developed work.

People build up specific expertise. For example, a development team can concentrate on one version of equipment and its operating system rather than all of the various nuances associated with different platforms and their operating systems. This extends to the users and maintenance folk also.

CM can reduce development time. By the reuse of components, modules, software, or product configurations, good CM speeds up development as well as keeping costs down. The use of templates for document preparation can provide time savings, also.

Finally, there is a history of the project, with all of the versions of the product(s) and the documentation that goes along with each. This can be a life saver (or a career saver). It also helps, or can help, later projects. (However, it may not be worthwhile to go back and create documentation if it wasn't created originally, just to fill the squares.)

CM Man is Your Friend

CM Man is not there to stop change and advancement. He is there to help. His goal is to fight the evil hordes of wasted efforts and wasted resources. He is not a superhero, but an everyday man (or woman) who can assist PMs with the development of quality products in the shortest time possible. And this article presents only an overview of CM in projects--there are a lot more down-in-the-dirt activities that CM men and women perform to keep projects out of trouble.

So don't ignore CM. Don't fight it. Make friends with CM Man, and let him help you.

The editor welcomes comments and questions and can be contacted at [e-mail]

Turk is an independent consultant. He is a retired Air Force lieutenant colonel and defense contractor. He has supported information technology projects, policy development, and strategic planning projects for DoD, other federal agencies, and non-profit organizations. He is a frequent contributor to Defense AT & L.