Key challenges of Major Incident Handling process

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
vampirephenom
Itiler
Itiler
Posts: 17
Joined: Tue Jul 22, 2008 8:00 pm

Tue May 27, 2014 3:33 am

Hi,

Can anyone help me with the key challenges that could be faced during major incident handling?

Thank you


User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3636
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Tue May 27, 2014 3:19 pm

Major Incident
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Tomek
Itiler
Itiler
Posts: 9
Joined: Mon Aug 04, 2014 8:00 pm
Contact:

Tue Aug 05, 2014 5:09 pm

Few out of my mind:
- re-prioritization (justification if this is really critical incident from End User or Business perspective)
- prioritization (if you have limited resources and many critical incidents at once)
- fixing it (search Knowledge Mgmnt DB effectively and discover workarounds or solutions)
- sticking to KPIs (especially if you have very limited time, for example Response 0.5h, Resolution 2h)
- monitoring (if you have big volume of tickets dispatcher is a good solution, then he/she decides also on ticket priorities)
- some incidents require emergency changes to be implemented

From end user perspective from my practice I can say that the biggest expectation, especially for business important systems, is timely & accurate communication.
In my opinion it should cover:
- what happened (in easy, understandable language)
- what IT is doing
- impact on the User, any actions expected from the User
- next communication (when)
User avatar
Tingtong
Newbie
Newbie
Posts: 2
Joined: Wed Sep 17, 2014 8:00 pm

Thu Sep 18, 2014 8:18 am

vampirephenom wrote:Hi,

Can anyone help me with the key challenges that could be faced during major incident handling?

Thank you
Challenges equal to experience.
Revolting users
Poor commmunication
Lack of skills
Processes in place delaying the procurements
Reactive Managers
and etc
User avatar
simplr
Itiler
Itiler
Posts: 10
Joined: Mon Dec 15, 2014 7:00 pm

Fri Dec 19, 2014 9:54 pm

The main ones we see are poor communication and poor prioritisation.

I have a theory that you can communicate well and fix very little and you'll be seen to be a better support team than one who fixed a lot and communicates very little.

The approach we generally take is to start by communicating too much and dial it back from there as people provide suggestions / feedback.

Additionally, the prioritisation of tickets is critical and unfortunately the 'standard' approach that most environments use (e.g. number of users being impacted + critical system etc) is very unreliable. It is better to teach staff the business thought process that would deliver more consistent results.

We teach that if there is an immediate financial or reputational impact to your client or your business then the impact should be high and you should be communicating this with the relevant manager.

This accommodates for that single user who is doing something critical and needs an immediate resolution (e.g. payroll won't go out tonight with XYZ fix).

This will also mean that you can retrospectively look at the incident and determine whether there are redundancies that can be put in place in future.
User avatar
Kimm
Itiler
Itiler
Posts: 11
Joined: Tue Jul 07, 2015 8:00 pm

Fri Jul 10, 2015 2:30 pm

When dealing with an MI, make sure that everyone understands "what" an MI is... Not all Sev 1's are MI's.

It is easier if you have a Major Incident Coordinator who can help with critical issues. They are responsible to get everyone together to best figure out what the solution may be... this includes vendors as well.

Your MI process should indicate who is responsible for what, expected timelines for everyone to be engaged & communications to people who need to know about it.

An post-MI review can also be worthwhile to discuss lessons learnt.

...Kimm
Post Reply