Ideas for Incident Management

In advanced organizations, an on-duty pager is usually defined.

The manager of each technology group is responsible for preparing the call handling schedule for such a pager and ensuring that calls are serviced at all times. In addition, a hierarchical (managerial) escalation procedure must be defined for each technology group. Typically, the line manager of the third level group is the first leader in the escalation.

Hierarchical escalation

Hierarchical escalation involves management in order to ensure that the incident is given the appropriate priority and the necessary resources are allocated before the resolution time frame is exceeded. Hierarchical escalation can be performed at any support level. In Table 4, hierarchical escalation occurs in the third escalation step for issues of all severity levels.

In advanced organizations, escalation to management occurs automatically according to a predefined procedure based on the severity of the problem. Once an escalation has occurred, the appropriate manager is expected to actively manage problem resolution and become the single point of contact for status messages.


Statistical reports in advanced organizations are used to monitor, continuously improve the process and analyze whether performance indicators are meeting the level of service agreed with customers.

To control incident management and problem management processes, for example, reports containing the values ​​of the following parameters can be used:

The number of incident cards currently open by severity level, time spent, responsibility groups
Number of problem cards currently open (for which the cause has not yet been identified)
Such reports allow managers to make decisions about the allocation of resources, the direction of staff efforts. Regular use of type parameters:

Average processing time for cards at each level

The number of cards submitted and resolved at each level can help identify weaknesses in the IT infrastructure
Finally, a vital set of reports, such as:

Percentage of incidents resolved within the given time frame
Average time to recovery of service, allows IT organizations to interact with their customers and correlate the achieved level of performance with the target level of service


The development of incident management processes and procedures is carried out by many organizations, but not all of these organizations do the same for problem management. Often this is due to a lack of understanding of the characteristics of these two activities. Incident management is the easiest activity to understand because it simply creates a mechanism for responding to service interruptions. Because “the squeaky wheel will always be greased,” incident management is moving along fairly quickly. However, there is often less reason to develop problem management.

Problem management is much like managing a portfolio of projects, the purpose of each of which is to identify the causes of a problem. Incidents are often the first indicator of a problem and once faced with an incident, an organization must have a process and procedures in place to find out the cause.

Continuing with the project portfolio analogy

a problem management organization must develop a criteria for identifying the problems that should be investigated to determine the causes, in much the same way as it does with the criteria for deciding whether to select a new project. Issues that are not being investigated continue to be monitored for future research. Once the cause is found and a solution is developed, the organization tracks progress towards implementing the solution.