September, 2018

Questions regarding the differences between Configuration Management (CM) and Change Management (also CM) arise so often that we decided to address it in a CMsights post. It is not uncommon that a new A&D program manager or engineering lead may think that configuration management and change management are synonyms. If you have one you must be doing the other. This is far from the truth.

Many examples exist where change management was confused for configuration management. This includes recent highly publicized issues with automotive ignition switches as well as over 1,000 data breaches that took place in 2017. Implementing a change management process rather than a configuration management solution costs billions of dollars each year.

A well-known example of a configuration management failure occurred in the 2010 Deepwater Horizon offshore drilling rig fire. Contracting partners thought they each had their respective change management responsibilities covered without taking into account the broader implications of systems level configuration management implementation. A lack of controlled engineering documentation and maintenance record distribution to equipment designers, owners, operators, and maintenance teams was identified as a critical contributing cause to the accident.

U.S. Coast Guard Photo of Deepwater Horizon from Wikimedia.

A final example that recently came to our attention regards an aerospace industry supplier. Discussions on the acquisition of a new intranet-based CM (as in Configuration Management) system took place at the highest levels of management over half a year. The implementing organization instead heard CM (as in Change Management) and rolled out a simple file version control solution thought to be the least expensive and fastest option to implement. Not only was the contractor lost in a foggy sea of acronyms, but the implementing organization failed to understand the engineering requirements.

How is Configuration Management different from Change Management? Configuration Management is a comprehensive approach that assures, maintains and verifies a product’s physical and functional attributes against its requirements and documented design and operation. Configuration management provides the provenance of every item contained in the product including what was tested, how it was tested, part substitutions and field modifications. Change management is just a single element of configuration management. You can’t have true configuration management without change management. But you can have excellent change management processes and tools and still have non-existent configuration management capacity and controls.

To understand why this is we need to delve a little deeper. Let’s start with the definitions:


EIA-649 Configuration Management Standard describes the following five foundational elements of configuration management. These are underpinned by data management.

  • Configuration Management Planning
  • Configuration Management Identification
  • Configuration Change Management and Change Control
  • Configuration Status Accounting
  • Configuration Verification and Audit

Configuration management is performed in concert with the product lifecycle. It begins with the Requests for Offer/Proposals (RFO/RFP) Pursuit, Program Award, Program Planning and Management, Product Development, Manufacturing and Test, Delivery and Support, and End of Life disposition.

The five configuration management elements assure that there is continuity between the product and the requirements that drive product design. Within a configuration management implementation strategy, change management is the process of ensuring changes to, variances from, and implement/incorporation of changes to an approved configuration baseline are properly identified, documented, evaluated, dispositioned (approved/disapproved) incorporated and verified.

Change management is transactional in nature. It is a point in time event that isn’t complete until the change is proposed, assessed by stakeholders, approved, released, and implemented in the units in production, delivered or sold. Automatic updates to your phone, laptop, desktop, or infotainment system software, applications and operating systems all fall into this category. As illustrated in an example from our last CMsights post, we have seen as many as 47 changes to a single circuit carrying assembly (aka printed wiring assembly) before the design was finalized in a system with over 30 different circuit carrying assemblies. Over a sample size of 32 developmental programs with a contract value greater than $36 million, 14,000 engineering changes is well within a one sigma normal distribution centered on zero changes. Some 2,300,000 changes existed on the largest program analyzed!

As detailed in earlier CMsights posts, the practice of effective configuration management for A&D contractors does not end when the engineering changes are all released to define the As-Designed configuration. The current As-Maintained configurations including changes for each serial number also needs to be tracked for each unit throughout its lifecycle. This is done via the digital threads in the configuration management software tools like those inherent in CMstat’s PDMPlus.

In this recent CMsights post we shared the questions a manager should ask of their organization to assess whether configuration management and change control are under management control. A fair question their team should be sure to ask of these same managers is do they understand that configuration management and change management are not the same. To show them an example illustrating that difference, request a demonstration of how PDMPlus’ change management module enables full-lifecycle configuration management by sending an email to