9.2 Issue and Change Control Procedure

The 5-Step Issue and Change Control Procedure in PRINCE2 7

Practitioner Core Mandate: In PRINCE2 7, managing issues is not an informal, gut-feel activity left to the personal preferences of individual project managers. The method defines a rigorous, repeatable five-step procedure—Capture, Assess, Recommend, Decide, and Implement—that applies universally to Requests for Change, Off-Specifications, and Problems/Concerns. Understanding this sequence, the artifacts created at each stage, and the precise governance thresholds that trigger escalation is essential for the Practitioner examination.

---

1. Architecture of the 5-Step Procedure

The Issue and Change Control procedure ensures that every issue is systematically identified, analyzed for multi-dimensional business impact, evaluated against alternative options, decided by the appropriate authority level, and tracked through to verified execution.

┌─────────────────────────────────────────────────────────────────────────────┐
│            THE PRINCE2 7 ISSUE AND CHANGE CONTROL PROCEDURE                 │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 1: CAPTURE                                                             │
│ • Receive issue from any stakeholder                                        │
│ • Triage: Minor/operational ──► DAILY LOG                                   │
│           Formal/baseline   ──► ISSUE REGISTER & create ISSUE REPORT        │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 2: ASSESS                                                              │
│ • Conduct multi-dimensional impact assessment across ALL 7 TARGETS:         │
│   [Costs] [Timescales] [Quality] [Scope] [Benefits] [Risk] [Sustainability] │
│ • Assess impact on Business Case, Project Plan, Stage Plan, & Tolerances    │
│ • Identify and evaluate alternative options (including 'do nothing')        │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 3: PROPOSE                                                             │
│ • Formulate balanced recommendation based on trade-off analysis             │
│ • Confirm whether recommendation remains within delegated tolerances        │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 4: DECIDE                                                              │
│ • Refer to appropriate governance authority:                                │
│   - Project Manager (within delegated stage limits)                         │
│   - Change Authority (within delegated change boundaries & budget)          │
│   - Project Board (major RFCs, concessions, or stage tolerance breaches)    │
│ • Outcome: APPROVE | REJECT | DEFER | GRANT CONCESSION                      │
│ • If stage tolerance breached ──► Raise EXCEPTION REPORT                    │
├─────────────────────────────────────────────────────────────────────────────┤
│ STEP 5: IMPLEMENT                                                           │
│ • Execute approved corrective action via Work Packages or plans             │
│ • Update baselines, Product Descriptions, and the product register          │
│ • Communicate outcome to originators; verify resolution; close Issue Report │
└─────────────────────────────────────────────────────────────────────────────┘

---

2. Step 1: Capture (Triage, Registration & Issue Reports)

The procedure begins the moment an issue is raised. A vital principle of PRINCE2 is that anyone involved in or affected by the project can raise an issue—a team member, external contractor, user representative, project assurance officer, or corporate executive.

The Initial Triage: Daily Log vs. Issue Register

Not every issue requires formal administrative overhead. The Project Manager conducts an immediate triage upon receiving an issue:

                                  ISSUE RECEIVED
                                        │
                       Can the PM resolve it informally
                       without impacting baselines, stage
                       tolerances, or external stakeholders?
                                        │
                       ┌────────────────┴────────────────┐
                      YES                               NO
                       │                                 │
                       ▼                                 ▼
                 [DAILY LOG]                     [ISSUE REGISTER]
            Informal day-to-day             Formal tracking required;
            operational tracking;           Assign unique Issue ID;
            no formal Issue Report          Mandatory ISSUE REPORT created

• Informal Handling (Daily Log): If the issue is a minor operational matter, straightforward informational query, or tactical adjustment that the Project Manager can handle directly within delegated autonomy—without altering an approved baseline, threatening stage tolerances, or impacting external commitments—it is recorded in the Daily Log. The PM manages its resolution informally without creating formal management products.
• Formal Handling (Issue Register): If the issue is a Request for Change (RFC), an Off-Specification, or a significant Problem/Concern that requires formal evaluation, Project Board consultation, cross-functional coordination, or potential tolerance escalation, it must be formally recorded in the Issue Register and allocated a unique reference identifier.

The Issue Report: Anatomy and Lifecycle

For every issue entered into the formal Issue Register, the Project Manager creates an Issue Report. The Issue Report is a dynamic management product that matures across the five steps of the procedure:

Core Sections of an Issue Report:

1. Identifier & Issue Title: Unique reference number and descriptive headline.
2. Issue Type: Classified strictly as RFC, Off-Specification, or Problem/Concern.
3. Originator & Date Raised: Who identified the issue and when.
4. Issue Description: Detailed narrative explaining the symptoms, root cause, and current operational context.
5. Priority & Severity: Initial rating (e.g., High, Medium, Low) based on business criticality.
6. Impact Assessment: Comprehensive analysis across the 7 performance targets and the Business Case.
7. Evaluated Options: Detailed examination of viable resolution options (including costs, risks, pros, and cons).
8. Recommendation: The Project Manager's proposed solution and justification.
9. Decision & Authority: The formal ruling (Approve, Reject, Defer, Concession), authorizer's name, and decision date.
10. Implementation & Closure Details: Verification that corrective actions were completed, configuration baselines updated, and final close-out confirmed.

---

3. Step 2: Assess (Multi-Dimensional Impact Analysis across 7 Targets)

The Assess step represents the analytical engine of the procedure. Rushing this step or conducting superficial reviews is a primary cause of project failure and a frequent subject of Practitioner exam testing.

The Seven Project Performance Targets

In PRINCE2 7, an impact assessment is defective if it considers only time and financial cost. The Project Manager must systematically evaluate the consequences of the issue and its potential solutions across all seven project performance targets, plus the overarching Business Case:

┌─────────────────────────────────────────────────────────────────────────────┐
│            7-TARGET IMPACT ASSESSMENT FRAMEWORK IN PRINCE2 7                │
├─────────────────────────────────────────────────────────────────────────────┤
│ 1. COSTS: Financial capital required, supplier fees, ongoing maintenance    │
│    costs; funding sources (Change Budget vs. Stage Budget).                 │
│ 2. TIMESCALES: Delays to Work Packages, milestones, stage completion, or    │
│    project end date; critical path shifts.                                  │
│ 3. QUALITY: Performance degradation, customer satisfaction impacts,         │
│    reliability changes, adherence to Product Description criteria.          │
│ 4. SCOPE: Additions, removals, or modifications of specialist products;     │
│    boundary changes between delivery stages.                                │
│ 5. BENEFITS: Changes to projected business return, user efficiency gains,   │
│    payback periods, or the creation of operational dis-benefits.            │
│ 6. RISK: New secondary threats introduced by the change; alterations to the │
│    probability or impact of existing risk exposures.                        │
│ 7. SUSTAINABILITY (NEW v7): Changes to embodied or operational carbon,      │
│    material recycling targets, environmental compliance, and social impact. │
└─────────────────────────────────────────────────────────────────────────────┘

Evaluating the Business Case & Tolerances

Beyond individual targets, the assessment must determine:

• Impact on Stage & Project Tolerances: Will resolving the issue cause stage cost, time, quality, scope, benefits, risk, or sustainability to breach agreed tolerance boundaries? If so, the issue cannot be resolved under delegated authority—an Exception Report will be required.
• Continued Business Justification: Does the issue or proposed change undermine the fundamental economic viability of the project? If an RFC costs $50,000 but only delivers $10,000 in discounted lifecycle benefits, business justification is weakened.

Formulating Options (The "Do Nothing" Mandate)

When assessing an issue, the Project Manager must formulate and evaluate at least two to three realistic options.

[!CRITICAL EXAM RULE] An options assessment is incomplete unless it includes the "Do Nothing" (or baseline preservation) option. In PRINCE2, the Project Board must always have the ability to see what happens if no change is approved, including the operational fallout, residual defects, or missed opportunities. Comparing proposed solutions against the "do nothing" baseline provides the objective benchmark for decision-making.

---

4. Step 3: Recommend (Formulating Recommendations)

In the Recommend step, the Project Manager synthesizes the findings of the impact assessment into a clear, defensible recommendation.

The Art of Trade-Off Analysis

Every recommendation involves balancing conflicting project variables:

• Should the project spend money from the Change Budget to protect the stage milestone date?
• Should the project accept a minor quality shortfall (concession) to avoid exceeding the stage sustainability carbon cap?
• Should a requested feature be scaled back to fit within existing Work Package hours?

Verifying the Governance Boundary Before Submission

Before presenting the recommendation, the Project Manager must verify:

1. Does the recommended action fall within the Project Manager's delegated authority?
2. Does it fall within the delegated limits of the Change Authority?
3. Does it breach stage tolerances, requiring an Exception Report to the Project Board?

---

5. Step 4: Decide (Delegation & Governance Boundaries)

In the Decide step, the evaluated options and recommendation are reviewed by the individual or body holding the appropriate delegated authority.

                          GOVERNANCE DECISION HIERARCHY
   
   MANAGEMENT LEVEL                 AUTHORITY & REMIT
   
   Business layer      ────────►  Approves project-level tolerance breaches
   Management                       or fundamental Business Case alterations.
          ▲
          │ Escalates when Project Tolerances threatened
   Project Board ────────────────►  Approves major RFCs, stage Exception Plans,
   (Directing Level)                significant concessions, and project scope.
          ▲
          │ Escalates when Stage Tolerances or CA limits exceeded
   Change Authority ─────────────►  Approves routine RFCs and concessions within
   (Delegated Role / CCB)           pre-allocated financial/schedule caps.
          ▲
          │ Escalates when RFC exceeds PM threshold or alters baselines
   Project Manager ──────────────►  Approves minor operational adjustments
   (Managing Level)                 within stage tolerances and Daily Log matters.

The Four Core Decision Outcomes

The deciding authority selects one of four formal determinations:

1. Approve: The proposed change or corrective action is authorized. Necessary funds are released (e.g., from the Change Budget), and the Project Manager is instructed to implement the decision.
2. Reject: The request is denied. The baseline remains unchanged, the reasons for rejection are documented in the Issue Report, and the originator is informed.
3. Defer: The decision is postponed. The change may be deferred to a subsequent management stage, held for consideration during an upcoming release cycle, or transferred to the post-project operational maintenance backlog.
4. Grant Concession: (Applicable strictly to Off-Specifications) The Project Board or Change Authority formally agrees to accept the deliverable as-is, despite its failure to satisfy the Product Description. The concession is logged, baselines are updated, and no corrective rework is demanded.

The Tolerance Escalation Rule

If the deciding authority realizes that implementing the chosen option will cause a stage tolerance to be breached, the Project Manager cannot simply implement the decision. The Project Manager must immediately log the breach, prepare an Exception Report, and escalate to the Project Board during the Directing a Project (DP) process.

---

6. Step 5: Implement (Action, Re-baselining & Communication)

Once a decision is rendered, the procedure moves into the final, operational step: Implement.

Key Implementation Activities:

1. Execute Corrective Actions: The Project Manager issues new or revised Work Packages to Team Managers (or external contractors) to perform authorized rework, development, or adjustments.
2. Re-baseline Management and Specialist Products: If an RFC or concession was approved, the Project Manager updates the affected Product Descriptions, Stage Plans, or Project Plan. The newly approved version becomes the new formal baseline.
3. Update the project log: product register: Project Support or the Project Manager updates the status, version number, and cross-references in the project log: product register for all affected deliverables.
4. Communicate Outcomes: The Project Manager notifies the originator, affected users, suppliers, and assurance roles of the final decision and delivery schedule.
5. Verify Resolution & Close Issue: Once physical or digital changes are verified through quality testing, the Project Manager records the actual costs and dates, marks the issue as closed in the Issue Register, and archives the completed Issue Report.

---

7. Comprehensive Comparative Matrix: Issue Control Steps

---

8. Practical Scenario Evaluations

Scenario A: The Urgent Client Workaround (Bypassing Assess and Decide)

During Stage 2 of a municipal transit smartcard initiative, the transport authority's commercial director calls the Project Manager demanding that Apple Pay and Google Wallet integration be activated immediately for an upcoming mayoral press conference. To keep the client happy, the PM bypasses the formal issue procedure, calls the software supplier, and authorizes 200 hours of emergency contractor billing to code the integrations over the weekend.

Practitioner Evaluation:

• Governance Flaw: The Project Manager committed severe governance malpractice by jumping directly from an informal request to Implementation, completely bypassing Assess, Recommend, and Decide.
• Impact: The unauthorized expenditure of 200 contractor hours breaches the stage financial tolerance. Furthermore, the unassessed integration introduces severe cybersecurity vulnerabilities, fails data privacy compliance, and diverts developer focus from the baselined transit ticketing engine.
• Correct PRINCE2 Action: The PM must log the request as an RFC in the Issue Register and create an Issue Report. A multi-dimensional impact assessment must evaluate security, cost, schedule, and sustainability impacts. Because the 200 contractor hours breach stage cost tolerances, the PM must submit an Exception Report alongside the Issue Report to the Project Board for a formal decision.

Scenario B: The Overlooked Sustainability Tolerance

A pharmaceutical packaging line project experiences supplier delivery delays. The Project Manager discovers an alternative air-freight logistics vendor who can deliver the machinery on time, preserving the stage completion date and staying within the stage financial cost tolerance. However, air freight will increase the project's logistics carbon footprint by 400%, breaching the agreed stage sustainability tolerance cap by 60 tonnes of CO2e. The PM approves the air freight contract without consulting the Project Board, reasoning that time and cost were protected.

Practitioner Evaluation:

• Governance Flaw: The PM violated the Manage by Exception principle by treating sustainability as a secondary, non-binding metric.
• Impact: In PRINCE2 7, Sustainability is an equal performance target governed by mandatory tolerance boundaries. Breaching sustainability tolerances is just as severe as breaching financial or schedule tolerances.
• Correct PRINCE2 Action: During the Assess step, the PM was obligated to identify the sustainability tolerance breach. In the Recommend step, the PM should have recognized that approving the air-freight contract exceeded delegated authority. The PM was required to escalate the issue via an Exception Report to the Project Board, allowing the Board to decide whether to authorize the carbon overrun or accept a stage schedule delay.

Scenario C: Concession with Price Renegotiation

A supplier delivers 500 bespoke stainless-steel casings for laboratory autoclaves. Quality inspection reveals that the surface finish is brushed matte rather than mirror-polished as mandated in the Product Description. The autoclave manufacturer's Senior User confirms that the matte finish has zero operational or safety impact. The supplier offers a $25,000 price discount if the project accepts the casings as-is.

Practitioner Evaluation:

• Governance Handling: The issue is correctly logged as an Off-Specification. During the Assess step, impact analysis confirms that technical performance, safety, and operational longevity are unaffected.
• Decision & Implementation: The Project Manager presents the Issue Report to the Project Board (or Change Authority), recommending that the project grant a concession and accept the $25,000 credit into the project account. The Project Board approves the concession. During the Implement step, Project Support updates the project log: product register for the casings to document the matte finish, and the Issue Report is formally closed.

---

9. Practitioner Exam Pitfalls & Governance Traps

• Trap 1: Bypassing the Assess Step for Urgent Issues: Exam scenarios often present an 'urgent executive request' and tempt candidates to choose immediate implementation. Under PRINCE2, no matter how urgent the request, the PM must never bypass Assess and Decide.
• Trap 2: Omitting the 'Do Nothing' Option: In options analysis questions, any proposal that fails to consider what happens if the project rejects the change or accepts the baseline status quo is incomplete under PRINCE2 rules.
• Trap 3: Project Manager Approving Tolerance-Breaching Changes: If an RFC or issue resolution requires spending more than the remaining stage cost tolerance, the Project Manager cannot approve it, even if the Change Authority has delegated powers. A tolerance breach always requires an Exception Report to the Project Board.
• Trap 4: Forgetting Configuration Updates at Implementation: Implementing a change is not complete when the supplier finishes coding or manufacturing. The change is only complete when baseline Product Descriptions, the project log: product register, and the Issue Register are formally updated and verified.
• Trap 5: Confusing Issue Register with Daily Log Remits: The Daily Log is for informal, day-to-day operational issues managed by the PM. The Issue Register is for formal issues requiring tracking, multi-target impact analysis, or board escalation.