In many organizations, escalation is treated as a failure. Teams hold problems until they are certain they cannot solve them, and by then the options have narrowed. Leaders hear about issues late and conclude they need more oversight, which makes teams more cautious about escalating the next time.
Escalation thresholds break that cycle. They define in advance which conditions move an issue to the next level, who receives it, and how quickly a decision is due. When the conditions are agreed beforehand, raising an issue is following the plan rather than admitting a problem.
The four elements of a threshold
- Trigger. A measurable condition, such as a schedule variance, a cost variance, a risk rating, or a missed dependency.
- Level. Who receives the escalation: workstream lead, program lead, steering committee, or executive sponsor.
- Response time. How quickly the receiving level must respond with a decision or a direction.
- Record. Where the escalation and its resolution are logged, so patterns are visible over time.
A starting table
The values below are a starting point for a mid-sized program. Calibrate them to the program's size, risk, and contract terms before adopting them.
| Condition | Workstream lead | Program lead | Steering committee |
|---|---|---|---|
| Schedule | A task slips within the milestone's float | A milestone moves by up to two weeks | A milestone moves by more than two weeks, or the end date is at risk |
| Cost | Variance within the workstream's contingency | Variance up to 5 percent of the program budget | Variance above 5 percent, or contingency exhausted |
| Scope | A clarification within the approved requirement | A change that affects another workstream | A change to the outcome, benefits, or contract terms |
| Risk | Medium risks with a mitigation in place | High risks, or any risk without an owner | Risks that threaten the outcome or require funding |
| Response time | Two business days | Five business days | The next meeting, or ten business days if that is sooner |
How to set them
- Start from decision rights. A threshold should route an issue to the level that holds the authority to resolve it. If that level is unclear, settle decision rights first. The Decision Rights Map is built for that exercise.
- Use measures the program already tracks. Thresholds built on data nobody reports will not be used.
- Agree them with the sponsor. The steering committee should approve the table, so escalations arrive as expected business rather than surprises.
- Review after the first quarter. If nothing has escalated, the thresholds are probably too loose. If the committee is flooded, they are too tight.
An escalation that arrives early, against an agreed threshold, is a program working as designed.
Making escalation routine
Thresholds only work if escalating is safe. The receiving level should respond within the agreed time, with a decision or a direction, and without treating the escalation as a performance problem. Log each escalation and its resolution. Over a few quarters, the log shows where the program's real constraints are, which tells leadership more than any status report.