9.1 Issues Practice: Issue vs Change & Categories

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.

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.