Issue Escalation Process

An issue escalation process defines how an unresolved event, dispute or decision moves from a program component to program leadership and, when necessary, to executive governance. It protects delivery by matching each issue with the right authority, urgency and evidence.

When to use it

• Establish the process before program execution and use it whenever an issue exceeds delegated authority, tolerance, resources or cross-component scope.
• Communicate clear thresholds so escalation is timely rather than personal or political.
• Adapt the pattern to the program’s governance, regulatory exposure and benefits model.

Context

This artifact supports program governance and should be integrated with the issues register, change control, risk management, communications plan, decision log and governance calendar. Emergency safety, legal or regulatory events may require immediate routes outside the normal sequence.

What it is

Issue Escalation Process

The approach reflects the governance discussion associated with section 4.9 of the Standard for Program Management—Third Edition (2013) and the governance-domain reference 6.2.4.9 in that edition (2013). Current programs should map the process to the edition, policies and authorities that actually apply.

Purpose

Resolve issues at the lowest competent level while escalating promptly when impact, urgency, authority or cross-program consequences require a governance decision.

1. Create the program issues register at initiation. Give each issue a unique identifier, link it to the program work breakdown structure and migrate known charter, mandate and business-case issues into the governed register.
2. Determine whether the issue requires a formal change request. If it does, assign preparation to the person closest to the evidence with change-control support.
3. Assess priority, urgency, impact and escalation threshold. Name one accountable issue owner and one register custodian.
4. Decide whether structured analysis or a feasibility study is needed. Define scope, owner, deadline, cost and the decision it must inform.
5. Notify the Governance Board immediately when tolerance may be breached or a special meeting could be required; otherwise include the issue in routine reporting.
6. Check the program manager’s delegated authority. Possible responses include acceptance, corrective action or an approved change to program plans and baselines.
7. Identify affected stakeholders and engage them proportionately. Update the stakeholder register and protect confidential or sensitive information.
8. Escalate when the program manager lacks authority, cannot resolve the issue, or when consequences extend to other programs or the organisation.
9. Present the board with a concise decision paper: facts, impact, options, recommendation, urgency, stakeholder implications and requested decision. Record and communicate the decision and rationale.
10. Implement corrective action and determine whether preventive action, control improvement or a risk update is also required.
11. Capture the issue, analysis, decision and outcome in the lessons-learned register.
12. Confirm closure and completed actions at the next appropriate Governance Board meeting; share transferable learning with relevant programs.
13. Report closure to authorised stakeholders at the level of detail appropriate to their role, privacy and information needs.
14. Include residual ownership and post-closure support in transition plans so a comparable issue has a clear route after program completion.

Minimum fields

• Issue ID
• Description
• Evidence
• Date raised
• Owner
• Priority
• Impact
• Threshold
• Affected benefits and components
• Options
• Requested decision
• Authority
• Due date
• Decision and rationale
• Actions
• Status
• Closure evidence
• Lessons and residual owner