A change control process is the defined route a proposed change takes from the moment somebody asks for it to the moment the baseline is updated: the change is requested in writing, its impact on scope, cost, schedule, risk and benefits is assessed, an authority at the right level approves or rejects it, and if approved the plan and the budget are formally updated. The record of that journey is the change log.
Without one, changes still happen. They just happen invisibly, absorbed into the schedule by a team trying to be helpful, until the project is four months late and nobody can explain which decision caused it. Change control does not stop change and is not supposed to. It makes change a decision somebody made, at a level appropriate to its size, with the cost visible at the time.
Key takeaways
- Written request or it did not happen. A verbal "can you just add" is not a change, it is scope creep with a smile.
- Assess impact before the board meets, not in the room. Boards that estimate live make bad decisions quickly.
- Set delegated thresholds. If every change goes to the board, urgent things route around the process and the process dies.
- Rejecting is a valid outcome and so is deferring. A board that approves everything is a rubber stamp with a calendar invite.
- Approval is not the end. The baseline has to be updated or the project is now measured against a plan that no longer exists.
- The change log is the audit trail. It answers "why did this cost double" long after everyone involved has moved on.
- A CCB decides. A CAB advises. Do not merge them and then wonder who has authority.
What is a change control process?
Change control is the formal procedure for reviewing, approving or rejecting changes to an agreed baseline, and for updating that baseline when a change is approved. In project management the baseline is normally scope, schedule and cost. In IT service management it is the production environment. In regulated manufacturing it is the validated process. The mechanics are the same in all three: nothing changes without an assessed, recorded decision.
The word "control" misleads people. The purpose is not to make change difficult, and a process designed to discourage requests will simply be bypassed. The purpose is to make the cost of a change visible at the moment somebody asks for it, so the person asking can decide whether they still want it. Half of all change requests are withdrawn once the requester sees the schedule impact, and that alone justifies the paperwork.
It also matters because unmanaged change is how portfolios quietly lose capacity. A project absorbing three unapproved additions is a project consuming resource that the portfolio believes is available for something else, which is the mechanism behind most resource contention that appears to come from nowhere.
The five steps of the change control process
Different frameworks label these differently, but every workable process has the same five stages.
| Step | What happens | Owner | Typical duration |
|---|---|---|---|
| 1. Request and log | Change written up on a standard form, given an ID, entered in the change log with a date and requester | Requester, logged by PMO or PM | Same day |
| 2. Initial screen | Reject duplicates, clarify vague requests, classify by size against the threshold table | Project manager | 1 to 2 days |
| 3. Impact assessment | Cost, schedule, resource, risk, quality, benefit and dependency impact estimated in writing, plus the option of not doing it | PM with technical and finance input | 3 to 10 days |
| 4. Decision | Approve, reject, defer, or approve with conditions, at the authority level matching the impact | PM, sponsor or change control board by threshold | At the next scheduled meeting |
| 5. Update and communicate | Baseline revised, budget adjusted, plan reissued, affected parties told, log closed out | Project manager | Within 5 days of decision |
Step five is the one that gets skipped, and skipping it undoes the other four. An approved change that never reaches the baseline means the project is being tracked against a plan the sponsor no longer approved. Every subsequent status report is then measuring performance against fiction, which is how a project can be reported green for months and still miss its date by a quarter. The same discipline shows up in earned value management, where an un-rebaselined change corrupts every variance figure downstream.
What goes on a change request form?
A change request form needs enough for a decision and no more. Ten fields is about right: any longer and requesters fill it in badly, any shorter and the board cannot decide. The essential set is the identifier, the requester and date, a plain description, the reason, the impacts, the options, and a recommendation.
- Change ID and date raised. Sequential, so the log can be read chronologically.
- Requester and sponsor. Who wants it, and which senior person is backing it.
- Description. What would change, in language a non-specialist can follow.
- Reason and driver. Regulatory, defect correction, new requirement, external dependency, cost saving. Classification matters because regulatory changes are not really optional and should be routed faster.
- Cost impact. One-off and ongoing, with the confidence level attached.
- Schedule impact. Days added to the critical path, not days of work.
- Resource impact. Which named roles, for how long, and whether they are already committed elsewhere.
- Risk and benefit impact. What new risk this introduces, and whether the business case still holds.
- Options considered. Including doing nothing, which should always be listed and costed.
- Recommendation and decision. The PM's view, then the board's decision, decision date and approver name.
The "do nothing" option is the field that most forms leave out and the one that changes the most decisions. A board looking at a single proposal tends to approve it. A board looking at a proposal next to the honest cost of leaving things as they are makes a genuine choice.
What is a change control board?
A change control board, or CCB, is the group with authority to approve or reject changes above a defined threshold. It is normally chaired by the project sponsor and includes the project manager, a finance representative, a technical or delivery lead, and a representative of the business area affected. Its defining feature is decision authority: a CCB decides, it does not advise.
Membership should be small and consistent. Five or six people who attend every time make better and faster decisions than twelve who rotate. The single most common membership mistake is leaving finance out, which produces changes approved on cost estimates nobody validated, and the second is leaving out whoever owns the resource pool, which produces changes approved without anyone confirming the people exist.
Cadence depends on change volume. Fortnightly suits most projects. Weekly is right for a large program in a volatile phase. Monthly is too slow for anything active, and a board that meets monthly will find that urgent changes get approved informally and presented as done, which is the failure mode that ends most change control processes.
You also need a written route for genuine emergencies: who can approve a change without the board (usually the sponsor and the PM together), what qualifies, and the requirement that it is presented at the next meeting for ratification and logging. Without that clause, every emergency becomes an argument about the process instead of a decision about the change.
Change control board vs change advisory board vs steering committee
These three get used interchangeably and they are not the same. Confusing them is how projects end up with a body that everyone assumes has authority and which actually has none.
| Change control board (CCB) | Change advisory board (CAB) | Steering committee | |
|---|---|---|---|
| Authority | Decides: approves or rejects | Advises: recommends to the change manager | Decides, at portfolio and investment level |
| Scope | Changes to one project or product baseline | Changes to live IT services and environments | The project itself: continue, stop, refund |
| Origin | Project management and engineering practice | ITIL service management | Corporate and project governance |
| Typical chair | Project sponsor or product owner | Change manager | Executive sponsor |
| Cadence | Weekly to fortnightly | Weekly, plus emergency sessions | Monthly or quarterly |
| Escalates to | Steering committee | IT leadership or the CCB | The portfolio board |
The practical relationship is a hierarchy. The CCB handles changes within the approved envelope of a project. Anything that breaks the envelope, meaning it changes the business case, moves the end date past a committed milestone, or needs money the project does not have, goes up to the steering committee, which is the body that can actually release funds. If your CCB is regularly approving things that alter the business case, the thresholds are set wrong.
Setting change control thresholds: who approves what
Thresholds are the part that determines whether the process survives contact with a real project. Route everything to the board and people bypass it. Delegate too much and the board finds out about material changes after they are built. The workable answer is a small table, agreed at kick-off, and written into the project plan.
| Change size | Example threshold | Approver | Turnaround |
|---|---|---|---|
| Minor | Under 1% of budget, no schedule impact, no scope change | Project manager, logged only | Same week |
| Moderate | 1% to 5% of budget, or up to 5 days on the critical path | Change control board | Next scheduled meeting |
| Major | Over 5% of budget, milestone at risk, or scope boundary moved | Steering committee | Next monthly meeting or called session |
| Business case affected | Benefits, strategic fit or total investment changes | Portfolio board | Next portfolio review |
Those percentages are a starting point, not a standard. Calibrate them so the board sees roughly three to six changes per meeting. Fewer and the thresholds are too loose. More and the board rushes, which is worse than delegating properly. Where these thresholds sit inside the wider set of decision rights is the subject of the project governance framework, and the individual roles holding each approval are best written down as a RACI matrix so nobody has to guess.
The change log
The change log is the register of every request and what happened to it, including the rejected ones. Rejected entries matter as much as approved ones, because the question that comes up eighteen months later is usually "did anyone consider this", and a log that only records approvals cannot answer it.
Columns worth keeping: ID, date raised, requester, description, driver, cost impact, schedule impact, status, decision date, approver, and the date the baseline was updated. That last column is the one that reveals whether the process is real. A log full of approved changes with blank baseline-update dates is a project that has lost its plan.
In regulated environments the log stops being project admin and becomes evidence. Pharmaceutical manufacturing, medical devices, financial services and anything under SOX all require a demonstrable record that changes to validated processes were assessed, authorized and traceable, and an auditor will ask to see it. Teams working under that kind of obligation usually end up mapping which changes trigger which control, and treating the log as a continuous compliance record rather than something reconstructed the week before an audit. The same instinct helps even where nothing is regulated, because the log is only useful if it is written as the change happens.
What is integrated change control?
Integrated change control is the PMI term for reviewing all change requests against the whole project rather than in isolation, so that a change approved for scope also flows through to the schedule, cost, resource, quality and communications plans. The word "integrated" is the point: changes rarely touch only one thing.
The practical failure it guards against is the change approved by one specialist without the knock-on effects being traced. A requirement is added, the technical lead confirms it is two days of work, it is waved through, and nobody notices it needs a test environment that is booked, a vendor amendment, and a retraining session for forty users. Integrated change control means one assessment covering every plan the change touches, which is why the impact assessment step deserves more time than the decision step.
At portfolio level the same logic scales up. A change on one project that pushes its delivery date can break a dependency another project is counting on, which is why change assessments should check the dependency register before the board sees them. The mapping technique for that is covered in dependency mapping.
Frequently asked questions
What is the difference between change control and change management?
Change control is the procedural side: assessing, approving and recording changes to a baseline. Organizational change management is the people side: communication, training and adoption so the change actually sticks. A change can be perfectly controlled and still fail because nobody prepared the users, and the reverse is equally common.
What is the difference between a change request and a change order?
A change request is the internal document asking for a change to be considered. A change order is the contractual instrument that amends a supplier agreement once a change is approved, adjusting price, scope or dates. One is a proposal inside your project, the other is a legally binding amendment with a vendor.
Who sits on a change control board?
Typically the project sponsor as chair, the project manager, a finance representative, a technical or delivery lead, a representative of the affected business area, and where relevant quality, security or the resource manager. Five or six consistent attendees works better than a large rotating group.
How often should a change control board meet?
Fortnightly suits most projects, weekly suits large programs or volatile delivery phases. The right cadence produces three to six changes per meeting. Anything slower than monthly and urgent changes get approved informally, which quietly kills the process.
What is a change control procedure?
A change control procedure is the written document describing how change control works on a given project or in a given organization: the form to use, the routing, the thresholds, the board membership, the meeting cadence, the emergency route, and how the log is maintained. It is the process written down so it survives a change of project manager.
Does agile use a change control board?
Usually not at the story level, because reprioritizing the backlog each iteration is the built-in change mechanism and a board would only slow it down. Agile teams still use change control at the boundary: changes to funding, scope commitments made to customers, release decisions, and anything that alters the business case the work was approved on.
What triggers a change request?
Most requests come from four sources: a new or clarified requirement, corrective action after a defect or an issue, an external driver such as regulation or a vendor change, and a risk response that alters the plan. That last one is why change control and the RAID log should be reviewed together rather than in separate meetings.
Can a change request be rejected?
Yes, and a board that never rejects one is not functioning. Rejection, deferral to a later phase, and approval with conditions are all legitimate outcomes. Recording the rejection with its reason matters, because the same request usually returns in a different form within a few months.
The test of a change control process is not whether it exists in the methodology. It is whether a project manager under pressure, three weeks from a milestone, with a senior stakeholder asking for one small addition, still writes it up. That only happens if the process is fast enough to be worth using and if the sponsor visibly backs it when it is inconvenient. A process that is thorough and slow will be bypassed by exactly the changes that most needed the scrutiny, which is why threshold design matters more than form design. For how these decisions connect to the scheduled review points across a project, see the stage gate process.
Last updated August 2026.