In the context of PRINCE2 7, the Issue Management Approach is a baseline management product created during the 'Initiating a Project' process. It describes precisely how the project will capture, assess, and control issues. Under PRINCE2 definitions, an 'issue' is a relevant event that has happened, was not planned, and requires management action; this includes requests for change, off-specifications (where a product fails to meet criteria), and general problems or concerns.

The primary objective of this document is to establish a standard, effective procedure for handling deviations from the project plan, thereby protecting the project's baselines (cost, time, scope, quality) from uncontrolled scope creep. It defines the project's specific 'Issue and Change Control Procedure,' which typically follows the steps: Capture, Assess, Decide, and Implement.

Key components of the Issue Management Approach include:

1. Roles and Responsibilities: It clarifies who can authorize changes (identifying the Change Authority and the budget available to them), the role of Project Support in maintaining the Issue Register, and the Project Manager's decision-making limits.
2. Scales: It establishes consistent metrics for prioritizing issues (e.g., MoSCoW - Must have, Should have, Could have, Won't have for now) and rating severity, ensuring objective assessment across the team.
3. Configuration Management: It details how product versions (Configuration Items) and records will be tracked to ensure that the status of project assets is always known.
4. Timing and Reporting: It outlines when issue reviews occur and how decisions are communicated to stakeholders.

Without a robust Issue Management Approach, a project lacks the governance required to manage uncertainty. By defining these rules upfront, the project team ensures that every change or problem is treated on its merits, balanced against the Business Case, and managed without derailing the project's justification.

In the context of PRINCE2 7, the Issue Register is a vital management product within the Issues practice, serving as the central repository for capturing and maintaining information on all formal issues. An issue is defined as any relevant event that has happened, was not planned, and requires management action. The Issue Register is distinct from the Daily Log, which handles informal management notes; only issues requiring formal handling—specifically Requests for Change (RFCs), Off-specifications, and Problems/Concerns—are recorded here.

From a Practitioner perspective, the register is used to monitor and control the project's direction. It is created during the 'Initiating a Project' process and updated continually throughout the lifecycle, particularly during 'Controlling a Stage'. Each entry typically includes a unique Issue ID, the type of issue, the date raised, the originator, a description, and the current status (e.g., live, closed, or unresolved). Crucially, it documents the impact analysis, detailing how the issue affects project performance targets (time, cost, quality, scope, benefits, and risk).

The Issue Register ensures that every change request or deviation is visible, assessed, and tracked until resolution. It supports the Project Manager in reporting to the Project Board via Highlight Reports and End Stage Reports, ensuring that stakeholders are aware of current challenges. Effective maintenance of the Issue Register provides an audit trail of all decisions made regarding changes and problem resolution, preventing scope creep and ensuring that the project remains aligned with its Business Case.

In the context of PRINCE2 7, the Issue Report is a specific management product used to describe an issue in detail. While the Issue Register functions as a high-level log of all issues raised during the project, the Issue Report serves as the detailed dossier for items that require formal analysis and decision-making, particularly those that exceed the Project Manager's delegated tolerances.

The primary purpose of the Issue Report is to provide the Project Board (or the appointed Change Authority) with sufficient information to make an informed decision regarding a Request for Change, an Off-specification, or a Problem/Concern. The report is dynamic; it is created when the issue is first captured and is updated as the issue is examined and proposed solutions are formulated.

A robust Issue Report includes a unique identifier, the type of issue, and a comprehensive description of the issue's cause and effect. Crucially, it contains an impact analysis. This section details how the issue and its proposed solutions affect the project's performance targets (time, cost, quality, scope, benefits, and sustainability), the Business Case, and the project risk profile.

Furthermore, the report outlines the recommendation options. The Project Manager presents different courses of action, detailing the resource requirements and implications of each, and clearly states a recommended path. Finally, the document records the decision made by the relevant authority (approve, reject, defer, or request more information). By formalizing this data, the Issue Report ensures that significant changes or deviations are handled in a controlled manner, preventing scope creep and ensuring alignment with business objectives.

In the context of PRINCE2 7, the Issues practice is designed to identify, assess, and control any relevant event that has happened, was not planned, and requires management action. These events are categorized into three distinct types of issues to ensure they are handled appropriate by the Project Manager.

1. Request for Change: This is a proposal for a modification to a baseline. In PRINCE2, a baseline is a reference point (such as an approved Plan or Product Description) that has been signed off. Any change to these frozen documents—whether it implies adding a new feature, removing a scope item, or altering a timeline—is classified as a Request for Change. These typically incur costs or time delays and require formal approval from a Change Authority.

2. Off-specification: This issue type arises when a product is missing a feature, fails to meet a specific requirement, or is not available when expected. It represents a failure to meet the agreement outlined in the Product Description. For example, if a software component fails a security test or a physical prototype is smaller than the agreed dimensions, it is recorded as an Off-specification.

3. Problem/Concern: This is a broad category covering any other issue that the Project Manager must resolve or escalate. It often includes general inquiries, disputes, or external events impacting the project (such as a supplier delay). Significantly, a risk that has materialized (occurred) is also treated as a Problem/Concern.

Properly categorizing these issues in the Issue Register allows the project management team to assess their impact on project performance targets—time, cost, quality, scope, benefits, and sustainability—and decide on the correct course of action, whether that be a formal change procedure or corrective action.

In PRINCE2 7, the Change Control Process is a fundamental aspect of the Issue Management practice. Its purpose is to ensure that all changes to the project's baselines—whether they are Requests for Change (RFCs), Off-Specifications, or general Problems/Concerns—are assessed and approved in a controlled manner, preventing uncontrolled scope creep.

The process follows a systematic cycle:

1. **Capture**: The issue is identified and formally recorded in the Issue Register. Early capture ensures visibility and prevents informal, unapproved work.

2. **Assess**: The Project Manager and relevant specialists perform an impact analysis. They evaluate how the issue affects the project's six performance targets: time, cost, quality, scope, benefits, and risk. This step determines the severity of the issue and its potential impact on the Business Case.

3. **Propose**: Based on the analysis, options are generated (e.g., accept, reject, defer, or workaround). The Project Manager recommends a specific course of action that aligns best with the project's objectives.

4. **Decide**: The appropriate authority makes the decision. Minor changes within work package tolerance may be decided by the Project Manager, while significant changes are escalated to the Project Board or a delegated Change Authority. A Change Budget allows the Change Authority to fund changes without constantly seeking new corporate funds.

5. **Implement**: Once approved, the necessary plans and Product Descriptions are updated (re-baselined), and Corrective Actions are issued via Work Packages to the teams.

This structured approach ensures that the project remains desirable, viable, and achievable despite the inevitability of change.

In the context of PRINCE2 7 and the Issues Practice, Baseline Management is a critical control mechanism that establishes fixed reference points for project products, plans, and documentation. A baseline represents the state of a 'Configuration Item' (a product or set of products) at a specific point in time that has been reviewed and agreed upon. Once a product is baselined, it is effectively 'frozen' and can only be changed through a formal change control procedure.

Within the Issues Practice, baselines serve as the standard against which potential changes and deviations are measured. An issue—defined as any event relevant to the management of the project which requires attention—often arises as a challenge to a baseline. For instance, a 'Request for Change' asks to alter a baselined product, while an 'Off-Specification' indicates that a product fails to meet the criteria defined in its baselined description. Without these fixed reference points, it would be impossible for the Project Manager or Project Board to assess the impact of an issue on time, cost, scope, or quality.

Baseline management prevents 'scope creep' and ensures version control. For example, when the Project Initiation Documentation (PID) is approved, it becomes the baseline for the project's scope. Any subsequent deviation requires an impact analysis to determine if the change is viable. This aligns with the principle of 'Manage by Exception,' as tolerances are set against these baselines. By strictly managing these reference points, PRINCE2 ensures that all stakeholders share a single version of the truth regarding what has been created and what is currently agreed upon, thereby maintaining the integrity and stability of the project environment.

In PRINCE2 7, the Issues practice manages deviations from the project baseline through rigorous governance, utilizing the concepts of Change Budget and Change Authority.

A **Change Budget** is a financial tolerance allocated specifically to fund authorized Requests for Change (RFCs). It is distinct from a contingency fund; it is not intended to cover overspending on original work or delays. Instead, it provides a strictly monitored 'bank account' to pay for new requirements or modifications to baselined products. If a proposed change exceeds the available Change Budget, the Project Manager must escalate the issue to the Project Board via an Exception Report, as this constitutes a deviation beyond agreed tolerances.

The **Change Authority** refers to the person or group authorized to make decisions regarding these changes. While the Project Board holds ultimate accountability for project success, reviewing every minor issue is inefficient. Consequently, the Project Board may delegate decision-making power. The parameters for this delegation—such as cost limits, severity levels, or specific technical domains—are defined in the Change Management Approach. For example, a Project Manager might be authorized to approve low-cost changes, while a dedicated Change Authority group handles medium-impact changes, leaving high-risk decisions to the Project Board.

Functionally, the Change Authority acts as the gatekeeper of the Change Budget. When an issue arises, the Change Authority assesses its impact on the Business Case and benefits. If they approve the change, the cost is deducted from the Change Budget. This system prevents uncontrolled scope creep by ensuring that every modification is financially accounted for and authorized by the appropriate management level, preserving the project's continued business justification.