How to Control a Moving Baseline

Definition: Configuration Management (CM) is the application of sound practices to establish and maintain consistency of a product or system's attributes with its requirements and evolving technical baseline over its life [1].

Keywords: CM, CM process, configuration baseline, configuration management, modification management, moving baseline, UCN, urgent compelling need

MITRE SE Roles & Expectations: Although configuration management is not a primary focus of MITRE's systems engineering, it is an integral part of the overall systems engineering job and is an area MITRE systems engineers (SEs) are expected to understand sufficiently. SEs need to monitor and evaluate the CM efforts of others and recommend changes when warranted.

One of the more challenging tasks for the SE of a particular program is to assure the application of sound CM practices in environments where change is pervasive and persistent.

Increasingly the types of programs that MITRE supports are becoming more complex and reliant on commercial technology. Many of our customers' users are facing asymmetric threats and constantly changing mission environments. The result is that the programs we work on have constantly changing baselines that need to be managed efficiently and effectively. This is most evident in programs that are already fielded and have substantial development efforts taking place in parallel. In these situations, the government is responsible for the overall CM of the program (fielded baseline as well as oversight of development efforts being done by industry).

Best Practices and Lessons Learned

The following practices and lessons learned are from MITRE experiences:

CM is "paperwork"—the "right paperwork." Tracking and managing a fielded configuration baseline is largely an exercise in documentation management. The configuration baseline is an amalgamation of various documents (hardware drawings, software version descriptions documents, interface control/design documents, technical orders, etc.), and is normally managed as site-specific configurations for fielded systems. Development contractors and vendors maintain configuration control of their various software products and applications that make up the system, but the overall configuration baseline is at the system level and managed by the customer organization or program office. From this perspective, configuration management really means maintaining positive control over the paperwork that describes the configuration. The hard part is to determine what level of documentation provides the most accurate representation of the configuration. Experience has shown that the hardware drawings, software version descriptions, technical orders, and systems specifications provide the most bang for the CM buck.

"Shock treatment CM" can be useful—when used sparingly: CM normally works well up until programs are fielded and delivered to operating locations. After fielding and over time, CM can break down. Users at different operating locations have an interest in the system doing specifically what they need, and needs between differing locations can vary enough that the baselines begin to diverge. This can also happen in development programs when different versions of a system are delivered to different users with slightly different baselines. This poses a fundamental dilemma and choice for CM. Is the goal to manage a common core baseline with divergent parts for different users and locations? Or is the goal to maintain a single baseline (for interoperability or standard operations and training reasons, for example)? Either answer can be right. The problem arises when there is no explicit discussion and decision. The usual consequence is that CM breaks down because the different customers and locations start to assume they have control and modify the baseline themselves.

How can this situation be remedied? Sometimes "shock treatment" is the only way to re-assert CM authority. Essentially, this is the threat of closing down an operation due to critical certification or security baselines not being upheld. It is an extreme measure, but if the operation of the system is critical enough to warrant consistent certification of operations or security, it can be a useful hammer. As an example, in one government program, the Designated Accreditation Authority (DAA) became aware of baseline control deviations that resulted in concerns over the integrity of the system. Sites (operating locations) were put on notice by the DAA that their security accreditation would be jeopardized if they did not adhere to the configuration management controls instituted by the program office. This strict enforcement technique sent shock waves throughout the user community, the sustainment organization, and the program office. Uncontrolled baseline modifications soon became a thing of the past. "Shock treatment" CM can be a useful tool to get a configuration back on track. But, it is not an enduring solution to CM issues.

CM—a balance between rigor and reality: CM processes tend to swing back and forth like a pendulum in meticulousness, resources applied, and adherence to documented process. There are benefits from a highly disciplined CM process. However, an unintended consequence can be delays in processing baseline changes and ultimately in fielding modifications. When this happens, the phrase, "CM is slowing me down" may become common. Experience has shown that the most effective CM processes strike a balance between sufficient standards and control processes and mission needs of the program/system. Consider the following factors when determining your CM process: life-cycle stage, operational environment, acceptable risk, and mission requirements. The volume of data maintained is not necessarily a good metric for measuring the effectiveness of a CM process. Less can be better, especially if the quality of data meets your "good enough" threshold.

Get the user invested in the CM process: The user should be your most critical stakeholder and strongest advocate in quality and disciplined CM. Their early and active involvement throughout the CM process is a must. Understandably, users tend to favor speed of execution, and they commonly consider CM as a burden to be managed by engineers. When operational users participate as members on modification teams, engineering reviews, and configuration control boards, they become vested, resulting in a CM process owned by both the managing program office and the user. Users can feel "stonewalled" when they ask for a change that never appears to happen, if the process appears chaotic or inefficient, or is just not understood. An operational user properly invested in CM is the best advocate or spokesperson to the rest of the user community for a disciplined CM process.

Two compelling examples come from an existing government program. In both cases, the user representatives proved to be critical to the development and implementation of two major CM process changes for the system. The first was the establishment of an urgent and compelling need (UCN) process to facilitate rapid fielding of mission critical modifications. Working together, the systems engineers and the operational users negotiated and designed a minimum acceptable CM (documentation and approval) process that met the "good enough" standards for program management, engineering, and the users. This process has stood the test of time, and has proven itself over several years of direct support to field operations. The second example involved the transition to a bulk release modification process for fielding modifications. The bulk release method significantly reduced the number of disruptions and logistical burdens at each site by combining non-time-critical major and minor modifications into one integrated baseline release, with the result that the overall time spent at the sites for modifications was reduced.

Complexity of enterprise CM: Asserting CM control over a small system with clearly defined interfaces can be fairly straightforward. In general, applying good CM practices to that case is well understood. But as programs transition from being primarily "stovepipe" configurations to systems that are part of an enterprise, the scope of their CM processes change as well. Enterprise systems have more stakeholders to involve in the process, and they also tend to have more moving parts, making CM particularly challenging. Teams responsible for coordinating modifications or new developments must now also manage configurations that are part of and have implications for enterprise capabilities like networking, information assurance, and data management. This requires new perspectives on what needs to be managed at what level (system or enterprise) and with what stakeholder involvement. Enterprise CM activities need to be appropriately resourced to meet the greater needs of an enterprise. For more information on enterprise systems, refer to the Enterprise Engineering section within this guide.

Sustaining and maintaining organizations are critical CM stakeholders: Make sure the sustainment or maintenance organization is on board and an equal partner in the CM process. Their unique vantage point helps ensure the sustainability of the fielded baseline by identifying vanishing vender items, provisioning, and a host of other logistical considerations.

References & Resources

  1. Acquisition Community Connection, Defense Acquisition Guidebook,, accessed January 25, 2010.

Additional References & Resources

Air Force Instruction 63-131, November 6, 2009, Modification Program Management.

Leffingwell, D. and D. Widrig, 2003, "Managing Change," Managing Software Requirements: A Use Case Approach, Addison-Wesley Professional, Chapter 28.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team