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)
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.
Posted: Sat Jul 11, 2015 4:30 am Post subject: Major Incident
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.
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