Who closes the Major Incident

By ITIL® from Experience©

At first glance using “whoever logged it closes it” makes sense. It works well when the Service Desk opens the Major Incident and it aligns with ITIL®1 . However, when another group opens a Major Incident and closes it, “whoever logged it closes it”can create issues.

Let’s take the example where IT Operations Control2 logs a Major Incident after hours for a network storage issue. They resolve the issue within the hour and close the Major Incident. The next morning, another Major Incident is logged as users are reporting that a key application is not working. The Application Group trouble-shoot the issue. If they would have known about the issue from the night before, they would have simply performed their usual procedure and restored the service (e.g. restart the web service). Thus, a little bit of communication would have avoided the Application Group and the Service Desk from wasting effort as well as reduced, or even eliminated unnecessary impact to the business. It is true that if people would have looked at the ITSM Tool they would have seen the network incident, however, it is a reactive approach and time is wasted. More over, not every organization has a Configuration Management Database (CMDB) that enables them to easily understand the impact across its environment.

To prevent such a situation, a simple conversation, by cell phone or text message, between the following individuals ensures that they are aware of the situation and agree that the Major Incident can be closed.

1. The User or the IT staff who opened the incident in order to confirm that the issue has been resolved.
2. The individual(s) who addressed the fault or resolved the incident.
3. A senior member of the Service Desk (the Service Desk Manager is not necessarily the right person since he or she must be able to understand the impact of technical details on users).
4. Other IT specialist(s) responsible for Configuration Items impacted by the incident.

Including the Service Desk in the closure-decision ensures that the fix is viable from a User perspective. For example, if the fix involves modifying a registry setting on all Microsoft Windows workstations, it is not feasible to ask Users to perform this manually or for the Service Desk to guide Users to do so. An acceptable customer-focused solution is to deploy a reg file3 to apply the fix.

That being said, some I.T. groups will object to waiting for this "committee to decide" to close the Major Incident as it introduces delays that affects their Service Level Management metrics (i.e. SLA, OLA).

Using a two-step procedure to close the Major Incident addresses this concern. The first step is to take an Action in the ITSM Tool to change the status of the Major Incident to “Resolved”4 and to stop the SLA clock. The second step is to record the completion of the service’s recovery by closing5 the Major Incident. The additional benefit is that two metrics are now available: 1) how long it took the technician to fix the issue and, 2) the duration of the impact to the business.

Caution should be used not to keep the Major Incident record open to manage and track the improvement activities (see Should project activities be logged and tracked in the ITSM Tool). Another element to be mindful of is that many people, like the Service Desk Manager, the Service Owner, Service Level Manager or even the Chief Information Officer (CIO) may want to participate to the closure decision. Although they are all important stakeholders, they do not need to be part of the technical discussion and decision to close the Major Incident. The Major Incident Closure procedure can include a specific communication task to inform stakeholders.

Key individuals should be involved in closing the Major Incident to ensure that people are aware of the issue so that they can address impacts.

Related:

• Should the incident be closed as soon as the RFC is logged
• Should a Major Incident be declared if it was resolved automatically by the fail-over
• Should incidents be closed or kept open for monitoring
• Should a Problem be opened for every Major Incident
• Should the incident be reopened or a new one logged
• Does an emergency change need an incident

More on Incident Management

From Around the Web:

• Major Incident Report Template (MS Word, 95.5 KB)

Category:
ITIL Process > Incident Management

Disclaimer

Copyright 2013-2014 - ITIL® from Experience - D.Matte