8.4 Issue Resolution & Decision Registers

8.4 Issue Resolution & Decision Registers

[!NOTE] Core MSP Definitions:

• Risk vs. Issue: A risk is an uncertain future event or set of events that, should it occur, will have a positive or negative effect on the achievement of objectives. An issue is an event that has already occurred, or is certain to occur, that is currently affecting the programme and requires immediate management intervention.
• Decision Register: A permanent governance record that captures the context, options considered, rationale, approving authority, and date for every major strategic decision made throughout the programme lifecycle.

During a multi-year transformation, uncertainty constantly collapses into reality. Anticipated risks either fail to materialize or they manifest as tangible, present-tense disruptions: a mission-critical contractor goes into liquidation, a national regulatory authority introduces a new compliance standard, or an integration testing phase reveals catastrophic data corruption.

When an event becomes a reality, it is no longer managed through probabilistic risk assessments; it becomes an issue. Managing issues demands rapid, decisive, and authoritative intervention. MSP 5th edition establishes the Issue Resolution Approach and the Decision Register to ensure issues are resolved transparently, systematically, and at the correct level of authority.

---

The Critical Difference Between Risks and Issues

A fundamental requirement on the MSP Foundation exam is the ability to cleanly distinguish between a risk and an issue.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     THE UNCERTAINTY-TO-REALITY SPECTRUM                     │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│    PROBABILISTIC FUTURE (Risk)             DETERMINISTIC PRESENT (Issue)    │
│  ┌─────────────────────────────┐         ┌─────────────────────────────┐    │
│  │          A RISK             │         │          AN ISSUE           │    │
│  │ • "Might happen in future"  │ Collapse│ • "Has happened / Certain"  │    │
│  │ • Probability < 100%        │────────►│ • Probability = 100%        │    │
│  │ • Threat or Opportunity     │ Event   │ • Present-tense reality     │    │
│  │ • Proactive mitigation      │ Occurs  │ • Reactive resolution       │    │
│  │ • Logged in Risk Register   │         │ • Logged in Issue Register  │    │
│  └─────────────────────────────┘         └─────────────────────────────┘    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Comparison of Key Dimensions

1. Temporal Dimension: A risk is future-focused (what might happen). An issue is present-focused (what has happened or is happening right now).
2. Probability: A risk has an estimated likelihood greater than 0% but less than 100%. An issue has a probability of 100%—it is a confirmed fact.
3. Polarity: Risks can be negative (threats) or positive (opportunities). Issues, by definition in delivery management, represent problems, specification failures, or changes that demand resolution.
4. Management Action: Risk management focuses on proactive preventive controls or contingency plans. Issue management focuses on reactive containment, impact mitigation, root-cause resolution, and decision-making.

---

The Issue Resolution Approach & Types of Issues

The Issue Resolution Approach defines the processes, roles, tools, and escalation criteria for identifying, assessing, and resolving issues. MSP does not prescribe a fixed issue taxonomy, but most programmes adopt the widely used three-way classification also found in PRINCE2:

                                  PROGRAMME ISSUES
                                         │
            ┌────────────────────────────┼────────────────────────────┐
            ▼                            ▼                            ▼
┌────────────────────────┐  ┌────────────────────────┐  ┌────────────────────────┐
│   REQUEST FOR CHANGE   │  │   OFF-SPECIFICATION    │  │   PROBLEM / CONCERN    │
│         (RFC)          │  │                        │  │                        │
├────────────────────────┤  ├────────────────────────┤  ├────────────────────────┤
│ Proposal to alter:     │  │ Deliverable fails to:  │  │ Unplanned situation:   │
│ • Baselined scope      │  │ • Meet quality criteria│  │ • Resource loss        │
│ • Target Operating Mod.│  │ • Satisfy requirements │  │ • Supplier dispute     │
│ • Contracts / Costs    │  │ • Pass acceptance tests│  │ • Technical blocker    │
└────────────────────────┘  └────────────────────────┘  └────────────────────────┘

1. Request for Change (RFC)

A Request for Change is an issue raised when a stakeholder proposes an alteration to an approved baseline—such as extending the Target Operating Model, modifying a project's agreed deliverables, altering quality criteria, or changing contract specifications.

• Example: The Human Resources department requests that the new enterprise payroll system incorporate multi-currency capabilities to support recently acquired overseas subsidiaries, altering the baselined project scope.

2. Off-Specification

An Off-Specification occurs when an item or deliverable has been produced (or is currently being produced) that does not meet its agreed specifications, acceptance criteria, or quality standards, and cannot be readily corrected within normal working tolerances.

• Example: An electric bus manufacturer delivers 50 municipal transit vehicles whose battery range reaches only 160 kilometers in cold weather, failing the contractually mandated specification of 220 kilometers.

3. Problem or Concern

A Problem or Concern is any unanticipated event, operational blocker, stakeholder conflict, or external obstacle that is currently impairing progress and requires management intervention.

• Example: A primary cloud infrastructure data center suffers a major physical fiber cut, halting end-to-end integration testing for all projects for five consecutive days.

---

The Issue Owner

Every issue on the issue register has a named issue owner: the individual accountable for the issue being investigated, resolved or escalated, and formally closed. The role mirrors the risk owner in the risk response approach, and the same discipline applies — an issue without a named owner is an issue that nobody is managing.

The issue owner is chosen for authority over the affected area, not for availability. An issue whose resolution requires changing an operational process should be owned by the business change manager; one requiring re-sequencing of projects should be owned by the programme manager; one that threatens the business case should be owned by the SRO.

[!CAUTION] Common trap — owner versus actionee: Distractors frequently swap the two. The owner is accountable for the issue reaching a resolution; the actionee performs specific tasks. Assigning the work does not transfer the accountability.

---

Issue Escalation Pathways and Decision Thresholds

Not every issue should be escalated to executive leadership. Managing large programmes requires delegated governance and management by exception.

┌─────────────────────────────────────────────────────────────────────────────┐
│                     SPONSORING GROUP (Executive Level)                      │
│ Issues that alter corporate vision, breach total funding, or damage brand. │
└──────────────────────────────────────▲──────────────────────────────────────┘
                                       │ Escalation
┌──────────────────────────────────────┴──────────────────────────────────────┐
│              SENIOR RESPONSIBLE OWNER (SRO) & PROGRAMME BOARD                │
│ Issues that breach programme tolerances (cost, schedule, Target Operating   │
│ Model scope) or alter the Programme Business Case.                          │
└──────────────────────────────────────▲──────────────────────────────────────┘
                                       │ Escalation
┌──────────────────────────────────────┴──────────────────────────────────────┐
│                   PROGRAMME MANAGER (Programme Level)                       │
│ Cross-project friction, inter-project dependencies, resource contention,     │
│ within agreed programme tolerances.                                         │
└──────────────────────────────────────▲──────────────────────────────────────┘
                                       │ Exception Report
┌──────────────────────────────────────┴──────────────────────────────────────┐
│                    PROJECT MANAGERS (Delivery Level)                        │
│ Day-to-day technical issues resolved within agreed project stage tolerances. │
└─────────────────────────────────────────────────────────────────────────────┘

The Hierarchy of Escalation

1. Project-Level Resolution: Project Managers resolve local issues (e.g., minor bugs, internal sprint tasks) using delegated project tolerances. If an issue threatens to breach project tolerances (time, cost, scope, quality), the Project Manager submits an Exception Report to the Programme Manager.
2. Programme-Level Resolution: The Programme Manager assesses the issue against the baselined Delivery Plan. If the issue can be resolved within programme tolerances (e.g., leveling resources between two projects, shifting non-critical tasks), the Programme Manager directs resolution.
3. SRO & Programme Board Escalation: If the issue breaches programme tolerances, threatens critical path milestones, requires drawing upon programme contingency budgets, or involves accepting an off-specification that alters the Target Operating Model, the Programme Manager escalates it to the Senior Responsible Owner (SRO).
4. Sponsoring Group Escalation: If an issue threatens the strategic viability of the transformation, requires an increase in the overarching programme capital envelope, or demands fundamental policy changes, the SRO escalates the dilemma to the Sponsoring Group.

---

Maintaining the Issue Register and Decision Register

To ensure complete accountability and auditability, MSP maintains two crucial logs: the Issue Register and the Decision Register.

1. The Issue Register

The Issue Register acts as the live tracking repository for all formal issues raised across the programme. For each issue, it captures:

• Issue ID & Title: Unique identifier and concise description.
• Issue Category: Request for Change (RFC), Off-specification, or Problem/Concern.
• Date Raised & Originator: Who identified the issue and when.
• Impact Analysis: Quantitative and qualitative evaluation of consequences across cost, time, capability, and benefits.
• Severity & Priority: Criticality rating (e.g., Low, Medium, High, Urgent).
• Issue Owner: The designated individual accountable for steering the resolution.
• Current Status: Open, Under Evaluation, Escalated, Approved, Rejected, Resolved, Closed.

2. The Decision Register

While the Issue Register tracks problems and their operational progress, the Decision Register captures the formal governance choices made by leadership.

[!IMPORTANT] Why Maintain a Decision Register? Large programmes span multiple years and experience frequent turnover among executive sponsors, Programme Managers, and suppliers. Without a formal Decision Register, programmes suffer from decision churn—re-debating settled questions, losing the rationale behind technical compromises, or facing severe audit vulnerabilities. The Decision Register provides an immutable, transparent record of transformational governance.

Key Fields in a Decision Register

                                  DECISION REGISTER ENTRY
┌─────────────────────────────────────────────────────────────────────────────┐
│ DECISION ID        : DEC-2026-042                                           │
│ RELATED ISSUE/RISK : ISS-089 (Off-Specification: Data Center Storage Latency)│
│ DATE OF DECISION   : 14 October 2026                                        │
│ DECISION TITLE     : Approval of Hybrid Cloud Storage Architecture          │
├─────────────────────────────────────────────────────────────────────────────┤
│ DILEMMA / CONTEXT  : On-premises SAN storage failed performance benchmarks  │
│                      for real-time analytics. Full replacement costs €1.2M. │
│ OPTIONS CONSIDERED : Option 1: Buy new SAN hardware (+€1.2M, 16-wk delay)   │
│                      Option 2: Hybrid cloud caching (+€350k, 2-wk delay)     │
│                      Option 3: Accept degraded performance (Zero cost)      │
│ DECISION & RATIONALE: Approved Option 2. Delivers required 12ms latency     │
│                      within existing tranche contingency and avoids delay.  │
│ DECISION AUTHORITY : Senior Responsible Owner (SRO) with Lead Architect     │
│ STAKEHOLDERS CONS. : Head of Data Governance, Finance Controller, Lead Vendor│
│ REVIEW / AUDIT DATE: End-of-Tranche 2 Review Gate (December 2026)           │
└─────────────────────────────────────────────────────────────────────────────┘

---

Real-World Organizational Transformation Scenario

Logistics Fleet Decarbonization Programme

Context: A national postal operator initiated a five-year, €450 million programme to transition 12,000 diesel delivery vans to an all-electric fleet supported by depot charging hubs.

Application of Issue Management & Decision Recording:

• The Issue: During Tranche 2, the primary municipal power utility informed the programme that grid capacity upgrades for four central distribution depots would be delayed by nine months due to transformer supply shortages.
• Categorization: The Programme Manager classified this event as a Problem/Concern (ISS-104) with a severity of "High", as it directly blocked the deployment of 2,500 new electric vehicles.
• Escalation: Because the nine-month delay exceeded the programme's baselined four-week schedule tolerance and threatened the business case's carbon reduction benefits, the Programme Manager submitted an Exception Report escalating the issue to the Senior Responsible Owner (SRO).
• The Decision: The SRO convened the Programme Board and evaluated three options: (A) pause vehicle delivery and pay supplier holding fees, (B) deploy mobile battery energy storage systems (BESS) at depots as a temporary bridge, or (C) reallocate vehicles to regional depots with existing grid capacity. The SRO selected Option B and C combined.
• Decision Registration: The PMO formally logged DEC-2026-088 in the Decision Register, recording the selected bridge solution, the €480,000 contingency drawdown authorized by the SRO, the stakeholder consultation with municipal regulators, and the scheduled review date at the next tranche gate.

Outcome: When Corporate Internal Audit conducted a review six months later, the Decision Register provided complete transparency regarding why contingency funds had been drawn down and prevented contentious re-litigation among board members.

---

Exam Tips & Common Traps

• Exam Tip (Risk vs. Issue Determinant): If an exam question describes an event that has occurred, is occurring, or is 100% certain to happen, it is always an issue, never a risk. If it describes an event that may or may not happen in the future, it is a risk.
• Exam Tip (RFC Classification): Remember that a Request for Change (RFC) is handled as an issue under MSP governance. It is logged in the Issue Register, evaluated for impact, and routed through delegated change control authority.
• Common Trap (Decision Authority Limits): Watch out for questions suggesting that the Programme Manager can approve an issue resolution that breaches the Programme Business Case. The Programme Manager can only resolve issues within delegated programme tolerances; any decision altering the Business Case or total capital envelope requires the Senior Responsible Owner (SRO) or Sponsoring Group.
• Common Trap (Decision Register as Minutes): A common distractor characterizes the Decision Register as an informal compilation of meeting minutes. In MSP, the Decision Register is a formal, baselined governance artifact providing an audit trail for executive choices.