9.1 Types of Issues (Problem/Concern, External Event, Business Opportunity, Request for Change, Off-Specification)

Types of Issues (Request for Change, Off-Specification, Problem/Concern) in PRINCE2 7

Practitioner Core Mandate: In project environments, change is not an unexpected anomaly to be suppressed; it is an inevitable reality driven by shifting markets, emerging technologies, stakeholder discoveries, and operational friction. PRINCE2 7 rejects informal, ad-hoc change handling. Through the Issues practice, the method establishes a disciplined, transparent framework to identify, assess, and control any potential and approved changes to baselines, while systematically capturing and resolving all unexpected events that threaten project delivery.

---

1. Evolution & Purpose of the Issues Practice in PRINCE2 7

One of the most prominent evolutionary refinements in PRINCE2 7 is the renaming of the Change theme (from the 6th Edition) to the Issues practice.

Why the Renaming Matters

In previous editions, practitioners often fell into the trap of equating "Change" purely with formal scope modifications—such as a client requesting a new software module or an architect modifying building specifications. This narrow interpretation overlooked the reality that project managers spend enormous energy responding to operational surprises: broken test servers, team sickness, supplier disputes, ambiguous specifications, or component defects.

By retitling this discipline the Issues practice, PRINCE2 7 underscores that:

1. Issues encompass changes, non-conformances, and general problems: Formal change requests are merely one subset of a broader universe of issues requiring management intervention.
2. Issue management protects project baselines: You cannot have effective progress control or quality assurance if deliverables and plans are altered without formal assessment and authorization.
3. Proactive problem resolution preserves business justification: Unresolved issues quickly erode financial returns, stretch schedules, inflate carbon footprints, and destroy customer trust.

Core Purpose of the Issues Practice

The purpose of the Issues practice is to:

• Identify, assess, and control any potential and approved changes to baseline management and specialist products;
• Provide an open, structured mechanism to capture, evaluate, and resolve all issues (problems, queries, and non-conformances) that arise throughout the project lifecycle;
• Ensure that project baselines (time, cost, quality, scope, benefits, risk, and sustainability) are modified only with explicit authorization from designated governance roles.

                      THE ISSUES PRACTICE GOVERNANCE UMBRELLA

   ┌─────────────────────────────────────────────────────────────────────────┐
   │                             ISSUES PRACTICE                             │
   ├────────────────────────┬────────────────────────┬───────────────────────┤
   │   REQUEST FOR CHANGE   │   OFF-SPECIFICATION    │  PROBLEM OR CONCERN   │
   │         (RFC)          │   (NON-CONFORMANCE)    │  (SITUATIONAL EVENT)  │
   │ Proposed modifications │ Deliverables failing   │ Operational obstacles,│
   │ to agreed baselines    │ to meet agreed quality │ team disputes, supply │
   │ or project scope.      │ criteria.        │ shocks, or queries.         │
   ├────────────────────────┴───────────┬────────────────────────────────────┤
   │   EVENT EXTERNAL TO THE PROJECT    │       BUSINESS OPPORTUNITY         │
   │   Outside the project's control    │   Unanticipated positive           │
   │   but impacting it (a supplier     │   consequences for the project     │
   │   ceasing to trade, for example).  │   or the user.                     │
   └────────────────────────────────────┴────────────────────────────────────┘
                                    │
                                    ▼
   ┌─────────────────────────────────────────────────────────────────────────┐
   │                   CONTROLLED MANAGEMENT INTERVENTION                    │
   │        (Assess 7 Targets ──► Authorize Decision ──► Update Baselines)   │
   └─────────────────────────────────────────────────────────────────────────┘

Alignment with PRINCE2 Principles

The Issues practice operationalizes three core PRINCE2 principles:

• Focus on Products: Changes are evaluated against specific Product Descriptions and baselined assets. Changes are not made in a vacuum; they are tied directly to deliverable integrity.
• Manage by Exception: Delegated authority levels dictate who approves an issue. Minor matters remain with the Project Manager, routine changes may sit with a Change Authority, and significant variances escalate to the Project Board.
• Continued Business Justification: Every proposed change or resolved issue must be evaluated to confirm that the project remains desirable, viable, and achievable under the Business Case.

---

2. Definitional Precision: What is an Issue vs. a Risk?

A perennial source of confusion on the Practitioner exam is the precise boundary between a Risk and an Issue. Confusing the two leads to incorrect documentation, flawed governance escalations, and severe scoring penalties.

Official Definitions

• Risk: An uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. A risk is defined by two fundamental characteristics: probability (the likelihood of occurring, strictly between 0% and 100%) and impact (the positive or negative consequence if it occurs). Risks are strictly future-focused.
• Issue: A relevant event that has happened, was not planned, and requires management action. An issue has a probability of 100%; it has already occurred or is currently occurring in the present.

                          THE CERTAINTY SPECTRUM
   
   PROBABILITY:   0% ────────────── (0% < P < 100%) ────────────── 100%
   STATE:       Impossible               RISK                   ISSUE
   TIMEFRAME:   N/A                  Future-Focused         Present Reality
   TOOL:        N/A                  Risk Register          Issue Register /
                                                            Daily Log

The Lifecycle Conversion Between Risks and Issues

Risks and issues do not live in isolated silos; they interact dynamically across the project lifecycle:

1. Materialization of a Threat: When a threat identified in the Risk Register actually occurs, its probability becomes 100%. It ceases to be a risk and must immediately be logged as an Issue in the Issue Register (or Daily Log) and managed through the issue procedure.
2. Secondary Risks Generated by Issues: When an issue occurs and a management response or change is proposed, that proposed action frequently introduces new uncertainties. These potential consequences must be identified and captured in the Risk Register as secondary risks.

Comparative Governance Matrix: Risk vs. Issue

---

3. The Five Issue Categories in PRINCE2 7

PRINCE2 7 recommends that all issues are categorized as one of five types. The 6th Edition offered three (request for change, off-specification, problem/concern); Version 7 promotes event external to the project and business opportunity into named categories of their own. Proper classification is critical because each type triggers distinct analytical workflows, financial authorizations, and product register updates — and because the categories give the project management team data about which kinds of issue keep recurring, which often reveals that some other aspect of project management is not working.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE 5 ISSUE CATEGORIES IN PRINCE2 7                     │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. REQUEST FOR CHANGE (RFC)                                                 │
│ • Proposal to alter an approved baseline deliverable, plan, or requirement  │
│ • Examples: Adding a new mobile app screen; changing material from steel to │
│   carbon fiber; updating system security requirements                       │
│ • Financial Source: Change Budget (if allocated) or Project Budget          │
├─────────────────────────────────────────────────────────────────────────────┤
│ 2. OFF-SPECIFICATION                                                        │
│ • Deliverable fails or is forecast to fail its agreed Product Description   │
│ • Non-conformance against quality specifications or acceptance parameters   │
│ • Examples: Server response time is 3.5s (limit: 2.0s); concrete wall is    │
│   5mm thinner than specification; missing documentation chapter             │
│ • Resolution Paths: Corrective rework, rejection, or formal CONCESSION      │
├─────────────────────────────────────────────────────────────────────────────┤
│ 3. PROBLEM OR CONCERN                                                       │
│ • A PROBLEM has an immediate and negative impact                            │
│ • A CONCERN is an issue whose timeliness and impact need to be assessed     │
│ • Examples: lead developer resigns; two user reps disagree on a workflow    │
│ • Resolution Paths: Internal PM resolution, workaround, or Exception Report │
├─────────────────────────────────────────────────────────────────────────────┤
│ 4. EVENT EXTERNAL TO THE PROJECT                                            │
│ • Something outside the project's control that may still impact it          │
│ • Examples: a supplier goes out of business; a regulator changes the rules; │
│   a competitor launches first; a flood closes the site                      │
│ • Resolution Paths: analyse the resulting impact, consider alternatives,    │
│   and monitor the external environment regularly                            │
├─────────────────────────────────────────────────────────────────────────────┤
│ 5. BUSINESS OPPORTUNITY                                                     │
│ • An issue that represents unanticipated positive consequences for the      │
│   project or the user                                                       │
│ • Examples: a supplier offers a free capability upgrade; a grant becomes    │
│   available; an early release window opens                                  │
│ • Resolution Paths: assess against the business case, then recommend        │
└─────────────────────────────────────────────────────────────────────────────┘

[!CRITICAL EXAM RULE: ISSUE OR RISK?] PRINCE2 7 states that when categorizing an issue you should check whether it is actually a risk: the distinction is that risks are uncertain. If the item is uncertain, transfer it to the risk register and follow the risk management approach instead. The reverse check also applies — review the risk register for entries that are no longer uncertain and move them to the issue register.

3.1 Request for Change (RFC)

A Request for Change (RFC) is a formal proposal to modify a product that has already been approved and baselined, or to alter the agreed scope, specifications, or parameters of the project.

Key Characteristics of an RFC:

• Targets Baselined Assets: An RFC applies only to baselined products. Prior to formal baseline approval (for instance, during draft brainstorming or initial prototyping within a Work Package), modifying a document is simply normal iterative development—not an RFC.
• Originators: Can be submitted by any stakeholder—an end-user desiring improved usability, a corporate sponsor reacting to legislative amendments, a Senior Supplier suggesting an upgraded hardware platform, or the Project Manager identifying a process enhancement.
• The Golden Rule of Baselines: Once a management product (e.g., Project Plan, Stage Plan, Project Brief) or specialist deliverable (e.g., architectural blueprint, software code, physical component) is baselined, it cannot be changed without an approved RFC.
• Funding Mechanism: If a Change Budget was established during project initiation, approved RFCs are financed from that ring-fenced fund. If no Change Budget exists, funding must come from approved stage cost tolerances or require a formal budget uplift authorized by the Project Board.

3.2 Off-Specification

An Off-Specification is an issue where a deliverable fails—or is forecast to fail—to meet its agreed specification, quality specifications, or acceptance criteria. It represents an explicit non-conformance between what was promised in the Product Description and what is actually delivered.

The Two Sub-Types of Off-Specification:

1. A Missing Product or Feature (Shortfall in Scope): Something that was agreed in the baseline specification will not be provided (e.g., a software release that was promised with single sign-on authentication is delivered without that feature due to technical incompatibility).
2. A Defective Product or Attribute (Shortfall in Quality): A product is delivered, but its performance, physical properties, or attributes fail to meet agreed tolerances (e.g., an industrial HVAC cooling unit operates at 68 decibels when the Product Description specified a maximum noise ceiling of 60 decibels).

Resolution Paths for an Off-Specification:

When an Off-Specification is captured, three resolution paths exist:

• Corrective Action / Rework: The supplier or delivery team fixes the defect at their own cost (or project cost, depending on contract terms) to bring the product into full compliance with its Product Description.
• Rejection: The customer refuses to accept the defective product, requiring the supplier to deliver a compliant replacement.
• Granting a Concession: The Project Board (or designated Change Authority) formally agrees to accept the product as delivered, without requiring rework, even though it fails to meet the approved Product Description.

                     THE OFF-SPECIFICATION RESOLUTION TRIAGE
   
                              [OFF-SPECIFICATION]
                         (Product fails specification)
                                      │
               ┌──────────────────────┼──────────────────────┐
               ▼                      ▼                      ▼
        [REWORK / FIX]         [REJECT PRODUCT]        [GRANT CONCESSION]
     Supplier modifies item   Customer rejects item;  Project Board accepts
     to achieve compliance    demands compliant       item as-is; baselines
     with Product Description replacement             updated to reflect defect

[!CRITICAL EXAM RULE] The Concession Principle: Granting a concession does not mean the product complied with its quality specifications. A concession is an explicit managerial dispensation to accept an imperfect deliverable. A Project Manager never has the authority to grant a concession unilaterally unless specifically delegated as the Change Authority within strict financial and performance limits. Concessions that affect project-level acceptance criteria or business justification must be approved by the Project Board.

3.3 Problem or Concern

PRINCE2 7 defines these precisely: a problem is an issue with an immediate and negative impact; a concern is an issue whose timeliness and impact need to be assessed. Both are relevant events that have occurred, were not planned, and require management action, and neither is a request to modify an approved baseline nor a product quality non-conformance. Problems and concerns are often first raised informally, in conversation, before any formal capture.

Judgement is required here. Capturing too many problems and concerns as formal issues inundates the project management team with trivial decisions; filtering or prejudging them is equally damaging. Minor matters (a broken project printer, for example) belong in the daily log; anything needing formal handling goes to the issue register.

Common Examples:

• Human Resource Disruptions: The lead structural engineer suddenly resigns; two key test analysts contract severe illness during critical acceptance testing.
• Commercial & Legal Obstacles: An external supplier is acquired by a competitor and halts contract renegotiations; a new municipal zoning bylaw requires unexpected environmental permits.
• Operational Queries & Disagreements: Two user representatives disagree fundamentally on operational workflows; a supplier disputes the interpretation of payment milestone criteria.
• Realized Threats: A severe storm floods a construction site, destroying raw materials and halting work for 10 days (this was previously a risk in the Risk Register, but has now happened).

3.4 Event External to the Project

An external event sits outside the project's control but may still impact it. The manual's own example is a supplier going out of business: the project cannot prevent it, but the project management team must analyse the resulting impacts and consider finding an alternative supplier. This category exists precisely to stop such events being mislabelled as problems the project manager is expected to have foreseen — and it is the reason PRINCE2 7 advises monitoring the project's external environment on a regular basis.

• Typical examples: regulatory change, a competitor's product launch, currency or commodity shocks, a natural hazard closing a site, a parent-company reorganization.
• Governance route: capture, assess the impact across the seven performance targets, recommend options, and escalate if the impact breaches or is forecast to breach tolerance.
• Exam trap: an external event is not automatically an off-specification, even when it stops a product meeting its specification. Classify by cause, then handle any resulting product shortfall as a separate off-specification if one exists.

3.5 Business Opportunity

A business opportunity is an issue that represents unanticipated positive consequences for the project or the user. PRINCE2 7 treats upside events as issues to be captured and assessed rather than windfalls to be quietly absorbed, because acting on them still changes baselines and still consumes money and time.

• Typical examples: a supplier offers a no-cost capability upgrade; a grant or tax relief becomes available mid-project; an earlier release window opens because a dependency finished early.
• Governance route: the same five-step technique. Assess the impact on the business case, recommend options, and let the appropriate authority decide — capturing an opportunity that breaches stage tolerance still requires an exception report.
• Exam trap: do not confuse a business opportunity (an issue: it has happened) with an opportunity in the risk register (uncertain: it may happen).

---

4. Comprehensive Classification & Diagnostic Matrix

To master Practitioner exam questions, candidates must instantly classify real-world project scenarios into the correct issue type or risk category:

---

5. Practical Scenario Evaluations

Scenario A: The "Complimentary Feature" Trap

During Stage 3 of an enterprise ERP deployment, a software developer realizes that adding an automated PDF export utility to the reporting module will only take 4 hours of coding. Because the customer mentioned wanting PDF exports during an informal lunch, the developer codes and bundles the utility into the build without notifying the Project Manager. The developer proudly announces at the weekly checkpoint that the project delivered extra functionality for free.

Practitioner Evaluation:

• Governance Flaw: The developer and team have breached baseline configuration control and the principle of Focus on Products. In PRINCE2, there is no such thing as an "informal free feature."
• Hidden Impacts: The unapproved feature was not analyzed against the other performance targets. It lacks an approved Product Description, has no agreed quality specifications, was not tested by quality assurance, increases future software maintenance costs, introduces potential cybersecurity vulnerabilities, and may invalidate system accreditation.
• Correct PRINCE2 Action: The Project Manager must stop the unauthorized release. The feature must be captured formally as a Request for Change (RFC) in the Issue Register. An impact assessment must examine documentation, testing, security, and maintenance implications. Only if approved by the designated Change Authority or Project Board can the Product Description and baseline build be updated.

Scenario B: The Marginal Quality Shortfall and the Silent Pass

On a medical diagnostics hardware project, the baselined Product Description for a blood centrifuge mandates an operating temperature of 4.0°C ± 0.2°C. During final testing of the pre-production unit, the sensor records 4.3°C. The lead engineer argues: 'It is only 0.1°C outside our tolerance window; in medical practice, that difference is negligible. We should sign off the quality review and dispatch the unit so we don't delay the stage milestone.'

Practitioner Evaluation:

• Governance Flaw: The lead engineer is attempting to bypass quality control and conceal an Off-Specification. Delivery teams have zero authority to redefine quality specifications or ignore tolerances.
• Legal & Commercial Liability: Delivering a non-conforming medical device exposes the organization to catastrophic regulatory fines, patient safety hazards, and contractual breach.
• Correct PRINCE2 Action: The failure must be recorded as an Off-Specification in the Issue Register. An Issue Report must be drafted. If technical rework is impossible or uneconomic, the matter must be escalated to the Project Board. Only the Project Board (consulting clinical experts and the Senior User) possesses the authority to grant a formal concession or order mandatory redesign.

Scenario C: Materialized Risk Transition

During project initiation for an overseas pipeline, the team identified a risk: 'Potential civil unrest in Region B could disrupt pipeline trenching.' The probability was assessed at 30%, and a risk response strategy was logged in the Risk Register. During Stage 2, violent protests erupt across Region B, and local authorities shut down all civil construction.

Practitioner Evaluation:

• Governance Flaw: The Project Manager leaves the matter in the Risk Register, updating the probability to 'High' and waiting for the next monthly Highlight Report to inform the Project Board.
• Failure to Escalate: The event is no longer a risk—it is an active reality (100% certainty). By treating it as a risk, the PM fails to take immediate issue-control action.
• Correct PRINCE2 Action: The PM must immediately log the event as an Issue (Problem/Concern) in the Issue Register and close or update the risk entry. The PM must assess the impact on stage cost, schedule, and safety tolerances. Because the work stoppage will breach stage time tolerances, the PM must submit an Exception Report to the Project Board without delay.

---

6. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Confusing an Off-Specification with an RFC: An RFC asks for permission to change a baseline; an Off-Specification notes that a deliverable already fails (or will fail) to meet its agreed baseline. If a supplier builds something that doesn't work to spec, that is an Off-Specification, not an RFC.
• Trap 2: Believing a Concession Erases the Defect: A concession does not rewrite history; the deliverable remains non-conforming. The concession simply records that the Project Board approved the delivery of the defective product as-is, preventing endless rework while documenting the variance in the project log: product register.
• Trap 3: Treating Realized Threats Purely as Risks: When an exam scenario states that 'a previously identified risk has now occurred,' any answer suggesting the PM should 'update the risk probability to 100% and continue monitoring' is incorrect. It must be logged as an Issue in the Issue Register.
• Trap 4: Project Managers Unilaterally Granting Concessions: A Project Manager cannot accept non-conforming deliverables or grant concessions unless specifically granted delegated Change Authority within defined boundaries. Quality criteria and acceptance baselines belong to the Project Board.
• Trap 5: Classifying Stakeholder Inquiries as RFCs Without Baselines: If a stakeholder asks for clarification on a draft requirement during the initiation stage before the Project Initiation Documentation (PID) is baselined, that is a query or normal planning dialogue—not a Request for Change.