Many professionals struggle to understand the difference between configuration management and change management. These two processes sound similar but serve different purposes in project management.
Configuration management focuses on tracking and controlling product features and versions. In contrast, change management handles modifications to project baselines, such as scope, cost, and schedule. Knowing when and how to apply each process helps teams deliver accurate, high-quality results without confusion or delays.
In this blog post, I will break down both concepts in simple terms, highlight key differences, and share real-world examples to clarify them. Whether you’re preparing for the PMP exam or managing complex projects, this explanation will strengthen your understanding and improve how you handle project changes.
Let us get started.
What is Change Management?
Change management, as defined in the PMBOK Guide 7th edition, centers on identifying, documenting, and controlling modifications to project baselines, plans, and processes. It’s the systematic approach to handling disruptions that could derail objectives like scope, schedule, or budget.
For example, mid-project, you find the steel supplier has left, which delays your schedule by one week. You raise a change request for a one-week extension. You analyze the impact on cost and risk. If approved, you update the schedule baseline. Only approved changes get implemented, with updates to relevant documents and stakeholder notifications.
Effective change management minimizes risks and keeps projects aligned. According to a 2025 report by Changing Point, organizations with strong change practices see only 34% of initiatives fail outright, compared to 50% in less mature setups. Frontline-led changes, per McKinsey research, have boosted success rates to 71%, highlighting the value of inclusive decision-making.
Core Activities in Change Management
To execute it smoothly, focus on these steps:
- Identify Changes: Spot potential shifts early—such as vendor delays—through regular monitoring.
- Document and Analyze: Log details in a change request form and evaluate ripple effects on the triple constraints.
- Review and Approve: Present to a Change Control Board (CCB) or PMO for go/no-go decisions.
- Implement and Communicate: Roll out updates, revise baselines, and loop in stakeholders to maintain transparency.
Common Triggers for Change Requests
Changes often arise from:
- Schedule Pressures: Developing recovery plans for delays, such as reallocating tasks.
- Budget Overruns: Recalculating costs and seeking approvals for additional funding.
- Scope Creep: Addressing unauthorized additions that threaten deliverables.
By embedding these into your project management plan, you foster resilience. A PMI study notes that mature change processes help 94% of teams meet objectives, reducing failed changes by 78%.
Exam Tip: Remember: “change management = process, baseline, approvals.”
What is Configuration Management?
Configuration management shifts focus to the “what” of your project: the specifications of deliverables, components, and processes. Per PMBOK 7th edition, it’s about maintaining the integrity of configurable items—think software versions, hardware setups, or product blueprints—through versioning and audits.
For example, on a school-building project, the client now wants 15 classrooms instead of 10. That alters the deliverable’s configuration, not merely the schedule. You must manage the version, document features, and maintain control.
This process is vital in IT and manufacturing, where precision matters. The global configuration management market, valued at $2.96 billion in 2024, is projected to reach $9.22 billion by 2032, driven by demands for efficiency and security in complex environments. Gartner emphasizes that robust practices can cut operational costs by up to 30% through better asset control.
Core Activities in Configuration Management
Streamline your efforts with these essentials:
- Identify Configurable Items: Catalog everything from code modules to facility layouts.
- Record and Report: Maintain a configuration log for baselines and change histories.
- Verify and Audit: Conduct regular reviews to ensure compliance with specs and flag deviations.
Common Triggers for Configuration Changes
These often stem from external forces:
- Market Demands: Adding features to stay competitive, like AI integrations in apps.
- Obsolescence Risks: Updating outdated elements to extend product life.
- Client Feedback: Incorporating extras, balanced against budget and timeline cuts.
- Efficiency Tweaks: Removing non-essential components to accelerate delivery.
Integrating this early prevents downstream issues and ensures your final product meets stakeholder expectations.
Exam Tip: Think: “configuration management = version control, deliverable items, auditing.”
Key Differences: Change vs Configuration Management
The following table shows the key differences between change management and configuration management:
| Parameter | Change Management | Configuration Management |
| Focus | Project baselines (time, cost, scope, quality) | Delivery items (products, services, components) |
| Trigger | A change request that impacts a baseline | A modification of a configuration item’s features or version |
| Approval Body | CCB, PMO, stakeholders | Configuration control board, or the same CCB with an additional version log |
| Example | Delay in the project schedule by one week | The client asks to increase the building from 10 to 15 rooms |
| Goal | Ensure the project meets objectives despite changes | Ensure deliverables remain consistent with the specification |
Bottom Line: Change management controls the change process. Configuration management controls changes to products and deliverables. They are complementary, not always hierarchical. Some experts argue that one is not a strict subset of the other.
Who Can Raise and Approve Change or Configuration Requests?
Any project team member can raise a change request, but it must be approved by the authority defined in the change or configuration management plan. This authority could be the Change Control Board (CCB), the Project Management Office (PMO), or another stakeholder listed in the project management plan.
If the client isn’t part of the approval process, their consent is still required before implementing any change.
A configuration request usually comes from the client since it involves modifying the product or its features. The project manager reviews the request and forwards it to the authorized body for approval. Client approval is also required because such changes often entail additional costs.
Why Both Matter
Construction Industry
A contractor working on a hospital needs to revert to an earlier design because of regulatory changes (configuration change). Meanwhile, the schedule is extended by 2 months due to a supply-chain issue (change request). If either process fails, cost overruns or quality failures follow.
IT/Software Industry
A software company shifts from version 1.0 to version 1.1 (configuration management). At the same time, a major regulatory update forces infrastructure upgrades across their data centre (change management). The combined disciplines maintain stability and compliance.
Manufacturing Industry
In a consumer-electronics firm, firmware update campaigns, hardware revisions, and manufacturing line changes all rely on proper configuration management. At the same time, if production volumes surge or logistics channels change, change management kicks in.
A 2025 study of software companies identified eight strategies to address configuration differences between development and production environments, including automation, virtualization, and detailed planning.
Real-World Examples of Configuration and Change Management
Consider a school construction project with 10 classrooms as the baseline.
Scenario 1: Change Management at Play
Mid-build, your steel contractor quits, forcing a one-week hiring delay. You file a change request via the CCB. After impact analysis—no significant cost hikes, just a schedule slip—it’s approved. You revise the baseline and notify funders. Result? Minimal disruption, keeping the project viable.
Scenario 2: Configuration Management in Motion
The client now demands 15 classrooms for growing enrollment. This alters the product config: blueprints, materials, and costs shift. Configuration logs track the new specs, with audits ensuring structural integrity. Client approval follows, triggering a secondary change request for budget/schedule tweaks.
These examples show how configuration updates can lead to project changes, but using separate tools keeps things organized. In IT, the same idea applies—a software configuration update, such as fixing a bug, may still require change approval if it affects the deployment schedule.
Best-Practice Framework for Implementation
Here’s a simple framework to integrate both processes in your project:
- Create a Configuration Management Plan as part of your project management plan. Define CIs, version naming conventions, and auditing schedule.
- Define your Change Management Plan (often part of your Integration Management), with request forms, impact assessment templates, and CCB membership.
- On every change request, ask two questions:
- Does it affect a project baseline?
- Does it affect a configuration item or deliverable?
- Based on the answers, you route the request through one or both processes.
- Maintain a Configuration Status Accounting log: current version of each CI, date, status, and change history.
- Conduct Configuration Audits at major milestones to verify alignment of deliverables with specs.
- Use metrics. Number of change requests, number of configuration deviations, downtime reduction, and cost savings.
- Example metric: “Configuration deviations decreased by 35% after the first year of the audit process.”
- Communicate clearly with stakeholders: a common mistake is delaying audits or missing version controls, which can lead to rework or legal issues.
Tip for PMP/CAPM Test-Takers: Memorize the five steps of configuration management (Plan -> Identify -> Control -> Status Accounting -> Audit) and the steps of change management (Identify -> Document -> Review/Approve -> Implement -> Communicate).
FAQs
Q1. Can a configuration change trigger a change request?
Yes. If the deliverable features change (configuration), the baseline (schedule, cost) may also be impacted, so a change request is needed.
Q2. Who approves configuration changes?
Often, the same Change Control Board or a separate Configuration Control Board; the plan should define roles.
Q3. Does change management apply if no baseline exists?
No. Formal change control applies after baselines are approved. Without a baseline, you manage updates rather than formal changes.
Q4. Are these processes agile-friendly?
Yes. Even in agile, you track versioned deliverables (configuration) and manage backlog items/impact (change). The same principles apply, though leaner.
Q5. Which PMI standard covers these?
The PMBOK® Guide – Seventh Edition covers Configuration Management in the context of system thinking and change management under Integration Management.
Summary
Understanding the difference between configuration management and change management helps project teams work efficiently and avoid confusion. Configuration management controls product features and versions, while change management handles updates to project baselines like cost, time, and scope. Both processes support quality, consistency, and better decision-making.
When applied together, they help projects stay on track, reduce risks, and deliver the right outcomes.
Further Reading:
- What is Configuration Management in Project Management?
- What is Project Change Management?
- What is the Change Control Board in Project Management?
- What is the ADKAR Model in Change Management?
- Change Management Vs Release Management
- Change Management Vs Project Management
Change management and configuration management are the most important concepts on the PMP exam, and you will see many questions about them!
I am Mohammad Fahad Usmani, B.E. PMP, PMI-RMP. I have been blogging on project management topics since 2011. To date, thousands of professionals have passed the PMP exam using my resources.
Hello Fahad,
Thank you for your well thought out article.
I like your definitions, and seems correct; and certainly one way to interpret the PMBOK. But, part of the problem (and why you have written this article and folks like me and rest of your readers look for clarification), is that the PMBOK very much makes it all a fuzzy deal. Your definition is good and makes perfect sense—it’s what I’d also espoused to: Configuration has to do with Product; Change has to do with Project docs, baselines, processes, etc. But there are contradictions.
And, as I’ve tried to make sense of it in my own head in studying PMBOK (as you know PMI has “THEIR definition” of things, not always the same as “Organization/Company lambda’s”), there are some contradictions in PMBOK, and thus in your own definitions above—which are indeed direct out of PMBOK. You say that “Change Control” is about “Project stuff” — Project Documents, Baselines and Processes ; and “Configuration Control” as Product/Scope related (“Product Stuff”). Yet, you then correctly quote PMBOK that ““Configuration Control focuses on the specifications of both the deliverables and the processes” (i.e., note PROCESSES).
Further on, you point again to the contradiction when you quote PMBOK: “Configuration control is focused on the specification of both the deliverables and the processes (i.e., note PROCESS!), while change control is focused on identifying, documenting, and approving or rejecting changes to the project documents, deliverables, or baselines” (note DELIVERABLES!). Thus not in line with your stated interpretation / defintition.
Another interpretation (that I’ve enountered) is that Change Control is the process of changing Project “Artifacts” (Project document, plans, process, deliverables, baselines – in short, everything that is under control): the written change requests, the Change Control Board, voting, approval / rejections, etc. And that Configuration control is the versioning, identification of “current version”, archiving of old versions, etc. of all “Project Artifacts” (Artifacts covering both “Project Stuff” like docs & processes and “Product Stuff”, like deliverables). This is the one espoused by Rita Mulcahey (her PM book). This interpretation also has problems and contradictions with some of the same definitions (and others) of Change Control (and Change Mgmt) and Configuration Control (and Config Mgmt) that is found in PMBOK.
All this to say: PMBOK was written by a lot of folks and then “Controlled” over its various authors and chapters to ensure overall integrity. But there remain unclarities and contradictions – and I believe this is one. They seem to clear these up with new versions of PMBOK, but others appear. All this said, your definition is a good one – and one that I have always thought was true. Now I am beginning to wonder. Having read around and now studying for PMBOK — and thus trying to understand “How does PMBOK define this” – because as stated earlier PMBOK definition is not always same one’s “real world” definition. That’s okay, it’s just not okay with they are not clear and there are contradictions in their method. Thanks. Great article. If you can or in position to dialogue with them– tell PMI to clarify their defintiions! Look forward to your feedback.
Change Management” is the first category. Here you manage changes related to project management plans, {processes}, and baselines.
According to the PMBOK Guide 6th edition, “Configuration Control focuses on the specifications of both the deliverables and the {processes}.”
I don’t understand how the 2 terms dealing with{ process }
kindly clarify it.
Hello Anas,
Change management is a subset of configuration management.
Does the Configuration Management, lead to raise a Change request in Project Management ?
Below are same 2 examples used in here, to help you understand, what I am trying to convey.
Example 1
During the middle of the project, my contractor for steel work walks off the job and I have to find a replacement. I found an alternative, but the new contractor will not start working on the project for a week.
This will delay the project. Therefore, I will raise a change request for a one-week extension of the schedule through the change management system.
Example 2
Now, I am constructing a school building and the client requests that I have to increase the number of rooms from ten to fifteen.
This is a request to change the product scope as the client has altered the product configuration.
I will handle this change under the configuration management system because here the specifications of the product have changed. Earlier the school building had ten rooms, and now it will have fifteen rooms.
However, building additional 5 rooms will take more time than building 10 rooms, planned earlier. Hence, my schedule will also change as a result effecting my baseline, and so I have to raise a change request.
Please let me know if my understanding is correct !
In both cases, you will raise a change request.
Dear Fahad,
Can you please provide a reference to this from PMI..?
If you have access to the PMBOK Guide 5th edition, you can refer to page 532.
This article is very good. It helps me to get clear about Configuration management and Change Request.
So, I would like to confirm about our project.
My project is to build the Window with blue color. But in executing, The window was painted with blue color. After that the stakeholder changed the color to yellow.
So, this should be managed by Change management or Configuration Management.
Because it impacts to schedule, cost and product specification.
Please explain.
Thank You so much.
This is the change in the specification, so configuration management.
Hello Fahad,
Please Read this sections from the PMBOK® Guide Sixth Edition, and then correct your answer and please also try to understand it well. What you are saying about configuration management and change management isn’t True at all.
“Configuration management plan:
Describes how the information about the items of the project (and which items) will be recorded and updated so that the product, service, or result of the project remains consistent and/or operative.
“Change control should be applied once the first version of a deliverable has been completed. The control of the multiple versions or editions of a deliverable (e.g., documents, software, and building blocks) is supported by configuration management tools and procedures.”
“Before the baselines are established, changes are not required to be formally controlled by the Perform Integrated Change Control process. Once the project is baselined, change requests go through this process. As a general rule, each project’s configuration management plan should define which project artifacts need to be placed under configuration control. Any change in a configuration element should be formally controlled and will require a change request.”
“Configuration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes;”
Thank you.
Hello Shady, though more technical details can be added to this blog post, the points discussed here are valid.
Hi Fahad, i also have same question above that why change management is a subset of configuration management instead another way around. Is there any reasoning behind?
Also have another question which made me confuse,
Ques: project manager doing quality check for steel bolts of 20 cm. The acceptable control limits are 19.955 cm and 20.045 cm. The measurements made at the end of the process yielded the following results : 20.033 cm, 19.982 cm, 19,995 cm, 20.006 cm, 19.970 cm, 19.968 cm, 19.963 cm, 19.958 cm, 19.962 cm, 19.979 cm and 19.959 cm. What should be done?
I always think if control limits are good why we need to frther investigate the process? Is it not control limits are typically similar like tolerances (except prior is defined by PM and later by customer.)
Thanks
Sumit
Configuration management has larger scope as compared to change management.
Control limits are set by project manager to control the process and if anything goes outside of it, he will check if everything is right though the project is within acceptable range.
Thanks Fahad for your explanation,but one question, according to your explanation, configuration is mainly for product and change is mainly focus on baseline and project plans, so i see that at many points they will be meet together, like for scenario 2 when u need to change the number of classrooms from 10 to 20 now yes that change in the product, but to meet that product you will need to change the plans as well, so in that scenario we will pass by both configuration and change, correct me if im wrong
Thanks again
In short, change management is a subset of configuration management.
Any changes in the project management plans and all its subsidiary plans and baselines requires to be updated through change control process and have it approved. Then do all project documents would need to go through the change control process before updates can be made? e.g. stake holder register or risk register or requirement documents. Can these by updated without going through a formal change control process and approval? Can the PM make the changes without some else’s approval?
These are the project document and supposed to be updated all the time throughout the project lifecycle. They do not require to go through this process.
Then are all project documents treated the same way? There is a list of documents in the PMBOK guide page 78. Besides the obvious ones like performance data and issues/change log/forecast etc, all others can be updated without a formal change control approval?
As per my understanding – yes.
I find a similar article on linkedin, and it is matching word by word. You can have a look at it:
https://www.linkedin.com/pulse/configuration-management-system-vs-change-bsc-pmp-pmi-rmp-tot-
The guy has copied my content and posted there. I have filed a copyright infringement notice with LinkedIn.
Thanks Amit for letting me know.
Dear Fahad, Thanks for your great explanation, But I’m still little confused about the configuration management system.
Let’s take your instance ( Increasing the number of classrooms from 10 to 15), That’s great.
You said that any chang to the project processes or baseline is considered as a change management system, So in the previous instance ,when we decide to increase from 10 to 15 , I think this change affects directly the scope of the project, which is in turn one of the project baseline.
So, in my opinion, this will be under the change management system.
Waiting for more information,and thanks in advance.
Change management is a subset of configuration management.
The change management plant defines the process for managing changes on the project.
The PMBOK Guide fifth edition, page: 138
Are Configuration Management and Change Management differing from Configuration control and change control?
In the PMBOX Guide fifth ed. Says: Configuration control is focused on the specification of both the deliverables and the process while you mentioned In the Configuration Management System, changes related to product specification are managed.
Thank you.
Please refer page 532, the PMBOK Guide 5th edition.
Dear Fahad,
Your work is impressive. But could you clarify Saad’s doubt? I share it too.
Documenting changes in scope/configuration of the product (deliverable) is configuration management
Documenting change in processes/cost baseline/schedule baseline is change management.
Is this understanding correct? If yes, pg. 96 of PMBOK 5th ed. says “Configuration control is focused on the specification of both the deliverables and the process “. How come configuration control is focused on specification of the process? This is description of change control right?
I feel there is some discrepancy between the definition of configuration management mentioned in these two places.
Anyway, I’m going to write a mail to PMI, let’s us see their reply.
Yes we should. Kindly update us.
Tauseef, I agree with your assessment: “Change management may act alone, [but] the configuration management has to take change management along”.
Also based on how PMBOK 5.6.1.1 – Control Scope describes Configuration Management Plan, it seems the plan itself defines what specifically *is* configurable (and therefore, in which cases the configuration control is applicable).
I only happened across this blog because one of my PMP Certification Exam Prep study questions asserted that Configuration Management “does NOT take the place of a Change Management System, but rather works with it”.
Hi,
Please can you tell me what is different between :
Change management plan & change management system
Also configuration management plan & configuration management system
Thank you very much
Imad
Basically you are asking the difference between plan and system.
Plan is something documented which guides you in your act. System is something that helps you implementing your plan.
Hope it helps.
Hi Fahad
I read your post about change management and configuration management . I still have some concerned about all this term.
Configuration management and change management system
Change management plan and change control system
Can someone gives me more explanation and difference between these four terms with example it would be nice
Thanks in advance for you contribution to my understanding
best regard
Hi Fahad,
Can we say Configuration management is scope change and change management is shcedule change?
Thanks
Ramesh
Configuration management is scope change – Yes, we can say this.
And Change Management includes the change in schedule and cost baselines.
i dont think so because changing scope will add a new scope and new related spécification. but configuration is concerned by changing spécifications to an existing scope. so i think changing scope is concerned with change management system and not configuration management system
Yes, you are right, if there is change in product scope then we can say it will be managed through the configuration change management system.
As Nedhir said, if there is scope change, it should be considered as change management. Like the school example, if the color of the classroom is changed from green to yellow, then this should configuration change