When is an Incident a Major Incident?

[RitaV]

This might sound like a confusing question but it is one that I am currently dealing with in our own company.

When is an incident timestamped as a Major Incident? Let's say a technician is working on a low level incident. Suddenly after working on it for 8 hours or 24 hours, he/she comes to the realization that this is a larger problem. He/she escalates to the Service Desk that this is a Major Incident which requires it to be work until it is resolved with all of the bells and whistles that come with a major incident.

The question is........after 8 hours of working on the issue......does the incident that is now declared a MI, come with 8 hours of baggage already associated to the MI or does the clock start at the point the incident is declared a MI?

To me, it would be incredibly difficult to manage MTTR metrics when MI's are "frontloaded" with all of the time the tech spent researching prior to declaring a MI. I have seen cases where MI's were opened with all of the previous hours attached but resolved within the MTTR guidelines established for the particular MI. However, when you allow those hours to be incorporated into the MTTR equation - it gives the impression that you are not resolving MI's within the restore time targets you have established.

What is the ITIL view on this?

Rita

[UKVIKING]

Rita

A major incident is what your company decides meets the company definition of a major criteria

Examples of a major incident

Data Centre loses power - completely or partially - and is on UPS
network centre loses one of the major telco trunks to the US (UK)
All print servers crash at the same time
Senior executive (Board level) laptop gets blue screen of death

As for your example, no it is still just an incident

There is no time limit in restoring service to be honest in ITIL. While a company may post MTTR and Service restoral time, these are merely guidelines

If the incident in question affect 10 people out of 2000, then it is a incident
If the incident after the 10 people in the payroll department - preventing payroll records to be done on the day of payroll, it is a major incident

How your company measure the start time / end time is up to you and the capabilities of your tool

IMNSHO, the incident start time is the incident start time
the major incident start time is when the incident is identified based on the company criteria for major incident

Your mileage may vary
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Diarmid]

Rita,

I'm sure there was another discussion about starting clocks. In fact I'm sure there are at least two other discussions.

As John says, "the incident start time is the incident start time".

To make things doubly clear, the incident start time is the moment that the incident occurs. From that moment there is a requirement to do something to alleviate or prevent service loss. This is irrespective of whether, at that time, you know that there has been an incident or not.

To make things triply clear, failure to recognize the full level of impact (or potential impact) of the incident for any length of time is a measure of your incident management capability (and may be something you can improve).

The primary point about measuring incident resolution time is to measure how much service quantity and quality has been lost to the customer. Considerations of capability in particular processes are a secondary aspect.

All incidents require the timely application of resources to expedite resolution. The true purpose of a "major incident" procedure is to ensure that, where such expedition requires it, there is a prepared path for engaging both service and customer management in the control and with the authority appropriate when it is beyond the scope of day to day practice.

I think there are really two kinds of "major incident". The first, as above, requiring "major incident" management and the second where the resolution is straightforward and quickly applied through normal channels, but the impact was nevertheless very great.

In this second case you do not need a major incident process, but you do need a high priority investigation to prevent (or at least mitigate) a recurrence.

So the major incident process should be about high impact combined with potential duration and complexity.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718