In the grand theatre of project delivery, issues arrive uninvited—sometimes quietly, sometimes with the force of a storm. PRINCE2 doesn’t attempt to eliminate them (that would be naïve); instead, it gives us a disciplined framework to control, contain, and convert issues into informed decisions.
Issue Management isn’t an optional activity in PRINCE2.
It is the heartbeat that keeps project governance alive.
This article breaks down the essentials: how issues flow, when to escalate, and how smart workarounds keep momentum moving—all while staying within the PRINCE2 boundaries.
The PRINCE2 View of an “Issue”
PRINCE2 is elegantly simple:
Anything that happens in a project and requires a decision or action becomes an Issue.
It can be:
- A request for change
- An off-specification
- A general problem or concern
- A deviation that threatens time, cost, scope, quality, benefits, or risk
PRINCE2 doesn't leave room for ambiguity. Issues get logged, evaluated, escalated (if needed), and resolved with structured governance.
- Escalation Paths in PRINCE2: Who Decides What?
PRINCE2 thrives on clear decision-making layers.
Escalation is not bureaucracy—it's precision in authority.
- Team Level → Project Manager
If the team cannot resolve something within the agreed Work Package:
- Clarify requirement issues
- Quality problems
- Minor delays
- Small rework needs
These go straight to the Project Manager.
- Project Manager → Project Board
When an issue threatens tolerances—that invisible line the PM must not cross—PRINCE2 demands escalation.
Escalate when:
- Stage cost exceeds tolerance
- Delivery is slipping beyond acceptable dates
- Quality tolerances are breached
- Significant scope deviation appears
- Business Case integrity is shaken
The PM informs the Board via:
- Exception Report
- Issue Report (if needed)
The Project Board then decides:
- Approve change
- Modify tolerances
- Trigger exception stage
- Halt project
- Continue with mitigation
Escalation is governance—not panic.
