ITIL Escalation Definition
Coworkers and colleagues might remember one of my phrases: “Escalate early, Escalate often”.
Today I got to use it anew and explain it to my current group of coworkers and colleagues.
Escalation
In short, escalation gets you needed resources when you’re having troubles meeting your customer’s expectations.
Examples:
- You said you’d be done by midnight and it’s now 10:30 and your change isn’t going so well.
- You find that this modified workload is asking for more RAM than you have authority to allocate.
- A new switch arrived and you just cannot figure out how VLANs work on it.
Escalation is a valid response for each of those cases. There are two basic types identified by ITIL.
Functional Escalation
This type of escalation asks for a higher level of expertise than what you currently have when dealing with an incident, problem or change. Calling Dell’s Pro support group for help with VLANs and that new switch is a good example. Another is walking across the aisle to ask your Linux colleague how to find and comment out a cron1 job. When you need a bit more knowledge or experience and you’ve exhausted your notes and the man2 pages, that would be a good time to escalate functionally.
Hierarchic Escalation
The other type of escalation asks for a higher level of management. Maybe you need access to a different level of communications or the incident is wide-spread enough that a different organization structure is impacted. Or perhaps you need additional authority to allocate more than the standard amount of RAM.
Maybe you can use the higher management level to run interference with another group. Or maybe you need that higher-level manager to ask for a resource from a different team (Functional and Hierarchic Escalation!).
Why Early?
In my experience, technologists tend to be an optimistic bunch. I’ve often heard that it will “only take a few more minutes” to resolve some incident being worked on. Half an hour later, it’s still being worked on.3 By that point, any benefit from using available redundancy or alerting your downstream might be useless and client impact might be that much worse. Escalate early4 to bring on the additional resource (or authority) to assist in your issue.
Why Often?
Well, partly because it sounds cool: it rounds out the phrase. But mostly because by escalating often, you give your management those updates needed to keep the incident managers at bay.5 It also serves as a checkpoint for evaluating the need for additional functional or hierarchic resources. Two brains are good for this—one tends to temper the other.
So whether you need additional authority or expertise, escalate early and escalate often. If you’re not already doing this, talk it over with your management, try it a few times and let me know how it works out for you!
For additional detail, check out the Service Operation Book (ITIL)
