One team escalates every delay. Another waits until a deadline is impossible. Both may be working without a shared threshold for when an issue exceeds the authority or capacity of the people handling it.
An escalation threshold is an agreement about when to bring an issue to a specified decision-maker. It should connect to consequences and responsibilities, rather than relying only on a red status colour.
Start with the project’s real limits: spending authority, delivery commitments, service impact, compliance requirements and dependencies on other teams. Identify which decisions the team can make itself and which require someone else. Keep legal or regulated obligations under the organisation’s appropriate professional process.
For a practical planning exercise, take a hypothetical supplier delay. A two-day slip may be manageable within spare time. The same slip may need immediate escalation if it blocks a fixed public launch. Duration alone does not describe the consequence.
- State the trigger in observable terms.
- Name the decision-maker or role, including cover for absence.
- Specify the information needed: impact, options and the decision deadline.
- Agree how the team will know the issue has been received.
Write a short example of an escalation message before the project is under pressure. It might identify the blocked milestone, two feasible responses and the date by which a choice is needed. Sending an entire message history without a clear request transfers the sorting work rather than the decision.
Review the threshold after using it. If every minor issue qualifies, the criteria may be too broad. If serious effects remain hidden until late, the triggers or reporting route may need improvement.
Escalation should make authority available where it is needed. It works best when people can raise an issue early without having to dramatise it, and when the recipient understands exactly what decision would help.