Configuration Management & Change Management System: Differences

By Vinai Prakash

I get a number of questions about the differences between a Configuration Management System and a Change Management System. This question arises because most project managers have heard about a Change Management System, and Change Control, but most of them haven’t seen, heard or used a Configuration Management System.

So I thought to clarify the difference between Change Management & Configuration Management in this article, and help PMP aspirants get correct answers to PMP quesitons from this area.

In the second world war, the Germans lost to Britishers & Americans in North Africa. Why?

Because of their failure to do Configuration Management.

When a tank used in the war broke down and needed a replacement part, it will be ordered. Most of the replacement parts would arrive on time, but would not fit nicely, causing the tank to be put out of service. Over the next few months, the supply of the German tanks reduced considerably, and the Americans and Britishers triumphed.

Configuration Management is the solution to solve this wrong-replacement-part problem. It tracks the different revisions to the design, blueprints, technical specifications, and can tell you which one is the lastest revision, so that the right part can be identified.

Configuration Management is primarily a Version Control System for the Product of the Project.

According to the PMBOK Guide, Fifth Edition:

Configuration Control focuses on the specifications of of both the deliverables and the processes.

Change Control is focused on identifying, documenting and controlling changes to the project and the project baselines.

A Change Management Plan documents how changes will be monitored and controlled. The plan defines the process for managing change on the project.

A Configuration Management plan documents how configuration management will be performed. It defines those items that are configurable, those that require formal change control, and the process for controlling changes to such items.

Basically, a Change Management Plan is a generic plan that guides the Project Manager in terms of making any kind of change on the project, specially the ones that can impact the baselines (scope, time, cost baselines), whereas, a Configuration Management  Plan only guides you in making changes which are specific to the Product Configuration.

Do you understand what does the term “Configuration” mean?

A configuration is the identified and documented functional and physical characteristics of a product, service, result or the component. This really means the “actual specifications of the product” of the project.

A Clear Difference:

First of all, you must know the difference between a project and an operation.

Let’s say that we are undertaking a project to create the product, service or result.

All the work that is done as part of this project is considered the “process”, which is used to create the “product” of the  project.

The change management plan oversees  how any change to the “process” should be done.

The configuration management oversees how any change to the “product” should be done.

An example of Configuration Management:

Let’s say you are the Project Manager of a large, multi location application installation & implementation Project. It requires you to send your team to upgrade the software, hardware, and get the system up and running in each of the 562 locations country wide, in the next 6 months. Each location has their own servers, and you need to upgrade them to standard version of hardware, software, utitilies and application, which are all compatible with each other.

You can have a great Change Management System in place, which will track how changes to the user’s specifications in terms of scope, time, cost, quality etc. are to be managed. But your team will have a tough time if you did not setup a proper Configuration Management System, which will track the different versions of the Hardware, software, compatibility between the versions that are running on each server, and enable the team to know what is compatible, not compatible, and what has been upgraded or not upgraded.

Remember, this is a large project, and your team is going to be spread out – no one person will be able to remember the different versions of each server specifications, and their upgrade state. With a proper configuration system, all changes to the servers will be tracked, and you can easily find out what version is running where, on which server, it’s compatibility etc. and make life and project management easier, less stressful for you.

The Key Elements of Configuration Management are:

  1. Version Control: The ablity to check the work into a common repository, retrieve it anytime to see any changes done by anyone, and maintain full version history.
  2. Baseline and release information: When was the last version released, what did it contain, and having a baseline version to deploy at any time.
  3. Audits & Review: Audit of the process to ensure that people are actually following the configuration management and versioning system properly, correctly, consistently.
  4. Documented Process: An agreed upon process by all team members to ensure compliance in actual implementation. No point having a great system that no one uses or uses it at random.
  5. Build, Integrate and Deploy Scripts: Common, standard scripts that automate the work of building, testing, integrating, deploying, and removing manual errors from the process. Standardization of the processes and its implementation is the key here.

Configuration management is an generic, umbrella term for all the activities that reduce the risk of integration failure due to component changes on the project.

This can mean any component – from the version of Unix running on a server to a programmer building with an out-of-date specification to using the wrong blueprints to make a part on the factory floor.

Change management is a generic procedure to manage all kinds of changes on the project. You should have a Change Management Plan to manage how changes will be handled – how will the changes be evaluated in terms of the impact on time, cost, scope etc.,  how will change requests be created, who approves them, where will they be documented, and how will changes be managed through out the life cycle of the project. It goes beyond the product specifications.

Hope you understand Configuration Management and Change Management better now… Let me know your comments, or discuss this on the PMChamp PMP Forum.

Cheers,
Vinai Prakash, PMP, MBA, ITIL

PS: PMP Exam Preparation workshop is starting on this Monday. View Videos each day where I explain important concepts about the PMP exam, and help you to prepare for the PMP exam. One new lesson every day, followed by a quick review questions and answers. Plus, access to a Member’s only Forum, to discuss any questions you have regarding the PMP Exam. Learn more about the PMChamp PMP Exam Prep Online Workshop. Hope to see you in the class soon!

Want More PMP Tips & Tricks?



Join & Get PMP Tips!

We don't spam. Unsubscribe anytime. Powered by ConvertKit
  • Andrew Kohlee

    thanks for articulating the difference between change/configuration management/plan

    • Cathy Jones

      The differences between configuration management and change management are communicated in a excellent manner BRAVO !

      • Thank you very much Cathy for the appreciation. Glad you liked it. 🙂
        Cheers – Vinai

  • Sam

    Thank you very much. Very good explanation.

  • AKEEM OWOADE

    Thanks alot.This is more explanatory than what i have been assessing online so far

  • Shreyashi Ghosh

    Very helpful. Thank You!

    • Glad you liked it Shreyashi. Hope it will help you in your PMP exam preparations – Vinai

  • Sang Le

    Great post! Thank you!

    • Thanks for appreciating this article. Hope it will help you in achieving your PMP certification. All The Best – Vinai

  • Momo Ramirez

    to be clear, one doesn’t exclude the other, right? i mean you need to do both if you want to add an extra feature to the product. first I will need to perform integrated change control and once the change is approved I will need to change the configuration, updating the product to the latest version, isn’t it?

    • Yes, you are correct Momo. You have to do both if you need additional scope to be added, after approvals.
      Cheers – Vinai