Defining an ITSM Major Incident

April 13, 2015

In ITIL 2011 Service operation paragraph headed Major Incidents or MI, it says there is a separate procedure and you must agree what constitutes a MI. There should be a separate team, and incidents and problems should be kept separate. It is difficult to define a MI, but procedures must be put in place and clearly defined. One could consider a Major Incident a case of emergency, so the normal methods of problem management aren’t going to be enough. It isn’t quite a disaster, but it is beyond a normal incident.
You can begin by deciding who is in charge of declaring a MI. Case Management is very important and there needs to be a standard approach. There should be set guidelines, roles, and responsibilities. Skills can differ for each person. The person that is the Incident Manager may not always be the Major Incident Manager. This is why structure is important. People shouldn’t be left to make last minute decisions.
Once you have guidelines and roles in place, you should rehearse with staff to ensure everyone knows their role and duties. It is a good idea to have two teams: incident resolution and problem resolution. Impacted customers must be managed along with the restoring of service. Many companies will wait until something happens, but that leaves you frantic and unprepared. Places with several Major Incidents often practice MIM (Major Incident Management)frequently. The more you practice, the more prepared you will be in the even of a MI.

Leave a Reply

One comment on “Defining an ITSM Major Incident”

  1. Whilst I agree with a lot of the comments ptesod, I wonder how big this issue really is in the immediate future. I see a lot of organisations who still haven't grasped the concept of Services, usually implementing ITIL V2 with a Service Catalogue, whilst a huge proportion of Enterprises don't run web based apps for a lot of Business critical processes so, as Noel pointed out somewhere in this or a related chain, the issue boils down to some core IT components such as the SMTP/POP or some other protocol.ITIL needs to be brought up to date and I believe it should be re-written in smaller releases rather than a huge great big lump every few years and embrace a more agile approach. However, do we really want ITIL to define call handling etc? Isn't that what organisations such as SDI do? If ITIL goes down to that level on every process it will become, or be perceived as, prescriptive, and also be so large that everyone will lose interest. The answer isn't ITIL, it's ITSM. ITIL never has, and nor should it, prescribe exactly what a Service Desk should do. It should provide a framework which Organisations can then develop to suit their needs. There is no one-size fits all. Some sectors are very locked down and regulated and probaby will be for a long time to come and this should also be recognised.Whilst ITIL needs a serious re-think if it is to stay relevant, it isn't the issue. How it is implemented or a lack of understanding of the wider ITSM landscape is the issue. Why does it have to be written in an ITIL book to become Best Practice?BYOD is here to stay and is a great opportunity to integrate with the Business as has been described previously, but trying to narrowly define it and document it goes against the Knowledge Centred, agile approach some people are advocating. Long live ITSM (with or without ITIL).

©2007-2018 IT Training Zone Ltd – a Peoplecert, EXIN and APMG accredited training organisation.
ITSM Zone is a trading name of IT Training Zone Ltd.

​Payments we accept
ITIL Verified Leader Badge
Copyright © 2021. All rights reserved.
hello world!