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: Charl6898
New Today: 24
New Yesterday: 51
Overall: 146490

People Online:
Visitors: 35
Members: 2
Total: 37 .

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 - No users impacted - not 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 

No users impacted - not a major incident

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


Joined: Jun 27, 2007
Posts: 6

PostPosted: Thu Jun 28, 2012 1:00 am    Post subject: No users impacted - not a major incident Reply with quote

Good afternoon. Would appreciate some comments on this. I was giving a presentation to the greater (non-ITIL aware) IT group. It was on incident and major incident mgt.

So I give a fairly basic and standard definition of Major Incident:

A Major Incident is an unplanned or temporary interruption of service with severe negative consequences or potential consequences for the business


Now this one guys says - Hold on - why potential?? If it hasn't impacted someone why would we call it a major incident? Now besides the point he had some fear around calling something a major incident I found this question raised a huge amount of discussion - and one which I was not sure we got to the bottom of.

His example was - well say if a primary linked dropped and failed over to the secondary - and there was 0 impact on the users community - why would we raise a major incident? I tried to exaplain that becuase it follows the standard troubleshooting and also the production of a formal incident report etc (our own internal policy for major incidents) it is still classified as a Major incident. I also pointed out the obviouls areas of impact and urgency etc but I am not sure my point came across.

So thoughts on this?
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Jun 28, 2012 1:21 am    Post subject: Reply with quote

pbalfe

I happen to agree with him

The definition of an major incident in the ITIL Glossary

is

(Incident Management) The highest Category of Impact for an Incident. A Major Incident results in significant disruption to the Business.

if there is NO significant disruption, then it is NOT a major incident

It is merely an incident
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
pbalfe
Newbie
Newbie


Joined: Jun 27, 2007
Posts: 6

PostPosted: Thu Jun 28, 2012 1:58 am    Post subject: Reply with quote

Thanks for the response John

We have some criteria for what makes up a Major Incident beyond just the simple definition. Basically its a fairly standard Impact and urgency matrix which will determine the associated priority. So for example Impact of 1 and urgency of 3 would give a priority of 2 (Impact + Urgency/2) We then say anything with a priority of 1 is by its nature a major incident

In the case mentioned above where you would have no direct disruption to the business but a high impact and urgency you would you say we have a Priority 1 Incident as opposed to a priority 1 Major incident?
Back to top
View user's profile
Diarmid
Senior Itiler


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

PostPosted: Thu Jun 28, 2012 4:05 am    Post subject: Reply with quote

First of all a little clarification of the terminology.

A major incident is about business impact, not about user impact. The two will mostly go hand-in-hand, but the distinction is important.

Now, major incident is a concept conceived to deal with the kind of situation where there is not merely urgency combined with severe risk or cost, but also a need for exceptional management and resources in order to ensure as rapid a return to normal service (or as near as can be achieved) as possible.

However you are not using the major incident concept in quite that way (it is perfectly possible to have a priority one incident that does not require special management or resources - for example the method for fixing it may be obvious, straightforward and able to be completed in less time that it would take to set up a major incident team.

Bearing that in mind I can conceive of a major incident being raised (even, or perhaps especially using your definition of a major incident) before any damage has been done to services simply because the business is exposed to unacceptable risk levels when the backup becomes the only thing holding the service together. This could be true in some services in some industries and less likely in others.
_________________
"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
UKVIKING
Senior Itiler


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

PostPosted: Thu Jun 28, 2012 7:05 am    Post subject: Reply with quote

TO add to Diarmid and my points

the following are examples of Major Incidents

Fiber cut
Terrorist take over of substation
Fire in substation
explosion in substation
DDOS attack on a website
Web service failure
Natwest and RBS (at the moment)
ATMs down for unplanned / expected
Eurostar cant move (snow)
7/7 /// 9-11 / etc

Users may not be impacted but the business cant deliver the service

For a fiber cut, the telco may consider it major or the DC that one of its trunk is on will be on may be

Sometime a major incident i
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
pbalfe
Newbie
Newbie


Joined: Jun 27, 2007
Posts: 6

PostPosted: Thu Jun 28, 2012 5:39 pm    Post subject: Reply with quote

Interesting follow up points - much appreciated.

I think I may have used a bad example though - as in our organisation, a complete failure of a primary link would indeed require exceptional mgt and resources to ensure it is restored to normal service.

As this was the first time a large number of people were exposed to these concepts in detail my next plan is to set up a seperate session with those involved and get their understanding of what should be the definition around major incidents. I'll be asking them to bring specific examples of issues they feel are borderline/uncertain and we can trash it out.
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Jun 28, 2012 7:32 pm    Post subject: Reply with quote

PBalfe

The key to defining a Major incident in your organization that is providing a service to your customers has to be the impact to the Service - ie the business using the service.

If you provide a Data Centre and you have 5 links via different carriers out of that data centre and 1 goes down, then this may not be a major incidents to your customers as you have 4 connections left

However, internally, you may treat it differently with the telco and the telco may not consider the outage a major one.

Major Incidents are usually when the service is DOWN, the service cant be delivered, etc ... to your customers

You can still have high level incidents that are NOT Major incidents

Yes.. I know it is silly. but, ITIL is a guideline NOT a requirement
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
pbalfe
Newbie
Newbie


Joined: Jun 27, 2007
Posts: 6

PostPosted: Thu Jun 28, 2012 7:42 pm    Post subject: Reply with quote

Hi John,

Thanks for that. Just becasue this is my first posting on this form - please don't think I am new to ITIL - I have been working with it for almost 20 years. Smile

I believe this will be one of those cases where I will use ITIL as a guideline and customise it for our own use.

I still have the feeling in our situation and company and based on my own experience that it /should/ take into consideration not only the user/bueiness impact - but also the inherint risk.

Maybe I'll just call it a Majorish Incident....

Wink

Appreciate the feedback
Back to top
View user's profile
UKVIKING
Senior Itiler


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

PostPosted: Thu Jun 28, 2012 9:16 pm    Post subject: Reply with quote

As we all have said, ITIL is a guideline

Your post was about the presentation that you gave and the confusion that it is caused and trying to resolve it

You need to always ensure you differentiate between ITIL definitions and your defintions. THis is what caused the confusions from the folks

The issue is the difference between YOUR definition and ITIL

ITIL should be the basis of the defintion
Your process should use that to tweak this more rigidlly

As a user, any incident that impacts me is major

The service provider should define tightly a Major Incident as opposed to a incident which is high focus

Your matrix is a good start. However, dont fall in love with it

And Diarmid and I also have multiple years in this field. Mine is coming on 30 years
_________________
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: Thu Jun 28, 2012 9:17 pm    Post subject: Reply with quote

pbalfe wrote:
I still have the feeling in our situation and company and based on my own experience that it /should/ take into consideration not only the user/bueiness impact - but also the inherint risk.


That's really what I said, except I would prefer also to have a consideration of the need for the special approach of the major incident procedure. The point is that something real has happened even if users and business are not yet affected and you have to manage that in the most effective way. I would have thought it a rare occurrence to require major incident status like this, but I see no reason to make a theoretical distinction that might someday impede your necessary activity.

You wouldn't wait until the boat had actually sunk before pulling out the stops to save it (or at least the occupants). On the other hand you wouldn't call the coastguard if all you needed to do was bail out a few cupfuls of water.

pbalfe wrote:
Maybe I'll just call it a Majorish Incident....


The only reason for doing this would be if you were to design a "majorish incident procedure" distinct from your major incident procedure and your other incident procedures.

I'm still wrestling with your organization's idea that if something is priority 1, it is therefore a major incident. All priority determines is the order in which you handle incidents when you have too few resources to work on them all simultaneously. The point with all incidents is to resolve them as soon as you can and to assign resources to the higher priority ones first. You do not need a major incident procedure to do that since it works exactly the same between a priority 3 and priority 2 incident as between a priority three incident and a priority 1 incident.

You only need a major incident procedure when something very important and urgent is going to take a long time and probably need access to special or extensive resources. Typically you would appoint someone to manage the major incident and give that person certain authority to call on resources and require the incident management to continually track progress and report it to senior IT and customer management.

If an incident does not require this, and it certainly won't if it can be resolved within a couple of hours, then, however great the impact and urgency it will be more effectively managed under the standard incident procedure.

I'm not trying to build an absolute barrier here, because your incident management procedure should have a degree of flexibility built in anyway.

In terms of dialogue with your colleagues, I would suggest you begin by showing them the differences between your standard, emergency and major (and any other if you have them) incident procedures (i.e. the different ways you are able to manage incidents) and work backwards with them to understand why, for practical reasons, each is best in a particular case.
_________________
"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
pbalfe
Newbie
Newbie


Joined: Jun 27, 2007
Posts: 6

PostPosted: Thu Jun 28, 2012 9:24 pm    Post subject: Reply with quote

Many thanks again for the comments. Food for thought and has certainly given me some ideas
Back to top
View user's profile
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.