Change theme. Every project, no matter how well planned, will face surprises — a stakeholder changes their mind, a supplier delivers the wrong part, or a new regulation appears. The Change theme gives you a formal system to handle these surprises without derailing the project, which is exactly why PRINCE2F tests it heavily: you need to know how to keep a project on track when reality hits the plan.
Jump to a section
The project manager on a kitchen renovation. Your friend decides to redo their kitchen. They have a clear plan: new cabinets, a quartz countertop, and a shiny new fridge. Halfway through the demolition, they realise the plumbing is from 1960 and won't support a modern dishwasher. This is a change — a deviation from the original plan, just like an issue in a project. The project manager must assess this: does the change (a new plumbing layout) affect the budget? Does it push back the completion date? Does it affect the quality of the finished kitchen? They write down the change request, score its impact (high, medium, low), and decide if the friend (the project board) needs to approve it. They also keep a master list of everything being installed — cabinets, appliances, paint colours — which is their 'configuration item register'. This is the core of the Change theme: a system to manage any deviation from the plan and keep track of all the project's components. Without it, you might end up with a new fridge that doesn't fit the cabinet gap, or a custom countertop that's measured for the old walls.
When the friend later wants to upgrade the light fixtures (another change), the project manager doesn't just say yes. They check the log: the electrician is booked for next week. Changing the fixtures now means rescheduling that job. The change request gets raised, the impact is assessed (medium cost, minor delay), and the friend is asked to formally approve the cost increase. The project manager updates the configuration item (the light fixtures) in their master list. This process — raise, assess, decide, track — is exactly how the Change theme works in PRINCE2. It's not about stopping change; it's about controlling it so the project doesn't derail.
The Change theme in PRINCE2 is the set of rules and procedures for managing any deviation from the approved project plan. A 'deviation' can be something going wrong (a 'problem' or 'off-specification'), something being requested to improve the product (a 'change request'), or a risk that has turned into a real issue. The theme's purpose is to answer one question: 'How will we assess and decide on any changes to the project?'
To understand this, you need to grasp three key concepts: issue, change control, and configuration management.
An 'issue' is any event that wasn't planned for and that requires a decision. PRINCE2 divides issues into three types:
Off-specification: something that should have been delivered but wasn't, or was delivered incorrectly. For example, the supplier shipped the wrong version of the software.
Change request: a request for something new or different that wasn't in the original plan. For example, the user wants an extra report.
Problem or concern: any other matter that needs attention, like a team member leaving or a budget freeze.
Every issue must be captured in the 'Issue Register', which is a log that records the date, description, priority, and decision for each issue. This is the project's memory for all unexpected events.
'Change control' is the procedure for assessing and deciding on issues. It has defined steps: capture the issue, assess its impact on time, cost, quality, scope, risk, and benefits, then decide whether to approve it, reject it, or defer it. The person who decides depends on the seriousness of the issue:
The Project Manager (PM) can approve minor changes within their delegated authority.
The Project Board (the senior stakeholders) must approve major changes.
Exceptional changes (e.g., threatening the whole project) may need a full re-plan and re-approval.
PRINCE2 provides a mechanism called 'change budget' — a pot of money set aside specifically to handle small, predictable changes without having to escalate every time. The change budget is part of the project's tolerance (the allowable deviation for each objective).
'Configuration management' is the discipline of identifying, tracking, and protecting the project's products (deliverables). Every product is called a 'configuration item' (CI). Examples of CIs include a design document, a piece of code, a user manual, or a training video. For each CI, you need to know its version (e.g., v1.0, v1.1), its status (draft, reviewed, approved, baselined), and where it is stored.
The 'Configuration Item Record' is a document that records this information for each CI. The 'Product Status Account' is a report that shows the current status of all CIs, helping the PM see which products are complete, which are in progress, and which are approved.
Why does PRINCE2 combine issues, change control, and configuration management into one theme? Because a change to one product often affects others. For example, a change request to add a new feature might affect the design document, the test plan, and the user manual. Configuration management tracks all those interlinked products. When a change is approved, the PM must update the configuration items to reflect the new versions. Without this link, you could approve a change but forget to update the relevant documents, leading to confusion.
In summary, the Change theme replaces the chaos of 'let's just change it as we go' with a controlled, traceable process. It ensures that every change is assessed, approved, and documented, and that the project always knows which versions of which products exist and are in use. This is crucial for the Foundation exam: you will be asked to identify the three types of issues, the roles responsible for decisions, and the difference between an issue and a risk.
Capture the issue
Any team member or stakeholder identifies a deviation from the plan — a product missing, a new request, a problem. This is recorded in the Issue Register with a unique ID, date, and description.
Assess the issue
The Project Manager analyses the impact on time, cost, quality, scope, risk, and benefits. This assessment helps decide whether the issue is minor or major, and determines the level of authority needed to approve it.
Decide on the issue
Based on the level of impact, the appropriate decision-maker (Project Manager, Change Authority, or Project Board) approves, rejects, or defers the issue. The decision is formally recorded in the Issue Register.
Implement the decision
If approved, the change is actioned. For a change request, this might mean coding a new feature. For an off-specification, it might mean fixing a defect. The project plan, budget, and schedule are updated as needed.
Update configuration items
All affected products (configuration items) are updated with new versions and statuses. The Configuration Item Record and Product Status Account are revised to reflect the current state of the project's products.
Close the issue
After implementation and verification, the issue is formally closed in the Issue Register. The team confirms that the change was completed successfully and any related risks are re-assessed.
An IT professional, like a project manager (PM) or a business analyst, uses the Change theme daily. Let's walk through a real scenario.
Your company is building a new mobile app for customers to track deliveries. The project has been running for three months. The design is approved, developers are coding, and testers are writing scripts. One morning, the marketing director (a key stakeholder) sends an urgent email: 'We need to add a feature that lets users rate the delivery driver. This will help us improve service. Can we include it in this release?'
Step 1: The PM identifies this as an 'issue' — specifically a 'change request', because it requests something not in the original scope. The PM logs it in the 'Issue Register' with a unique ID, date, and short description.
Step 2: The PM assesses the impact. They talk to the lead developer, who says it will take 2 weeks of work. The test lead says the test team is already at capacity; adding this means delaying existing testing. The PM calculates the cost: 2 weeks of developer time = $10,000. The delivery date must be pushed back by 2 weeks. The PM also notes that the change might increase customer satisfaction (a benefit) but also adds risk because the new feature hasn't been user-tested.
Step 3: The PM decides on the level of decision-making. The project has a 'change authority' level delegated to the PM for changes under $5,000. This change costs $10,000, so it must go to the Project Board. The PM prepares a 'Change Request' (a formal document) summarising the impact.
Step 4: The Project Board meets. They discuss the trade-off: is the benefit worth the delay and cost? They decide to approve the change, but only if the PM can reduce other scope (e.g., remove a minor 'settings' feature) to keep the original timeline. The PM re-plans, and the Board approves the modified plan.
Step 5: Now configuration management kicks in. The PM identifies all products affected by the change: the app design document, the code repository, the test cases, and the user manual. For each, the PM updates the 'Configuration Item Record': the design document goes from version 2.0 to version 2.1 (draft), the test cases get flagged for revision. The developers create a new branch in the code repository for the rating feature. Once the change is coded and tested, the PM updates the Product Status Account to show 'Implementation in progress' for the affected CIs.
Throughout this process, the PM uses tools like Jira or Azure DevOps to track issues and configuration items, but the PRINCE2 principles remain the same. The PM also ensures that the 'change budget' (if any) is updated. If the change was minor and within budget, the PM could approve it without the Board.
Later, if a developer accidentally deletes a file, that's an 'off-specification' issue. The PM logs it, assesses the impact (lost work, delay), and decides to restore from backup. The configuration management system (like Git) knew the exact version and location of the file, making recovery possible. Without it, the PM would be hunting for lost knowledge.
Every IT professional in a PRINCE2 project relies on this theme to keep the project stable. It prevents expensive mistakes like approving a change without knowing its cost, or losing track of which version of a contract is the latest.
The PRINCE2 Foundation exam tests your ability to recall facts about the Change theme. Here is exactly what you need to know.
First, memorise the three types of issues: off-specification, change request, and problem/concern. Exam questions will describe a scenario and ask you to identify which type it is. The trap is that they sometimes describe an off-specification as a 'bug' or 'defect'. The correct answer is still 'off-specification'. Another trap: they might describe a risk that has materialised (e.g., a supplier goes bankrupt); this is a 'problem/concern', not a change request.
Second, know the definition of each management product:
Issue Register: a log of all issues, their status, and decisions.
Issue Report: a more detailed document for a single issue (used for major issues).
Configuration Item Record: details about a single product (its version, status, owner).
Product Status Account: a summary report showing the status of all configuration items.
Exam questions often ask: 'Which management product lists the current version of every product?' Answer: Product Status Account. Or: 'When would you use an Issue Report rather than the Issue Register?' Answer: when an issue is so significant it needs its own detailed document.
Third, understand the concept of 'baseline'. A baseline is a frozen version of a product that has been formally approved. Once a baseline is set, you cannot change it without going through change control. For example, the project plan is baselined at the start. If you need to add a feature, you raise a change request; if approved, you create a new baseline. The exam may ask: 'What is the term for the approved version of a product?' Answer: baseline.
Fourth, know who does what. The Project Manager is responsible for day-to-day management of issues and configuration items. The Project Board approves major changes. The 'Change Authority' is a role assigned by the Board to approve changes within a set of limits (e.g., up to $10,000). The exam may ask: 'Who approves a change that exceeds the PM's delegated limits?' Answer: the Project Board.
Fifth, know the difference between 'issue' and 'risk'. A risk is an uncertain event that might happen. An issue is something that has already happened. The exam will test this distinction. For example, 'the supplier might go bankrupt' is a risk. 'The supplier is bankrupt' is an issue (problem/concern).
Sixth, understand that configuration management involves: identification (naming each CI), storage (where files live), status accounting (tracking versions), and auditing (verifying that the recorded information matches reality). The exam may ask you to order these steps or identify which is missing.
Finally, note the link between Change theme and other themes: the Business Case theme (because changes affect costs and benefits), the Risk theme (because issues are materialised risks), and the Plans theme (because changes affect the plan). The exam sometimes asks: 'Which theme provides the budget for implementing changes?' Answer: the Change theme, through the change budget and tolerance.
Typical question patterns: - 'Which of the following is an example of an off-specification?' (correct: a product that does not meet its specification) - 'Which role is responsible for creating the Issue Register?' (correct: the Project Manager) - 'What is the purpose of configuration management?' (correct: to identify, track, and protect the project's products)
The exam is not about interpreting philosophy — it's about memorising these definitions and roles. Practise with sample questions until the terms become automatic. The biggest trap is confusing 'Issue Report' with 'Issue Register' on a multiple-choice question. Remember: Register = the whole list; Report = a deep dive on one item.
An issue is any unplanned event that requires a decision.
There are three types of issues: off-specification, change request, and problem or concern.
The Issue Register is a log of all issues; the Issue Report is a detailed document for a single major issue.
Configuration management involves identifying, storing, tracking, and auditing all project products.
A baseline is a frozen, approved version of a product that can only be changed through change control.
The Project Board approves major changes; the Project Manager or Change Authority can approve minor changes within delegated limits.
The change theme works with the Business Case theme because changes affect cost, time, and benefits.
These come up on the exam all the time. Here's how to tell them apart.
Issue
Has already happened
Requires immediate decision
Recorded in Issue Register
Risk
May happen in future
Requires proactive management
Recorded in Risk Register
Off-Specification
Product does not meet agreed specification
Is a failure to deliver what was promised
Example: software feature missing a required function
Change Request
Requests something new not in original plan
Is a proposal for improvement or addition
Example: user wants a new report that wasn't specified
Issue Register
Log of all issues in project
Contains summary information for each issue
Used for tracking and reporting
Issue Report
Detailed document for one major issue
Contains full analysis and options
Used for decision-making by Project Board
Mistake
The Change theme is only about stopping people from making changes.
Correct
Its purpose is to manage changes in a controlled way, not to block them. It provides a process to assess, approve, and track changes, which often results in approving beneficial changes.
Beginners hear 'control' and assume it means prevention, not management. They miss that a good change process enables change to happen safely.
Mistake
An off-specification and a change request are the same thing.
Correct
They are different types of issues. An off-specification is a failure to deliver something that was promised. A change request is a request for something new or different that was never promised.
Both involve deviation from the plan, so beginners lump them together. But the exam explicitly tests the difference, often in scenarios.
Mistake
Configuration management is just about storing files on a server.
Correct
It is a structured discipline including identification, storage, status tracking, and auditing of all project products. It is as much about processes and records as it is about technology.
In everyday language, 'configuration settings' on phones or apps make people think of technical setup. They forget the tracking and audit aspects.
Mistake
The Project Board must approve every single change, no matter how small.
Correct
The Board can delegate authority to the Project Manager or a Change Authority to approve small changes within agreed tolerances and budget.
Beginners think all decisions go to the top. The exam loves to test delegation of authority as a way to speed up the project.
Mistake
Once a change is approved, you don't need to update the configuration items.
Correct
Every approved change must be reflected in the configuration management system. The affected products' versions and statuses must be updated.
People imagine change as a one-off event, not a ripple. They forget that changing one product usually updates others.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A risk is an uncertain event that may happen in the future. An issue is an event that has already happened and needs a decision now. You manage risks proactively; you react to issues.
The Project Manager is responsible for creating and maintaining the Issue Register. They log all issues raised during the project.
Yes, but the process can be scaled. Minor changes within tolerance can be approved by the Project Manager and logged simply. Major changes need formal escalation. The principle is that all changes are recorded, even if the response is minimal.
If no change budget is set, every change request must be funded by the project's contingency or by reallocating existing budget. The absence of a change budget means even small changes may require Project Board approval, slowing down the project.
Configuration management maintains a complete history of versions, changes, and approvals for each product. During an audit, the auditor can check that all changes were approved and documented, and that no unauthorised versions exist.
No, but it includes version control. Configuration management in PRINCE2 is broader than just software version control; it covers all project products (documents, hardware, contracts) and includes processes like baselining and status accounting.
You've finished Change Theme. Continue through the PRINCE2F study guide to build a complete picture of the exam.
Done with this chapter?