Configuration Management

There are two major definitions for configuration management.

  1. It can be a term given to the identification, tracking and managing of all the assets of a project. This definition would be especially relevant on software development projects where the “configuration” refers to the collection of artifacts, code components, executables, etc. The items that you will track under configuration management are called “configuration items” in the Capability Maturity Model (CMMI). These configuration items can be interpreted quite broadly to include things such as:
  • Documentation and all project management deliverables
  • Deliverable descriptions and templates
  • Design elements
  • Code, in which case your configuration management process would include your software change management process.
  • Test scripts, test plans, test cases, etc.
  • Hardware and software
  • Your final software deliverables
  • Other physical assets of the project, including furniture, supplies, machinery, etc.
  1. It is also a term given to the identification, tracking and managing of the metadata that describes the products that the project is creating. This is closer to the definition of configuration management used by the Project Management Institute (PMI). In this definition, the configuration of an asset is basically the detailed features and functions associated with the asset. For example, if your project resulted in the manufacturing of a laptop computer, the configuration would refer to the size of the hard drive, speed, DVD specifications, etc.

Most projects do not worry about tracking physical assets such as equipment, supplies and raw materials. If these assets need to be tracked, it is done at an organizational level. For instance, tracking and managing personal computers is usually done at a company or division level. The project manager of an individual project may need PCs for the team, but he doesn’t have to track and manage the asset.

If your project is worried about asset tracking, this is usually done outside of the realm of the project manager, and is instead handled by specialists on the team. For instance, if your project involves building an airplane, the tracking of materials is vital. However, there are team specialists that are assigned to manage this aspect of the project. If you are on a software development project, you need to track your software code. However there are software change management tools that will manage these assets.

All that being said, some very large projects do need to manage configurations, and if they do, the process can be managed using many of the techniques in this scope management section.

The following components make up the Configuration Management Process.

  • Planning. You need to plan ahead to create the processes, procedures, tools, files and databases to manage the configuration. You also may need to gain an agreement on exactly what assets are important, how you will define them, how they will be categorized, classified, numbered, reported, etc. The results of this up-front planning are documented in a Configuration Management Plan.

Planning is a very important part of configuration management since there are many ways that the configuration items can be defined. It is possible that your definition will only include meta-data, or information about assets, and not the actual assets themselves. You might also be tracking the actual assets.

Part of your planning process should be to assign configuration tracking numbers to each type of configuration item.

  • Tracking. It is important to understand the baseline for all configuration items. In other words, for each configuration item, you need to understand what you have at the beginning of the project. In many cases, you may have nothing to start with. In other cases, like physical assets, you may have some assets to begin with. The purpose of your tracking processes is to ensure that you can track all changes to a configuration item throughout the project.

You need processes and systems designed to identify when assets are assigned to your project, where they go, what becomes of them, who is responsible for them and how they are disposed. Since a project has a concrete beginning and end, ultimately all the assets need to go somewhere. This could be in a final deliverable, into the operations/support area, scrapped, etc. You should be able to dissect each major deliverable of the project and show where all the pieces and parts came from, and where they reside after the project ends.

The same ideas apply if you are tracking asset metadata through configuration management. You need to understand the starting point of the configuration and track any changes made during the project. These can be quite detailed. For example, if you are manufacturing a laptop computer, a new requirement to be able to support a new type of hardware could result in dozens (or hundreds) or detailed configuration changes to the machine.

  • Managing. Managing assets means they are secure, protected and used for the right purposes. For example, it doesn’t do any good to track purchased assets that your project does not need in the first place. Also, your tracking system may show expensive components sitting in an unsecured storage room, but is that really the proper place for them? Managing assets has to do with acquiring what you need and only what you need. You also need to make sure you have the right assets at the right place at the right time.
  • Reporting. You need to be able to report on the configuration, usually in terms of what you have and where they are, as well as financial reporting that can show cost, budget, depreciation, etc. If you are tracking configuration metadata you should be able to report out a complete set of the current product specifications.
  • Auditing. It is important that the integrity of the configuration process be validated periodically through audits of the status of configuration items. This can include physically inspecting or counting these items and comparing them against the expected results of your configuration management system. You will also want to audit the configuration change process to endure that the appropriate processes are being followed.

Auditing involves validating that the actual configuration elements (whatever they are) at any given time are the same as what you expect. Many projects get in trouble when they start to lose track of physical assets (for instance, material, supplies, code or other configuration items) or if the physical characteristics (metadata) of your deliverables is different that what you expect.

The auditing process is used to validate that the configuration elements match up with your expectations. These expectations are based on the original baseline, plus any change requests that you have processed up to the current time. For physical assets this would mean that your inventory reports match a count of the actual physical assets at the current time. If your configuration elements involve descriptions and other metadata, you would be validating that the descriptions and characteristics are consistent with the way the deliverables are actually being built.

If the audits do not result in the expected results, it would mean that your configuration tracking process is inadequate and that you should improve your processes to account for all changes. You would need to identify the ways that your configuration can change over time, and validate that you are catching all of these instances in your configuration tracking process.

Configuration audits are difficult and expensive in terms of resources and time.  Nevertheless, they are vital in ensuring that the final solution is complete and correct and that you have accounted for all of the configuration assets used to build the final solution.

If you practice configuration management on your project, it is suggested that you have a specific person identified as the configuration manager. This may be a part-time role, depending on how much asset tracking and management your project does. This person is responsible for the overall process, with focus on the planning, management and auditing responsibilities. If your project is large enough, you can also designate a configuration librarian. This is an administrative position that focuses on the legwork and follow-up needed for the tracking and reporting responsibilities.

Depending on the size of the project, you may need a specific Configuration Board, which is made up of managers and senior staff members. This Configuration board will approve the overall configuration plan, the configuration items, and they can even approve specific large changes to items that fall within your configuration management process.

Of course, if your project (or program) is big enough, such as building an aircraft, you are probably going to have a whole department doing this work, perhaps under the direction of the Purchasing / Procurement department.

Discover more from CMGuide

Subscribe now to keep reading and get access to the full archive.

Continue Reading

Scroll to Top