Configuration Management Tools

Definition: Webster defines a tool as "something regarded as necessary to the performance of one's occupation or professional task. [Words are the tools of my trade.]" Configuration Management (CM) tools come in several forms. For systems engineers and their sponsors, these tools include best practice methodologies, standards, documentation, managed environments, manual tools, automated tools, and leadership skills. These require and enable the discipline and rigor needed to plan, stand up, implement, and carry out CM successfully.

Keywords: automated tools, configuration management policy, program management plan, statement of work (SOW), tools

MITRE SE Roles and Expectations: MITRE systems engineers (SEs) are expected to have a sound understanding of configuration management principles, how program management and project management view configuration management, how the development organization initiates configuration control, how the developer implements configuration management, and how the government sponsor or sustainment organization continues configuration management following product delivery. MITRE SEs are generally involved in identifying requirements for automated tools to support the CM process. Rather than selecting specific automated CM tools, MITRE SEs need to begin with requirements that take into consideration and address the roles of the technical and nontechnical elements of CM, including documentation and the traditional software configuration management elements of hardware and software. To be successful, it is essential to understand CM. CM success is a function of leadership's insistence on its implementation and use.

CM is defined in the SEG's Configuration Management topic. Within that context, it is important to note that CM is not all things to all people nor is it program management. It is a tool used by program management. It is not document management, but it is a partner tool that document management uses. It is not requirements management or engineering, but it is a tool with important connections to requirements engineering activities and processes.

Automated CM tools can help to:

  • Record, control, and correlate Configuration Items (CIs), Configuration Units (CUs), and Configuration Components (CCs) within several individual baselines across the life cycle.
  • Identify and control baselines.
  • Track, control, manage, and report requests for changes to the baseline CIs, CCs, and CUs.
  • Track requirements from specification to testing.
  • Identify and control software versions.
  • Track hardware parts.
  • Enable rigorous compliance with a robust CM process.
  • Conduct Physical Configuration Audits (PCAs).
  • Facilitate the conduct of Functional Configuration Audits.

Best Practices and Lessons Learned

Start at the beginning. Get top-down buy-in on the value of CM. A successful CM program is supported and enforced by leadership. Set or cite a CM policy/directive that authorizes a high-level Configuration Control Board (CCB) (e.g., Executive CCB) at the highest authority with links to higher and lower boards. Coordinate CM planning with requirements development and management, quality assurance, process improvement, independent validation and verification, and existing enterprise processing centers to ensure engagement and integration of production stakeholders. Ensure that the Program Management Plan contains a program level Configuration Management Plan. Coordinate with the acquisition organization (e.g., contract officer, contract officer technical representative acquisition adviser) to ensure that adequate CM requirements are in the statement of work (SOW). In addition to the standard CM requirements, the SOW should include formal CM audits of the contractors to measure compliance with the agency/customer CM policy, agency/customer regulations, etc.

Audit early and often. Set standards early, and audit for compliance. Identify or establish agency/government/enterprise policy, plan, practice, procedures, and standards, including naming and tagging conventions early. Audit internally to ensure that the Program Management Office is following the policies and procedures. Consider an annual demonstration of contractor alignment with Software Engineering Institute Capability Maturity Model Integrated (CMMI) CM [1], Information Technology Infrastructure Library CM [2], uniform top-level CM processes—ISO-9001 [3], and National Consensus Standard for Configuration Management (ANSI EIA 649) [4]. Consider using a CMMI Practice Implementation Indicator Description format, such as those used for CMMI assessments, and include conclusive evidence for the demonstration. Schedule the demonstration annually.

Considerations for automated CM tool acquisition. First, ascertain the management method that is most significant for your project or system and ensure that the tools serve that purpose. Next, define the requirements. Identify the automated CM tool requirements before acquisition decisions are made. It is critical to establish requirements for the automated CM tool by collecting available CM plans, policy, process, procedure, and instructions and by meeting with the relevant stakeholders. Be certain to include business, user, contractor, and operations and maintenance stakeholders to define the automated CM tool requirements.

These requirements should include the following considerations:

  • Requirements management
  • Document Management version control
  • Controlled repositories
  • Configuration identification and control, including hardware, software, etc.
  • Processing and tracking of requests for changes
  • Audit support
  • Configuration Status Accounting Reporting (CSAR)
  • Baseline management (software, documentation, requirements, design, product, production)
  • Software development check-out/check-in
  • CM of environments (development, test, product, production); may be multiples of each
  • Multiplatform capabilities (personal computer, local area network, Web, mainframe, data centers, etc.)
  • Release engineering of all types of requests for changes (e.g., normal releases, routine releases such as operating system and security updates and patches, break fixes, emergency)
  • Transition CM tools into the sustainment activities
  • Automated CM tool within the approved technical reference model or fully justifiable for a waiver

CM tool selection needs to include a discussion of the selection criteria based on the requirements, evaluation of tools, and selection of tools

CM Lessons Learned and Pitfalls

  • Depending on the level of support from the program leadership and stakeholders for CM, tools may not be included as part of the overall CM plan or planned for acquisition. If automated tools are acquired, ensure that program leadership is aware of the need for planning short-, mid-, and long-term needs for installation, establishing the baseline data, and training, updating, securing, and maintaining the tools and the associated process and procedures needed to use them effectively.
  • Set expectations early. CM and configuration change control are all about requests for changes, regardless of what they are called (e.g., change requests [CRs] or Engineering Change Proposals [ECPs]), and the impact of change on scope, cost, and schedule.
  • Keep informal and formal communication open with CM as an agenda topic in meetings and gate reviews. Do not shoot the messengers.
  • Consider release management separate from CM. Do not assume that the CM organization can do release management.
  • Everyone may know CM, but training will be needed to orient staff on how CM is done in your particular organization.
  • Coordinate with those responsible for business continuity of operation and disaster recovery. Some will assume that CM will provide the capability to restore the entire system if the need arises. This is not a safe assumption unless your CM tools are designed with this capability in mind.
  • Identify, establish, maintain, and control the necessary development, test, and production environments, including the automated CM tools, hardware, software, operating system, security, access control, and supportive infrastructure.
  • Contractors and periods of performance may come and go. The transition from one contractor to the next should include an inventory of baselined hardware, software, documents, etc. PCAs on the departing contractor product should establish what the new contractor inherits. Gap analysis should be performed to determine the delta and provide input to the contract closure activity prior to making final payments to the departing contractor.

Conversely, if the preceding lessons are not applied, the consequences can lead to CM failure. Watch for these indications that things are not going well: leadership support is not evident, formal CCBs are not chartered or recognized as change approval authorities or do not function, "lanes in the road" are not defined and chaos reigns, attendance at CM meetings (CCBs, engineering/technical review boards, and impact assessment boards/teams) declines or is nonexistent, or CM only identifies cross program/project impacts when something breaks down.

Automated CM Tools Lessons Learned

  • Buying a CM tool will not establish an appropriate CM program for your effort.
  • It is unlikely that a single automated CM tool can be all things to all stakeholders by integrating all required elements across all platforms. So-called commercial off-the-shelf "suites" of tools may not contain integrated capabilities to suit the enterprise. When they have the potential for integration, adapting the products after they are taken out of the box often requires significant effort. What may support software development with check-out/check-in features may be bundled within a "suite" of standalone automated tools without any integration. Tool administrators may only be able to export to a spreadsheet for reporting. Automated tools may control one area well, but they may not be suited for other areas.
  • The automated CM tools used within the development and test environments may not be compatible with those in the production environments. This may require development of semi-automated or manual processes. Security and firewall infrastructures may present additional challenges.
  • Automated CM tools may offer flexible options, including the ability to design your own request for change form and flow. This has inherent pros and cons. The acquirer often assumes that the tool will deliver a request for change process out of the box with no other development effort needed. The capabilities delivered out of the box are directly impacted by the installation/customization of those tools. It is important to understand the need for development and administration of the automated tools and to set expectations early on.
  • When planning the acquisition of the automated CM tool, consider the initial and longer term costs, including licenses, and labor cost to install and develop it so it is usable for your program. Plan for on-going system administration, security, maintenance, back up, and recovery as well as business continuity of operation and disaster recovery. Consider the ability of the tool, and data contained within it, to be transitioned from one contractor to another, which is sometimes the case when a program transitions from production to sustainment.
  • Avoid an approach that implies that the tool will establish the standard and solve the problem. It is not best practice to say "Here is the solution. What is your problem?"

References and Resources

  1. CMMI Institute, Capability Maturity Model Integrated (CMMI) Models, accessed August 28, 2017.
  2. Axelos, Information Technology Infrastructure Library (ITIL), accessed August 28, 2017.
  3. ISO-9001:2015, Quality Management Systems—Requirements, accessed August 28, 2017.
  4. ANSI EIA 649, November 20, 2014, National Consensus Standard for Configuration Management, accessed August 28, 2017.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team