SLA philosophy: what is escalation and why is it needed?

In my article “How to write a good SLA” , I mentioned that the SLA simply asks for an escalation procedure. I want to say a few words for the escalation .

Escalation in IT, in my opinion, very few people understand. In ITIL, it is somehow dull defined. Accordingly, and further, when trying to implement it, the degree of turbidity is only increasing. Neither Google nor Yandex help to find anything intelligible. Instead of explaining the escalation simply and clearly (as I do), the authors begin to introduce some new terms, indicate what is the difference between functional and hierarchical escalation (why is this?), Broadcast something about automatic escalation, nothing without explaining and leading away. And at the same time, from the context, it can be assumed that escalation is either a synonym for sending a request to another executor, or to another division, or attracting additional resources, or increasing priority. And sometimes I just get lost in understanding the meaning. All this makes me personally feel or “twist-twist, I want to cheat,” or banal incompetence.

Especially nice (I can not help but give this example) looks like an automatic "escalation" of a request to another level of support, if (sic!) The current performer does not have time in the time specified in the SLA. That is, as a performer, we accept the request and hold out with all our might, we do nothing on it until it is almost expired, and ... bang! - Automatic "escalation" is triggered, which reassigns the request to someone else. Profit! .. The main thing is to control yourself and do nothing. It would be possible to laugh heartily, but in some places it is precisely this kind of “escalation” scheme that is used, posing as the best IT practices!

So what is escalation, who needs it and why? Now I will tell you my understanding, after which you, I hope, will love the escalation as well as me. Hold tight to the chair.

First, I debunk the above, why it is not an escalation.

Escalation is not a reassignment request. At least for the simple reason that reassigning a request to another executor is called "reassigning a request to another executor." Not an escalation. In general, to reassign the request, if the contractor has already begun work, it is absolutely impossible. The only correct way to send a request, which I know, is when a new contractor takes the request to himself voluntarily, and only after the prior consent of the current contractor. Because I took (gave) the request - decide to the bitter end. Yes, and rake the consequences "for the guy" after the reassignment - then another pleasure. The event is more force majeure than ordinary. Moreover, no automatic reassignment. Otherwise, performers will run from work.

Also, escalation is not an increase in priority. Because even a person who is not in control of the situation (but in possession of logic) immediately has a question: how then to escalate requests of the highest priority? And, if we have only four priorities in numbers from 1 to 4, then we can escalate a maximum of three times, changing the priority from 4 to 3, from 3 to 2 and from 2 to 1 and that's it, right? It looks suspicious and illogical. And then, if the performer does not respond to us on the third priority from vacation, then why does he suddenly start on the second?

And then what is escalation? Definition:

Escalation is a procedure for drawing attention to a separate query when the process of working on a query does not suit something.

That's it, and not otherwise. To draw attention. The naked eye can see a connection with an increase in priority - a suddenly increased priority, like other such absurd actions, will attract attention, so this behavior partly looks like escalation. But only if the performer did not go on vacation. Well, do not forget that the absurd actions of one side, the other can respond symmetrically. To your every question, so to speak, is our arbitrary answer. So it is more correct to understand the escalation precisely as attracting attention. And there already a competent person will figure out whether to raise the priority, whether to attract additional expertise or simply to give the performer the necessary acceleration, up to a complete change of its composition. That is, with the previous attempts to determine the escalation of this definition is consistent.

But this definition is already better, because it allows you to escalate requests as many times as necessary, regardless of the finite number of priorities and levels of support.

Go ahead. Every escalation must have a reason . In other words, something is wrong with the request, for some reason it took to draw attention to it. This reason the initiator is obliged to indicate during escalation. Without a reason for escalation does not happen. Here are typical examples of reasons for escalation:

• dissatisfaction with the progress of work, it is required to indicate what exactly (example: on a critical issue no action was taken in a week)
• new essential circumstances of the problem being solved have emerged: the terms, volume and other characteristics of the problem being solved have changed, which translate the problem into a new quality (example: not one record in the database is damaged, but many records)
• one of the VIPs is involved (example: the department director took the decision under personal control)
• other significant circumstances.

If the reason for the escalation is time, then it is necessary to specify and clearly state why this time is important, and what happens if the time limit is violated.

The reason for the escalation is not:

• the user escalated the request (and where is the reason?)
• I want a solution right now (why not yesterday? or tomorrow?)
• escalated (by whom and for what reason?)

and other similar meaningless phrases.

If the initiator did not indicate a clear reason for escalation, then the first question in the analysis of escalation should be exactly the request to indicate the reason. Well, everyone has it, a worried person missed an important one. I mean it, escalations are often done under harsh stress conditions. But if the reason is not specified, then the escalation should be closed, because there is no reason for the escalation. If it is not possible to formulate a coherent reason for escalation, then this is a good reason to think, maybe you really shouldn't escalate anything?

The reason for the escalation is usually described in a non- technical language, you need to state where and how the problem interferes with the business. This is the so-called business reason. Agree that a minor technical problem can actually cause a lot of trouble for a business and vice versa. Compare:

• tech. , Several records in the GL_JE_LINES table are damaged, you need to fix it until the 20th day of the month.
• business , Postings to the Civil Code were damaged, it is impossible to close the period and provide accounting and tax reports, enter transactions of the next period, from the 20th day the Tax will begin to charge penalties and fines.

The first reason will be understandable only to a narrow circle of technical specialists (and often only after a long analysis), the second one tells everyone that the whole business has already risen, and soon it will also get money.

To give a clear reason for the escalation is an excellent filter that will miss all cases when you really need to, and cut off most of the inadequate.

What should happen after someone escalated the request. Need to consider escalation. There should appear the executor of the request or someone more competent (especially if the cause of the escalation is the actions of the performer himself) and clearly respond. Generally speaking, “intelligibly respond” means the following: analyze the current situation with the request in the light of the cause of the escalation and offer the initiator a plan of further actions that will suit both parties and eliminate the cause of the escalation. Further act on this plan. Consideration of escalation should be operational, inevitable and quality. There can not be tinker.

By the way, the initiator of the request may not necessarily escalate, sometimes essential information may come from someone else. Also for completeness, I note that the escalation does not necessarily lead to an increase in priority or replacement of the contractor, but rather usually does not. Priority is adjusted only when necessary, if previously missed or circumstances have changed. It may also turn out that the whole action plan will be “continue further in the same mode” if the escalation was not in the case, or it may turn out that as part of the escalation, the priority will be lowered. Of course, priorities have to be raised during escalations more often, this action requires speed and, possibly, other adjustments in the work on the request, and the priority can be reduced by staffing. The main thing in escalation is that attention was drawn and entailed actions to eliminate the cause of the escalation and restore order. Consideration of escalation also often acts as an arbitration on a project if the initiator and the performer cannot agree. The initiator sometimes wants a strange, and sometimes impossible.

And here we are already smoothly approaching the question, why do we need escalation at all?

With the initiator is more or less clear. The initiator of the request is an opportunity to express their displeasure and disagreement, as well as solve any abnormal situation. This is in good agreement with the intuitive understanding of the word "escalation", which allows the use of escalations, including ordinary users of IT-systems, they are quite competent and can use the escalation in time without even reading any regulations and instructions.

But why the escalation of the performer? And whether? Performers often do not understand this, and therefore do not like escalation. And in vain.

At first glance, the situation seems to be asymmetric. For the initiator, this is an opportunity to knock the fist on the table, and to squabble, but for some reason the performer must jump and react to it. And bounce quickly and respond adequately. Is there anything else for him to do?

Let's see what happens if the escalation does not exist. If the initiator has a reason for dissatisfaction, he will wait, wait, wait until patience breaks. And then we have a scandal, swearing, blood gut complaints about everything that can be recalled to the third generation, involvement of the authorities, stresses, nerves and other industrial horrors. And if at the same time there is indeed a reason for discontent, and in the past there were flaws (as is often the case for nobody's perfect), then it will not seem like much to anyone. In addition, during such fights, it becomes very difficult to return to constructive actions on the request itself. The initiator is not ready to cooperate, does not want to compromise and to sacrifice anything, the decision is required right now and in the best possible way, on a silver platter. And the problem is usually nontrivial, for the sake of the trivial high would not rise. Smash such scandals oh how difficult.

Now consider what will happen in the same situation, if there is a well-tuned and well-functioning mechanism of escalation. The initiator, instead of enduring to the last, will escalate the request as soon as he realizes that something is going wrong. The reason for the escalation will be studied, the situation considered, the necessary actions are planned. Work will not be less, it is a fact, but it will remain in normal mode, and the interaction will remain constructive. If the plan is not good, then another escalation is likely to follow, that is, mistakes are unpleasant, but not fatal. Chance to correct will be the maximum. And even if the initiator, for whatever reason, did not take advantage of the escalation, instead of all the horror from the previous paragraph, the situation would be destroyed by one question to the initiator himself (and, possibly, to his head): “why didn’t you escalate it?”

And so it turns out that the working mechanism of escalation allows the contractor to avoid complaints about his work. And qualitatively and systematically. I will repeat it again for better memorization and even take it in a frame:

A working escalation mechanism allows the contractor to avoid complaints about his work.

Few? During escalation, the initiators themselves show which requests to pay particular attention to the performer . And in advance, before it exploded, and at the very moment when they themselves are ready to work constructively for their part. Themselves. In advance. Constructively. Just a holiday of some kind.

Still not enough? The project manager (division, department, group) participating in escalations gives an understanding of the current situation on the project and invaluable information for evaluating the work of subordinates . It is in those circumstances where the quality of work of the performers manifest themselves most clearly. And the head knows all the current potentially conflicting requests. Known at the level at which he himself participates in escalations.

So it turns out that in fact the executor of the mechanism of escalations is almost more necessary than the initiator. In my opinion, for the sake of this, it is worthwhile to suffer with the prompt and high-quality consideration of escalations.

Still not escalating? In vain ...

PS Changed the title of the article to more understandable