Change is normal on projects: requirements become clearer, business priorities shift and problems appear. What matters is that changes are controlled. Change control is the formal process for proposing, evaluating, approving or rejecting and then implementing changes to the project's approved baselines for scope, schedule and cost. Without it, small untracked changes accumulate and the project drifts away from what was agreed, and nobody can explain later why it went over budget. Change control does not exist to say no; it exists to make sure every yes is a conscious decision with known consequences.
The process usually follows the same steps. First, someone identifies the need and submits a change request, a written description of what should change and why. A request can come from anyone: the sponsor, a user, a vendor or a team member. Second, the project manager logs it in the change log with an ID, date, requester and status so it can be tracked. Third, the project manager and team perform an impact assessment: what the change will do to scope, schedule, cost, quality, resources and risk, and what happens if it is not made. Fourth, the change goes to the decision maker named in the change management plan, often a change control board (CCB) made up of the sponsor and key stakeholders. The CCB approves, rejects or defers it.
If the change is approved, the project manager updates the affected baselines and documents (scope statement, work breakdown structure or WBS, schedule, budget, risk register) and then implements the change like any other work. The change is validated to confirm it was delivered as approved. Finally, the decision is communicated to everyone affected, including the person who asked for it, using the channels in the communication plan. Rejected and deferred changes are also recorded, with the reason, so the same request does not keep reappearing and there is an audit trail.
Some organizations let the project manager approve small changes within agreed tolerances, for example up to two days of schedule impact or a small amount of money, and send larger ones to the CCB. The change management plan written during planning defines these thresholds, the forms or ticket types to use, and who sits on the board. Notice that the project manager rarely approves significant changes alone and never simply tells the team to start work on an unapproved request. Also separate the project CCB from the organization's change advisory board (CAB), which approves changes to production IT systems; a project deployment may need both.
The order matters, and exam questions test it. The correct sequence is: identify and document the request, log it, assess impact, get a decision, update the plan and baselines, implement, validate, and communicate. A version of this can be pictured as a simple workflow.
Request -> Log -> Impact assessment -> CCB decision
approved -> update baselines -> implement -> validate -> communicate
rejected/deferred -> record reason -> communicateConsider a worked example. Halfway through a customer portal project, the marketing director asks a developer to add a live chat feature. The developer redirects her to the project manager, who asks her to submit a change request. The impact assessment shows three extra weeks, a new software subscription and a security review. The CCB meets, weighs the benefit against the delay, and approves it for a second release instead of the current one. The project manager updates the release plan and backlog, logs the decision and emails the director and team explaining what was decided and why.
Common mistakes: implementing a change first and documenting it later (outside a true emergency path); skipping impact assessment because the change 'looks small'; letting the requester or the project manager approve beyond their authority; and forgetting to communicate rejections. Another trap is updating the schedule without updating the budget and risk register, which leaves baselines inconsistent. Exam wording usually asks for the next step or the first thing to do. 'A stakeholder asks for a new feature' means the first step is a formal change request, not starting work or refusing outright. 'A change was requested; what next?' is impact assessment. 'Who decides?' is the CCB or the authority named in the change management plan. 'The change was approved; what next?' is update baselines and communicate.
Key terms
- Change control
- The formal process for evaluating and approving or rejecting changes to project baselines.
- Change request
- A formal written proposal to modify scope, schedule, cost or another baseline.
- Change log
- A record of all change requests with their status, decisions and dates.
- Impact assessment
- An analysis of how a proposed change would affect scope, schedule, cost, quality, resources and risk.
- Change control board (CCB)
- The group authorized to approve, reject or defer project change requests.
- Change management plan
- The planning document defining the change process, forms, approval thresholds and board membership.
During an office relocation project, the facilities manager emails the project manager asking for two extra conference rooms to be wired. The project manager logs a change request, estimates the extra cabling, labor and a four-day delay, and presents it to the CCB. The board approves it, the project manager updates the scope statement, schedule and budget, and a note goes out to the cabling vendor, the facilities manager and the team.
Check yourself
A user asks a developer directly for a new report. What should happen?
The request should be redirected into a formal change request, logged and assessed before any work begins.
What is the step between logging a change request and the CCB decision?
The impact assessment on scope, schedule, cost, quality, resources and risk.
Why record rejected change requests?
To keep an audit trail and stop the same request resurfacing without context.
After a change is approved, what must the project manager update?
The affected baselines and documents, such as the scope statement, schedule, budget and risk register, and then communicate the decision.