Search
Topics
  Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· FAQ
· Feedback
· Forums
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account

Current Membership

Latest: EWaller
New Today: 44
New Yesterday: 64
Overall: 148297

People Online:
Visitors: 48
Members: 0
Total: 48

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

Note: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


The Itil Community Forum: Forums

ITIL :: View topic - When is an Incident a Major Incident?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

When is an Incident a Major Incident?

 
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk
View previous topic :: View next topic  
Author Message
RitaV
Newbie
Newbie


Joined: Jan 13, 2011
Posts: 2

PostPosted: Thu Jan 13, 2011 11:15 pm    Post subject: When is an Incident a Major Incident? Reply with quote

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
Back to top
View user's profile
UKVIKING
Senior Itiler


Joined: Sep 16, 2006
Posts: 3318
Location: London, UK

PostPosted: Fri Jan 14, 2011 12:38 am    Post subject: Reply with quote

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
Back to top
View user's profile
Diarmid
Senior Itiler


Joined: Mar 04, 2008
Posts: 1884
Location: Newcastle-under-Lyme

PostPosted: Mon Jan 17, 2011 8:30 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> The ITIL Service Desk All times are GMT + 10 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003 http://www.nukecops.com

Forums ©

 

Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.