9.1 Issues Practice: Issue vs Change & Categories

PRINCE2 Practitioner Version 7

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current Exam Facts 1.2 Exam Strategy & Open-Book Technique

2 PRINCE2 7 Method Overview

2.1 The PRINCE2 7 Method 2.2 What Changed in PRINCE2 7 2.3 Performance Targets, Tolerances & Project Context

3 PRINCE2 Principles (1–4)

3.1 Continued Business Justification 3.2 Learn from Experience 3.3 Defined Roles, Responsibilities & Relationships 3.4 Manage by Stages

4 PRINCE2 Principles (5–7) & Applying Principles

4.1 Manage by Exception 4.2 Focus on Products 4.3 Tailor to Suit the Project 4.4 Applying Principles in Context

5 People Management in Projects

5.1 Organisational & Project Ecosystems 5.2 Leadership in Projects 5.3 Team Culture & Diversity 5.4 Communication, Stakeholder Engagement & Change Management

6 Practices Overview & Business Case

6.1 The Seven Practices & Tailoring 6.2 Business Case: Desirability, Viability & Achievability 6.3 Business Case Lifecycle & Management Products 6.4 Business Case Application & Tailoring Scenarios

7 Practices: Organising & Plans

7.1 Organising: Roles & Accountability 7.2 Organising: 5-Step Ecosystem Technique 7.3 Plans: Three Levels & Product-Based Planning 7.4 Plans: Techniques, Tolerances & Tailoring

8 Practices: Quality & Risk

8.1 Quality: Planning, Control & Assurance 8.2 Quality Techniques & Management Products 8.3 Risk: Threats & Opportunities 8.4 Risk 5-Step Technique & Application

9 Practices: Issues

9.1 Issues Practice: Issue vs Change & Categories 9.2 Issues 5-Step Technique & Supporting Techniques 9.3 Change Control, Configuration & Priority/Effort Assessment

10 Practices: Progress, Sustainability & Application

10.1 Progress: Controls, Tolerances & Reports 10.2 Sustainability as the 7th Performance Target 10.3 Tailoring the Practices 10.4 Practices Application Scenarios (BL4)

11 Processes: Model, Starting, Directing & Initiating

11.1 The Seven Processes & Process Model 11.2 Starting Up a Project 11.3 Directing a Project 11.4 Initiating a Project

12 Processes: Controlling a Stage & Product Delivery

12.1 Controlling a Stage 12.2 Managing Product Delivery 12.3 Stage Control & Exception Scenarios (BL4) 12.4 Work Packages & Reporting Cycle

13 Processes: Stage Boundary, Closing & Tailoring

13.1 Managing a Stage Boundary 13.2 Closing a Project 13.3 Tailoring the Processes 13.4 Process Application Scenarios (BL4)

14 Tailoring, Management Products & Exam Technique

14.1 Tailoring to Project Environment, Scale & Agile 14.2 Management Products & the v7 Project Log 14.3 Final Exam Technique, Full Scenarios & Common Traps

9.1 Issues Practice: Issue vs Change & Categories

Key Takeaways Explain This Topic AI

An issue is anything that could affect the project; a change is a specific issue that impacts an agreed baseline (schedule, estimates, scope, or how work is done).

PRINCE2 v7 promotes an "issues-friendly" culture — communication should always come before control, so issues surface early rather than being hidden.

v7 issue categories are: problems/concerns, external events, business opportunities, requests for change, and off-specifications.

An off-specification means a product does not meet its agreed Product Description; a request for change asks for a deliberate alteration to a baseline.

Issues are formally recorded in the Issue Register (part of the v7 Project Log) and may also be captured informally in the Daily Log.

Last updated: August 2026

What is an Issue?

In PRINCE2 v7 , an issue is anything that could affect the project — positively or negatively. It is the broad umbrella term. A change , by contrast, is a specific kind of issue that impacts the project baseline : the scheduling, the cost estimates, the agreed scope, or the way the work is performed. The distinction matters because not every issue warrants the full machinery of change control.

A team member raising a concern about a supplier's responsiveness is raising an issue. If that concern then forces a replan of the next stage's dates, it becomes a change to the baseline. Treating the initial concern as a change from the outset would be heavy-handed and discourage early reporting.

Communication Before Control

v7 emphasizes an issues-friendly culture. The project environment should want to know about issues early. The maxim is: communication should always come before control . If people fear that raising a concern triggers immediate punishment or bureaucracy, they suppress it — and suppressed issues become expensive surprises later. The Project Manager should make it psychologically safe to flag problems, opportunities, and off-specifications as soon as they appear.

This mindset is why the practice was renamed from "Change" to "Issues" in v7. The previous name implied that the only thing worth managing was an alteration to the baseline. The wider lens captures concerns, opportunities, and external events that may never become changes but still need to be seen, assessed, and acted on.

Issue Categories in v7

PRINCE2 v7 groups issues into five categories. Knowing these cold is essential for the exam, because scenario questions regularly ask you to classify a described situation.

Category What it is Typical example

Problem / concern A difficulty that needs attention but does not (yet) require a baseline change A team member worried about the availability of a key SME

External event Something outside the project's control that affects it A new regulatory deadline published mid-project

Business opportunity A chance to deliver extra or different benefit A new technology makes a planned feature cheaper to deliver

Request for change A deliberate ask to alter an agreed baseline (scope, product, plan) Sponsor asks for an additional report to be produced

Off-specification A product will not (or did not) meet its agreed Product Description A build is delivered without one of the features in its spec

Problems/concerns, external events, and business opportunities may or may not mature into changes. Requests for change and off-specifications are, by definition, baseline-impacting and so enter change control once confirmed.

Where Issues Are Recorded

v7 consolidates project-level records into the Project Log . The Issue Register is the formal component of the Project Log used to record issues that need tracking, assessment, and a decision. For minor or day-to-day items that do not warrant a formal entry, the Daily Log provides an informal capture mechanism — often used by Team Managers for low-level concerns that may later be escalated into the Issue Register.

A useful mental model: the Daily Log is the "inbox" where anything noteworthy is jotted down; the Issue Register is the "tracked queue" for items that need a documented assessment and decision.

Issue vs Change: the practical test

A useful question to ask when an issue appears is: does this require us to alter something that has already been agreed? If the answer is yes — a baseline document, a stage plan, a Product Description, the project plan, or the business case itself — then the issue has matured into a change and change control applies. If the answer is no, the issue can be handled within the current plan and tolerances, often by the Project Manager without escalation.

Note that an issue can start as one category and mature into another. A concern about a supplier's responsiveness is a problem/concern at first; if it leads to a replan of the next stage's dates, it has become a request for change to the stage plan. The Issue Register entry should track that evolution so the audit trail shows how the concern became a change.

Why the rename matters for the exam

In earlier versions of PRINCE2 the practice was called "Change", and some older study materials still use that label. For the v7 Practitioner exam, the practice is Issues — the wider lens — and change is treated as one subset. Be wary of any answer that treats "issue" and "change" as synonyms; v7 deliberately separates them.

Exam application

In the Practitioner exam you will typically face several styles of question in this area:

Classify the issue : given a short scenario, identify which of the five categories applies. Watch for the trap of calling any negative item an off-specification — an off-specification specifically concerns a product not meeting its description , not just any bad news.

Issue vs change : decide whether a described situation is merely an issue or has matured into a change. The test is whether an agreed baseline (scope, schedule, cost, product definition, method of work) is affected.

Recording location : identify whether an item belongs in the Issue Register or can stay in the Daily Log, based on whether it needs formal tracking and a documented decision.

Culture and philosophy : questions that test whether the project's behavior is "issues-friendly" — for example, a PM who penalizes the messenger is violating the communication before control principle, even if the underlying issue is handled correctly.