Exam objective 3.2 focuses on a process that separates a controlled, stable IT environment from chaotic meltdowns. Change management and control is the formal system that ensures every modification to a system is requested, evaluated, approved, and tracked—so nothing breaks unexpectedly. For the PK0-005 exam, understanding this process is critical because it directly impacts project success, risk, and stakeholder confidence.
Jump to a section
A simple way to picture Change Management and Control
A home renovation is a carefully controlled process, not a sudden demolition.
Imagine you own a house and you want to knock down a wall between the kitchen and living room to create an open-plan space. You don’t just grab a sledgehammer and swing. First, you request a change from the local council by submitting a planning application (the formal change request). The council then performs an impact analysis: they check if the wall is load-bearing (could the roof collapse?), if it affects neighbours, and if it meets safety codes. Only after an architect reviews the plans and the council approves the application can you start work. During construction, you might find an unexpected pipe—that’s a new issue requiring a fresh change request. You pause, assess the impact on budget and timeline, and get approval from the project manager before proceeding. This mirrors IT change management: every modification to a live system, like a software update or a server reconfiguration, must go through a structured process to prevent outages, security breaches, or data loss. Without it, you risk chaos—just like a house collapsing because you ignored the load-bearing wall.
Change management and control is the structured process for handling any adjustment to a project’s scope, schedule, resources, or technical environment. In IT, a “change” could be anything from installing a software patch to adding a new feature or replacing a server. Without a process, team members might make unapproved alterations, leading to conflicts, downtime, or security holes.
The process typically follows these steps. First, someone identifies a need for change—perhaps a user requests a feature, or a bug is found. They submit a formal change request, which is a documented proposal describing what needs to change and why. This request is logged in a change log. Next, the change manager (a specific role) assesses the request. They perform an impact analysis: a detailed review of what the change will affect. This includes evaluating the risk (what could go wrong?), the cost (how much time and money is needed?), the resources required, and the effect on other parts of the project. The change manager may consult subject matter experts.
After impact analysis, the request goes to a change control board (CCB). The CCB is a group of stakeholders—often including the project manager, technical lead, business representatives, and testing lead—who have the authority to approve or reject changes. They meet regularly (e.g., weekly) to review all pending change requests. Their decision is based on the impact analysis, project priorities, and overall risk appetite.
If approved, the change is scheduled and implemented. The team must then verify that the change works as intended, often through testing. Finally, the change is closed in the change log with documentation of what was done and any lessons learned. If rejected, the requestor gets feedback and may resubmit with more information.
Why does this process exist? It prevents “scope creep,” where the project slowly expands beyond its original goals without proper control. It also ensures changes don’t break existing systems. For example, a developer might want to update a database to improve performance, but without analysis, they could accidentally break a critical reporting feature. The process forces consideration of all dependencies.
Before formal change management, projects often struggled with ad-hoc changes, miscommunications, and frequent failures. The structured approach—as defined by frameworks like ITIL (Information Technology Infrastructure Library) or PMI (Project Management Institute) standards—brings predictability and accountability.
Key terms to know:
Change request: the formal document initiating the process
Impact analysis: the evaluation of potential effects
Change control board (CCB): the approving body
Change log: the record of all requests and decisions
Emergency change: a change that bypasses normal process due to urgency (like a critical security patch), but still requires post-implementation review
Standard change: a pre-approved, low-risk change (like password reset) that doesn’t need CCB approval every time
For PK0-005, you must understand these terms and the flow. The exam often asks about the order of steps in the change management process, what the CCB does, and when an emergency change is appropriate.
In practice, change management is not about stopping change—it’s about controlling change safely. A good analogy is traffic lights: they don’t prevent driving, they ensure orderly flow and reduce collisions.
Consider a real IT project: deploying a new customer relationship management (CRM) system for a mid-sized company. The project has been running for three months, and the team is about to start testing. A business stakeholder suggests adding a new reporting dashboard that shows sales data in real-time. This is a change to the project scope (the planned set of features).
Here is what an IT professional does step by step:
First, the project manager or business analyst asks the stakeholder to fill out a change request form. The form includes a description of the change, the business reason (e.g., “sales team needs live data to close deals faster”), and an initial estimate of effort (e.g., 5 extra developer days). The form is submitted to the project manager, who logs it in the change log—a spreadsheet or project management tool like Jira or Azure DevOps.
Second, the project manager performs a preliminary assessment. They consider: does this change align with the project’s goals? Is it urgent? They then schedule a proper impact analysis. They meet with the lead developer, the test lead, and the database administrator to ask specific questions: how long will the new report take to build? Will the new queries affect database performance? Does the existing data structure support real-time calculations? The impact analysis is documented, including estimated cost (e.g., £2,500), schedule impact (e.g., two-week delay), risk rating (medium—because real-time data could slow the system), and dependencies (requires access to the sales database).
Third, the project manager presents the change request and impact analysis to the Change Control Board (CCB). The CCB includes the project sponsor (who pays for the project), the technical lead, a business representative from sales, and the quality assurance manager. They discuss the change. The sales representative argues it’s critical for user adoption. The tech lead warns about performance risks. The sponsor weighs cost versus benefit. After 20 minutes, the CCB votes: approved, with a condition that the database team must run a load test first.
Fourth, the project manager updates the change log: status changed to “Approved – in progress.” The developer implements the dashboard feature. The tester creates test cases. After development, the tester runs load tests—they simulate 100 users accessing the dashboard simultaneously. If performance degrades, they roll back the change and report back to the CCB. Assuming it passes, the change is deployed to the live environment during a planned maintenance window.
Finally, the project manager closes the change request, documenting the actual time and cost, any issues encountered, and a lesson learned: “always pre-approve DB-level access before building real-time reports.” This documentation helps future projects.
In this real scenario, the IT professional’s actions—logging, analysing, presenting to CCB, updating logs, testing, closing—are all part of change management. Without this process, the developer might have just built the dashboard without approval, causing a system crash during a live demo. That would harm the project’s reputation and budget.
The same process applies to smaller changes too, like patching a single server or updating a configuration file. The rigour can be lighter for low-risk changes, but the structure remains. Professionals use tools like change management software (e.g., ServiceNow, Cherwell) to automate the workflow and maintain an auditable trail—critical for compliance with standards like ISO 20000 or Sarbanes-Oxley.
The PK0-005 exam tests the change management process in objective 3.2, often with scenario-based questions where you must identify the correct sequence of steps or the appropriate action for a given situation. The exam is designed for IT project managers, so you need to know the standard flow—not any specific vendor tool.
Key concepts that appear frequently:
The order of the change management process: 1) Identify/request, 2) Evaluate/impact analysis, 3) Approve/deny, 4) Implement, 5) Verify/close. Questions may give a list of steps and ask you to put them in the correct order, or identify a missing step.
The role of the Change Control Board (CCB). The CCB reviews and approves/rejects changes; it does not implement them. A common trap is to confuse the CCB with the project manager or the person performing the impact analysis. The CCB is a group, not an individual.
Distinguishing among change types: standard (pre-approved, low risk – e.g., password reset), emergency (urgent, bypasses normal process but needs post-implementation review – e.g., critical security patch), and normal (everything else that goes through full CCB). The exam might present a scenario like “a server is down and needs immediate fix” – the correct answer is to implement as an emergency change, but still document it after.
Impact analysis vs. risk assessment. Impact analysis is specifically about what the change affects (schedule, cost, other systems). Risk assessment is about the probability and severity of adverse outcomes. The exam may use them interchangeably, but you should know they are separate steps.
The difference between a change log and a change request. The log is the list of all changes; the request is a single document.
Change classification: not all changes are equal. Low-risk changes may skip some steps. The exam might ask: “You are asked to change a shared printer setting, what is the best approach?” Answer: “Use a standard change if it’s pre-approved, otherwise treat as a normal change.”
Common traps in PK0-005 questions:
They mix up the order of implement and approve—you always approve before implement (except emergency changes which are approved retrospectively after control).
They test whether you know that the CCB should include stakeholders (business, technical, QA) – not just the project manager.
They include distractors like “implement the change and then ask for approval” – which is only acceptable for emergency changes after the fact.
They present overlapping concepts like scope management. Scope changes also go through change control, but the scope statement itself is controlled. Change management is broader than scope—it includes any change to the project baseline (schedule, budget, resources, etc.).
Memorise this short list of definitions:
Change request: formal proposal
Impact analysis: evaluation of effects
Change control board: approval authority
Change log: tracking document
Emergency change: urgent, bypasses normal approval
Standard change: pre-approved repetitive change
The exam loves asking “who approves a change?” – The CCB, not the project sponsor alone (unless the sponsor is on the CCB). Also, “when should you perform impact analysis?” – Always before approval.
Finally, expect a question on the “change freeze” period—a time near project delivery when no changes are allowed to avoid destabilising the system. This is used in large releases. Know that a change freeze requires special waiver approval.
Change management ensures every modification to a project baseline is formally requested, analysed, approved, implemented, and verified.
The Change Control Board (CCB) is a group of stakeholders that approves or rejects normal and emergency changes.
Impact analysis evaluates the effect of a change on scope, schedule, cost, quality, risk, and resources before approval.
Emergency changes bypass pre-approval but require full documentation and retrospective CCB approval.
Standard changes are pre-approved, low-risk, repetitive changes (like password resets) that do not need individual CCB review.
A change log provides an auditable record of all change requests and their outcomes.
Change management reduces scope creep and system outages by preventing unapproved modifications.
The process flow always follows: request, evaluate, approve, implement, verify—except for emergencies where approve comes after implement.
Mistake
Change management is just about saying no to every change to keep the project on track.
Correct
Change management is about evaluating and controlling changes, not rejecting them all. It allows beneficial changes while managing risk.
People associate 'control' with restriction. In reality, the process helps assess value and safety, enabling good changes to proceed.
Mistake
The project manager alone can approve changes because they have the authority.
Correct
Only the Change Control Board (CCB) or designated approver (depending on change type) has authority. The PM manages the process but doesn't approve alone in most organisations.
Project managers often feel responsible for all decisions, but change control distributes risk across stakeholders to prevent bias.
Mistake
Emergency changes bypass all change management steps completely.
Correct
Emergency changes skip the approval steps before implementation, but still require documentation, impact analysis after the fact, and retrospective approval by the CCB.
The word 'emergency' suggests no rules, but the process still demands accountability to prevent abuse and ensure learning.
Mistake
A change request and a change log are the same thing.
Correct
A change request is the individual document describing one change. The change log is the running list or database of all change requests and their statuses.
Beginners often confuse the singular document with the cumulative record because they both contain 'change' in the name.
Mistake
Only technical changes (like software updates) need change control; business process changes do not.
Correct
All baseline changes—whether technical, procedural, scope, schedule, or budget—should go through change control to maintain project integrity.
This misconception comes from IT-centric thinking, but project management standards apply to all project constraints.
You've finished Change Management and Control. Continue through the PK0-005 study guide to build a complete picture of the exam.
Done with this chapter?