Is change control the same as change management?

Not in this sense. Change control is the project process for altering an agreed baseline. Change management, in most organisations, means helping people adopt a new way of working, and in IT service management it means controlling changes to live systems. The same words, three disciplines.

Who sits on a change board?

The people whose money, time or acceptance the change would consume: typically the sponsor, the lead user and the lead supplier, or their delegates. Small enough to convene quickly, senior enough that its decisions hold.

What should a manager do with a change from a senior stakeholder?

Record it, assess it, and take the assessment to the person with authority to decide, even if the requester outranks everyone in the room. The process protects the manager as much as the project: a decision taken by the sponsor is defensible, and one taken in a corridor is not.

Change Control

Also: change management (projects), change request, change board, configuration management, tolerance

Change control is the process by which a proposed change to a project's agreed baseline is recorded, assessed for its effect on scope, schedule, cost and risk, and then approved, rejected or deferred by a person holding the authority to do so.

Our take. Change control exists to make saying yes expensive enough that people mean it, and it fails in both directions: too heavy and the team routes around it, too light and the baseline dissolves. The right weight is the one where a small change costs a small amount of process and a large one costs a meeting, and where nothing at all is absorbed silently.

Once scope, schedule and cost are baselined, every request to alter them is a change, and the process is the same each time. Record the request, so it exists. Assess it: what does it do to the scope, to the end date, to the budget, to the risks, and what happens if it is refused. Present the assessment to whoever has the authority to decide at that scale, which for a small change is the project manager and for a large one is the sponsor or a change board. Record the decision and, if approved, update the baseline so that the project is now measured against the new one. The point is not to prevent change. It is to make every change a decision that somebody visible took, with the consequences in front of them.

Tolerance keeps the process light

PRINCE2's answer to the weight problem is tolerance: the manager may vary time, cost and scope within stated limits without asking anyone, and must escalate the moment a change would breach them. A two-day slip inside a two-week tolerance is the manager's business; a three-week slip is the board's. PMI's body of knowledge reaches the same place through delegated authority and thresholds. Either way, most changes never reach a board, and the ones that do are the ones that should.

Record everything, including changes refused and changes absorbed within tolerance, so that the history of the baseline is complete.
Assess before deciding, and assess the refusal too; declining a change has consequences that are easy to forget.
Match the authority to the size: the manager decides small, the sponsor decides medium, the board decides large, and the thresholds are written down.
Update the baseline on approval, so that the schedule the team is measured against is the one they agreed to deliver.
Watch for the change that arrives as a clarification. Most scope creep enters as a helpful interpretation of something already in scope; the process exists to ask whether it is.

The professional certifications examine change control as a process and as a judgement: what a manager should do with a request from a senior stakeholder outside the process, which is to put it into the process rather than act on it or refuse it personally. Agile methods replace the board with the backlog: any change is a backlog item, the product owner orders it, and the next iteration's planning decides whether it is done, which is change control run continuously by one accountable person rather than periodically by a committee.

In practice

A marketing director asks the project manager, in a corridor, to add a customer survey to a website relaunch, and adds that it is a small thing. The manager, following the process, records the request and assesses it that afternoon: a new form, a data-protection review, a two-week delay to a launch already promised to the sales team, and a risk that the review finds a problem. The assessment goes to the sponsor with the manager's recommendation to defer it to a second release. The sponsor agrees and tells the marketing director personally. The team never heard about the survey; the director's request was taken seriously and answered in a day; and the launch date held. Without the process the manager would have said yes in the corridor and explained the delay later.

Often confused with

Scope Creep: Scope creep is what happens without change control: additions that were never assessed or decided accumulate until the project is late for reasons nobody agreed to. Change control is the process that turns each potential creep into a recorded decision.
Risk Register: The register manages what might happen; change control manages proposals to alter the plan. A materialised risk often leads to a change request, and the two processes hand off to each other without being the same.
Product Backlog: In agile delivery the backlog is change control: every request becomes an item, the product owner orders it, and iteration planning decides. Continuous and single-owner rather than periodic and committee, and doing the same job.

Key takeaways

→Every change to the baseline is recorded, assessed, decided by someone with the authority, and reflected in a new baseline.
→Tolerance and thresholds keep small changes light and send large ones up.
→The senior request from the corridor goes into the process, not around it.

Certifications that test this

Vendor exams whose syllabus covers this concept — facts, cost and a preparation path on each page.

More courses from these shelves

A rotating selection from the course directory, drawn from the subcategories where this concept is taught rather than picked for it. Details, price and the provider link are on the course page.

FAQ

Is change control the same as change management?: Not in this sense. Change control is the project process for altering an agreed baseline. Change management, in most organisations, means helping people adopt a new way of working, and in IT service management it means controlling changes to live systems. The same words, three disciplines.
Who sits on a change board?: The people whose money, time or acceptance the change would consume: typically the sponsor, the lead user and the lead supplier, or their delegates. Small enough to convene quickly, senior enough that its decisions hold.
What should a manager do with a change from a senior stakeholder?: Record it, assess it, and take the assessment to the person with authority to decide, even if the requester outranks everyone in the room. The process protects the manager as much as the project: a decision taken by the sponsor is defensible, and one taken in a corridor is not.

Sources

The primary text this definition rests on. Read it before you trust ours.

PeopleCert, Managing Successful Projects with PRINCE2, 7th Edition (2023)
Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), Seventh Edition (2021)

Last reviewed 13 September 2026 · Getting Digital

Change Control

In practice

Often confused with

Key takeaways

Certifications that test this

More courses from these shelves

Agile & Scrum: Interview Preparation with Questions, Answers

Hotel Management Strategic Operations

Healthcare Project Leadership 101

Operations Management: Inventory Management

The Complete Agile & Scrum Project Management Course

Strategic planning using ancient wisdom and visual mapping

FAQ

Sources