Configuration Control and Change Control - Similar yet Distinct

2 minute read    Updated:    Harwinder Singh

Configuration Control vs Change Control Configuration Control and Change Control are often used interchangeably. Both are related activities in the sense that they are concerned with “management of change”. Both are subsets of the overall Configuration Management System. However, they are distinct activities with different focus, and one is not a substitute for other. This article is a follow-up to Configuration Management System - A Quick Refresher. In this article, we’ll review Configuration Control and Change Control and learn how these two activities are similar, yet distinct.

Configuration Control

Configuration Control is the activity of managing the product (or project’s deliverables) and related documents, throughout the lifecycle of the product. An effective Configuration Control system ensures that:

  • The latest approved version of the product and its components are used at all times.
  • No change is made to the product baselines without authorization.
  • A clear audit trail of all proposed, approved or implemented changes exists.

Change Control

Change Control is the process of identifying, documenting, approving or rejecting, and controlling changes to the project baselines (including scope baselines, schedule baselines, cost baselines, etc.). In other words, it is used to control changes to all aspects of an approved project plan. An effective Change Control system ensures that:

  • Proposed changes are reviewed and their impact is analyzed, prior to approving or rejecting them.
  • All requests and changes are properly documented to provide a clear audit trail.

Difference between Configuration Control and Change Control

Configuration Control and Change Control are distinct in the following ways:

  1. Configuration Control addresses the management of the product (or project's deliverables), whereas Change Control addresses the management of the project.
  2. Configuration Control manages changes to the product baseline, whereas Change Control manages changes to the project baseline.
  3. Configuration Control is applied throughout the lifecycle of the product (concept -> design -> develop/manufacture -> service -> dispose), whereas Change Control is applied during the lifecycle of the project subsequent to establishing the project baselines.

I hope now you can better appreciate the distinction between Configuration Control and Change Control. Look forward to more articles in this series on Configuration Management.

3-part series on Configuration Management

Image credit: Flickr / spursfan_ace

You May Also Enjoy

Functional Organizational Structure

8 minute read

In a functional organization is the most common form of organization structure where staff members are grouped by specialty, such as engineering, manufacturi...

Pareto Charts and the 80/20 Rule

8 minute read

A Pareto Chart or Diagram, one of the Seven Basic Quality Tools, is a specific type of Histogram ordered by frequency of occurrence.

Leave a Comment

Please select the checkbox

18 Comments

Harwinder Singh Avatar

Hello Anonymous,

That's an interesting question and I think there may be others having the same doubt.

Schedule baseline is a component of the Project Management Plan. The project artifacts, including the Project Management Plan itself, are stored in a Configuration Management System. So, in a way you'll look into the Project Management Plan, but the Project Management Plan itself is physically stored in a Configuration Management System. Refer to the Configuration Management System - A Quick Refresher article for more details.

Let me know if it's still not clear enough. Thanks for bringing this up.

Best regards.

Missing Avatar

Configuration Management is consider as part of Enterprise Environmental Factors whereas Configuration Management Knowledge base is considered as a part of Organisational Process Assets . I m sure i m missing something

Harwinder Singh Avatar

Hello again Anon.,

It's a good point and something I had overlooked until now.

I understand your question better now. Configuration Management system used by the project need not be accessible at the corporate level. The following is what the PMBOK Guide, Fourth Edition says about the Configuration Management Knowledge Base:

"Configuration management knowledge base containing the versions and baselines of all official company standards, policies, procedures, and any project documents."

This is really referring to the Configuration Management system used at the corporate level, which is shared across the organization, and may be different from the one used at the project level.

To give you an example, you may be storing your project plans and documents in the Configuration Management System at the project level, but once the project is complete, as part of the the "Close Project" process, you would check them into the corporate level Configuration Management system so that it is accessible at the organization level. That's the reason why Configuration Management Knowledge Base is considered a part of the Organization Process Assets.

Hope that answers your question. Feel free to ask more questions.

Thanks.

Missing Avatar

Although the article is clear here is what my confusion is:
Since configuration management (control) is concerned with product baselines product manager and product management plan should be concerned with related activities, but instead configuration management plan is one of subsidiary plans for project management plan along with change management plan where both are responsible for managing changes. Even though change management plan manages changes to the project baselines – ultimately all these changes will affect final result which is project's deliverable (product) which is supposed to be responsibility of configuration management activities?
Fun, isn't it?

Reply to Alexey
Missing Avatar

Hi Harwinder,

What should be answer of the following question as per your understanding. I trust you most as PMP expert. Thanks

Question:
Your are managing a software project which is due for design document release next week. You are currently reviewing the document, when an influential stakeholder asks you to add a feature to the existing design. This stakeholder has earlier also tried to bother you with unreasonable demands at the last days of release. What is the best you can do in this situation?

Options:
A. Report his behavior to the senior manager suggesting them why he should no longer be associated to your project as a stakeholder
B. As this person is influential, you have no option but to listen to him and add the functionality
C. Determine the impact of this change on your schedule and their constraints before taking a decision
D. Ask him to raise a written change request form and then follow integrated change control

Reply to Anonymous
Missing Avatar

Hi Anon.,
I believe the correct answer is D. Adding feature to existing design would modify the configuration (characteristics)of the software (=product). As a key deliverable of the project, it's probably listed in the configuration management plan as an element to track. Therefore, any change on it should be initiated by a formal CR. I won't consider C in this case since the text says this stakeholder is known for bothering me with unreasonable request. I'll wait for him to introduce the CR before studying it.
Thank,
Pat

Harwinder Singh Avatar

Sorry for overlooking this question earlier. I would also go with D. C would be done as a part of the Integrated Change Control process.

Generally, when posting sample questions, please mention the source and do NOT post any questions which come under copyright protection (for example questions from PMP Exam Prep books or commercial exam simulators).

Missing Avatar

Thanks Pat and Harwinder for answering my question. Your explanation is very convincing now as I was juggling between C & D and not sure whether impact analysis is part of Integrated Change Control or should be done before that. Your answer says impact analysis should be done after CR is raised. Let me know if I misunderstood.
Harwinder, sorry for not mentioning source and will surely take care in future. As I remember, it is a question freely available on internet but as per my professional responsibility, I should be taking care :) Thank you once again. You rock!

Missing Avatar

Per me , answer should be 'c'. Just because, stakeholder is known for making unreasonable request in past, it doesn't indicate if he is unreasonable this time. We always need to assess impact of changes before requesting change. We don't even know if this this change is per scope/charter. Per Rita, the process flow is:

1. Prevent the root cause for changes
2. Identify change
3. Look at impact of the change
4. Create a change request

5. Perform Inetegrated Change Control
a. evaluate the impact - considering all the project constraints
b. create options - are created based on crashing, fast tracking, re-estimating..etc
c. get change request approved internally
d. get customer buy-in (if required)

6. Adjust the Proj Mgmt Plan, proj doc, baseline
7. Communicate change to stakeholders
8. Manage Project to the revised Proj mgmt Plan.

Missing Avatar

Just reading this and notice you say above, "Change control manages changes to the PROJECT baseline." But PMBOK 4 specifically says, "Change control is focused on . . . controlling changes to the project and the PRODUCT baselines." Has the PMBOK got it wrong?

Reply to Jim