5.2 Issues Practice & Issue Management Approach

5.2 Issues Practice & Issue Management Approach

No matter how thoroughly a project is planned, unexpected events will occur during execution. Requirements change, stakeholders request new features, deliverables fail quality tests, and external environmental shifts introduce problems. In PRINCE2 7, the Issues Practice establishes a reliable, controlled mechanism for identifying, assessing, and acting upon any unplanned event or proposal for change.

PRINCE2 7 Definition: An issue is any relevant event that has happened, was not planned, and requires management action.

Without formal issue management, projects fall victim to unmanaged change—commonly known as scope creep—where gradual additions to project deliverables erode budgets, delay deadlines, and compromise quality without executive approval.

---

Types of Issues in PRINCE2 7

The Foundation syllabus requires candidates to recognize these issue-related types (they are not mutually exclusive labels in every scenario—an issue may be classified and then handled as an RFC or off-specification):

                             ┌───────────────────────────────┐
                             │       PRINCE2 ISSUE TYPES     │
                             └───────────────┬───────────────┘
                                             │
       ┌─────────────────────────────────────┼─────────────────────────────────────┐
       ▼                                     ▼                                     ▼
┌──────────────┐                      ┌──────────────┐                      ┌──────────────┐
│ Request for  │                      │     Off-     │                      │   Problem /  │
│    Change    │                      │ Specification│                      │   Concern    │
└──────────────┘                      └──────────────┘                      └──────────────┘

Change (general issue classification)

• Any relevant event that has happened (or is happening) that requires management attention may be recorded as a change-related issue before more specific classification.
• Not every issue is a formal Request for Change; some are problems, opportunities, or off-specifications.

Business Opportunity

• A business opportunity is a type of issue representing a beneficial possibility that was not in the original plan (for example, a supplier offers a higher-value feature at no extra cost, or a regulatory change unlocks an additional market).
• Opportunities still require controlled assessment—accepting them can affect scope, cost, benefits, and sustainability tolerances.
• Exam trap: do not confuse a business opportunity (a certain event/offer requiring a decision) with a risk opportunity (an uncertain future event).

1. Request for Change (RFC)

• Definition: A proposal to modify an agreed baseline product specification, project objective, or project scope.
• Origin: Submitted by any stakeholder (e.g., customer requesting an extra module, business user requesting modified workflow).
• Financial Impact: Always requires evaluation against project cost, time, and quality targets; usually funded via the Change Budget if approved.

2. Off-Specification (Off-Spec)

• Definition: Something that should be delivered by the project but is not delivered, or does not satisfy agreed quality criteria or product specifications.
• Origin: Usually identified during testing, quality reviews, or technical audits (e.g., a delivered software module fails to achieve required throughput of 1,000 transactions per second).
• Action Required: The Project Board must decide whether to grant a concession (accepting the product as-is), order refactoring, or mandate alternative remedial action.

3. Problem / Concern

• Definition: Any other event, query, or observation that requires management attention and does not involve a direct change to a baseline product or off-specification.
• Origin: Operational issues, team resource shortages, supplier disputes, or technical queries (e.g., loss of a key senior developer during stage 2).

---

The Issue Management Approach

Created during the Initiating a Project process, the Issue Management Approach defines how issues and changes will be handled throughout the project lifecycle. It outlines:

• Issue Logging Rules: How issues are logged, categorized, and assigned unique reference numbers.
• Severity & Priority Scales: Standardized matrices to rate issue severity (e.g., Minor, Major, Critical) and priority (e.g., Low, Medium, High, Must Have).
• Escalation Thresholds: Criteria defining when an issue can be resolved by the Project Manager versus when it must be escalated to the Change Authority or Project Board.
• Change Authority Setup: Composition, financial authority limits, and decision rules for the delegated Change Authority.
• Change Budget Rules: Administrative rules governing how the Change Budget is allocated and accounted for.

---

The 5-Step Issue and Change Control Procedure

PRINCE2 defines a rigorous 5-step procedure for processing every logged issue:

Step 1: Capture

• Receive the issue and determine whether it should be dealt with informally or formally.
• If informal, record it in the Daily Log.
• If formal, create an entry in the Issue Register, assign an Issue ID, and draft an Issue Report.

Step 2: Assess

• Evaluate the impact of the issue on the project's performance targets (Time, Cost, Quality, Scope, Risk, Benefit, Sustainability).
• Assess the impact on the Business Case, stage plans, and downstream operations.
• Determine issue priority and confirm whether resolving it would breach stage tolerances.

Step 3: Propose

• Identify and evaluate potential options for resolving the issue.
• For each option, analyze costs, benefits, secondary risks, schedule impact, and trade-offs.
• Formulate a recommended course of action.

Step 4: Decide

• Submit the Issue Report and recommendations to the appropriate decision body:
  • Project Manager: Resolves minor issues within granted stage tolerances.
  • Change Authority: Approves or rejects Requests for Change within delegated change budget limits.
  • Project Board: Decides on issues that exceed stage tolerances or require project baseline alterations.

Step 5: Implement

• Execute the approved decision.
• Update the relevant management products (Project Plan, Stage Plan, Product Description, Work Packages).
• Update the Issue Register and notify affected stakeholders.

---

Change Authority & The Change Budget

The Change Authority

While the Executive holds overall accountability for approving project changes, reviewing every minor Request for Change can overwhelm the Project Board. Therefore, the Project Board may delegate authority for approving change requests to a designated person or group known as the Change Authority.

• Delegation Scope: Clear financial and scope limits must be defined in the Issue Management Approach (e.g., Change Authority may approve RFCs up to $10,000 per item).
• Composition: Can be the Project Manager (for minor changes), a user representative, a technical expert, or a formal change advisory committee.

The Change Budget

PRINCE2 7 Definition: A Change Budget is a sum of money allocated by the Executive to fund approved Requests for Change.

• Purpose: Ensures money is readily available to fund agreed scope additions without requiring constant corporate funding requests.
• Separation: The Change Budget is distinct from the stage baseline budget and the Risk Budget. It belongs to the Executive/Change Authority, not the Project Manager.