Updated: May 11, 2020
During my discussions with our PM-ProLearners and ProGraduates, many wonder about the Configuration Management Plan and its purpose. How is it different than the Change Management Plan and why is it necessary? During a recent email conversation in our Multi-Spectrum Online Learning System (MSOLS), I explained it like this for an Army Armor Officer:
“For your Configuration Management Plan question, the easiest way to describe this portion of the PM Plan is to say that it describes and defines what will be subject to ‘configuration change’ on the project and how you will signify those changes. For instance, you may have items that will undergo several iterations before they are finally complete and helps greatly in change management processes. The Configuration Management Plan might signify how a configuration is identified, such as naming convention, version number, location, etc. One great example you may know from US Army armor history is the XM1, which became the M1, M1A1, M1A2, and ultimately the M1A2 SEP V4. The XM1 was the pre-production project, which after several configuration changes, became the final production model M1 that was used by the Army in the 1980s. Behind all the changes, there was a Configuration Management Plan (likely called something different then) that signified what could be changed, configured, or updated along with how those changes would be captured, approved, and ultimately added to the final production version.
It is very common in software so I will use that as my primary example for the remainder of the explanation. It starts with labeling or identifying the baseline, generally listed as version 1. In software, that normally looks like this: “188.8.131.52.” This versioning system (a sub-set of Configuration Management) allows the user to see that this is major release version 1. The subsequent numbering is used to identify updates, releases, or minor revisions. If the configuration of the baselined version changes drastically, it would then be identified as version 184.108.40.206 and continue updating the numbering based upon updates, releases, and minor revisions. There is a lot more nuance and can be specific to an organization or industry, and warrants its own post or article for a deeper explanation.
The Configuration Management Plan also identifies the way the different items will signify their configuration to the team and which items are actually ‘configurable.’ Not all items on every project will be considered configurable, but items that are usually identified in the plan are the PM Plan, major components or deliverables, project documents, and the final deliverable. All the other configurable items are signified in the Configuration Management Plan based on the complexity of the project or product, the project environment, and the needs of the team.
The other aspect of the Configuration Management Plan is that it discusses how changes will be ‘allowed’ to affect the configuration of an item or component and how those changes will be documented. Much like the Change Management Plan, good documentation practice allows for higher levels of acceptance by the customer. This is means for a change to a configurable item to be implemented in the production (final) version, the Change Control Board (or other change control tool), may have to review the results of all testing and/or undergo rigorous user acceptance testing. The Configuration Management Plan may also require certain items, or the entire final product is audited or inspected to ensure that all changes to configurable items have been implemented as agreed upon and/or documented.”
The Configuration Management Plan is vital to the success of the project because it allows the PM to track the many changes of the product, service, or result individually, but still as a part of the whole. It also allows the PM to let the team and other stakeholders know that a change has been made. This is just another reporting and communication tool for the PM on the project and provides an actionable plan for the team in terms of the overall project’s goals.