3 Escalation Paths and Issue Resolution

Purpose of escalation

Escalation is the planned transfer of a matter to someone with the authority or capacity to address it. A sound process resolves matters at the lowest appropriate level while preventing decisions and problems from lingering beyond their tolerances. Governance arrangements should make decision rights, routes, and thresholds clear in advance.

Distinguish the matter being escalated

Risks, issues, conflicts, and decisions need related but distinct responses. A risk is uncertain and may affect project objectives; an issue has already occurred and needs action. A risk may become an issue when it occurs, so keep the records linked where useful and make clear who owns each response.

Escalate a risk when its exposure exceeds agreed tolerance, crosses project boundaries, or cannot be managed with the current owner's authority or resources. Escalate an issue when it threatens objectives, remains unresolved past an agreed deadline, or requires authority the current owner lacks.

A conflict concerns disagreement over priorities, resources, requirements, or accountability. First seek resolution between the accountable parties; escalate if they cannot agree, a shared resource or dependency is affected, or the dispute threatens delivery.

A decision must be made by someone with relevant delegated authority. Escalate when the choice exceeds that authority, such as when it changes approved scope, funding, or commitments, or when delay itself threatens delivery.

Design the escalation path

Define escalation routes and decision rights in project governance arrangements, such as the governance plan, decision log, and board terms of reference. A practical route usually moves through the following levels:

1. Work owner or specialist: Identify and assess the matter, act within assigned authority, and alert the project manager when help or a decision is needed.

2. Project manager: Coordinate analysis and response, resolve matters within project tolerances, assign owners, and escalate matters beyond those limits.

3. Sponsor or project board: Decide or secure action on matters outside the project manager's authority, including significant trade-offs, cross-functional support, or changes to approved commitments.

4. Programme, portfolio, or organizational authority: Address cross-project effects, enterprise-level priorities, or decisions reserved to higher governance bodies.

Roles and routes vary by organization. Name the accountable decision-maker for each decision type and identify a substitute or alternate route if that person is unavailable. Specify when specialist functions, such as legal, finance, security, safety, or human resources, must be involved.

Set thresholds and response expectations

Set thresholds against the approved plan and delegated authorities. Define measurable limits for relevant dimensions, which may include cost, schedule, scope, quality, benefits, safety, compliance, and reputation. Examples of matters that may exceed a threshold include:

• A forecast variance beyond the project manager's delegated cost or schedule tolerance.

• A proposed change to a baseline, outcome, or contractual commitment.

• A risk that cannot be controlled with the resources or authority available at the current level.

• An issue unresolved after its agreed response date, or one that blocks a critical milestone.

• A resource or priority conflict affecting more than one team or project.

Specify how quickly a matter must be acknowledged, assessed, escalated, and decided. For example, a project might require immediate notification for a safety threat, same-day escalation for a critical delivery blocker, and review at the next governance meeting for a lower-impact matter. These are illustrative service expectations, not universal standards; timelines should suit the project's risk, operating context, and governance cadence. Do not wait for a scheduled meeting when delay could increase harm or reduce available options.

Some events need an immediate route outside the normal chain, including an urgent safety, security, or legal concern, or suspected misconduct. Define the relevant emergency, incident, or protected-reporting channel and ensure staff know how to use it.

Make escalation actionable

Make an escalation concise and oriented toward a decision. Include what happened or may happen and when; the affected objectives, dependencies, and likely impact; actions already taken, the current owner, and any response deadline; options, trade-offs, and a recommended course of action; and the specific decision or support required, who can provide it, and by when.

The receiving authority should acknowledge the escalation, assign a decision owner, determine whether more analysis is needed, and communicate a decision or next step within the agreed response time. Record the decision, rationale, conditions, actions, and owners. Communicate the outcome to affected parties and update relevant risk, issue, change, and decision logs. If the authority declines the escalation or returns it to a lower level, record that disposition and confirm who retains accountability.

Apply the process and close the loop

A supplier delay may push a key milestone beyond the schedule tolerance delegated to the project manager. The project manager records the issue, assesses its effect on later work, and considers recovery options. If no option can restore the milestone within delegated authority, the manager escalates to the sponsor or board with a recommendation and decision deadline. The authorized body chooses a recovery option or approves a change to the plan; the project manager records and communicates the decision, assigns actions, and monitors the result.

Clear decision rights, named routes, measurable tolerances, and response times help make escalation effective. Escalate promptly when thresholds are exceeded, resolution stalls, or delay increases risk; assign an accountable decision-maker, record the outcome, and close the loop with affected people.