Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
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.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
The Itil Community Forum: Forums
ITIL :: View topic - No users impacted - not a major incident
Posted: Thu Jun 28, 2012 1:00 am Post subject: No users impacted - not a major incident
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.
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?
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu Jun 28, 2012 4:05 am Post subject:
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
Joined: Sep 16, 2006 Posts: 3544 Location: London, UK
Posted: Thu Jun 28, 2012 7:05 am Post subject:
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
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.
Joined: Sep 16, 2006 Posts: 3544 Location: London, UK
Posted: Thu Jun 28, 2012 7:32 pm Post subject:
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
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.
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.
Joined: Sep 16, 2006 Posts: 3544 Location: London, UK
Posted: Thu Jun 28, 2012 9:16 pm Post subject:
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
Joined: Mar 04, 2008 Posts: 1894 Location: Helensburgh
Posted: Thu Jun 28, 2012 9:17 pm Post subject:
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
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
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
