Major incident management

[sigquit]

What's your approach towards the major incident management? (dealing with severity 1 incidents) I've been presented today a model which forbids the initial asignee from re-assigning the ticket back to the service desk if he decides that it was misassigned or that the problem lies somewhere else. Instead what one must do is figure out where's the problem, who is the best person/team to resolve it and call him/her directly.

So basically if I'm a server guy, I receive a sev.1 ticket and I realise that it's actually some network issue for which I'm not responsible, instead of sending back the ticket to the SD and adding a comment like "network connectivity issue, please contact XXX", I should contact XXX myself and work towards resolving the issue. What do you think about it? How do you deal with this issue?

[dboylan]

In organizations I have been with, Level 1 Incidents are immediately brought to the attention of the Incident process manager (me). If it was assigned incorrectly, the person/group to whom it was assigned would call or page the Incident Manager and indicate that it needed to be re-assigned.

The thinking behind this was that the specialized 2nd level support groups would not have the institutionalized knowledge to quickly get it to the correct group. The person who will most likely have the knowledge (or know who to ask) would be the person in charge the of the Incident process.

[sigquit]

that's smart, good point. but still, why not route them back to the SD with a quick hint on where could be the problem? in the end the SD should be the best persons to reassign it to the correct group.

[UKVIKING]

The Major incident process should be controlled/managed / oversighted etc

by the Incident Manager and the Problem Manager\(team)

If the IM mgr says that the Team lead has control of the ticket through out its life, then ....
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Mark-OLoughlin]

Hi,

in situations I have been in the incidents / problems were passed back to te "Service Desk". However there was a specalist team there who were in effect Incident / problem managers and the tickets were send back to them and not 1st line support as the original poster is correct in saying how do they know where to send it to next. Also it provided for better control.

I agree it should go back to an Incident / Problem manager and in some cases this could actually be a small team of people if the org is large enough or just one person.
_________________
Mark O'Loughlin
ITSM / ITIL Consultant

[mgruber]

Hi,

First post in this forum...

One thought that may justify the reason is a ticket bouncing around.

The process may ask resolver groups to perform "warm handovers" between each other and give the receiver a accept/deny response.

i.e.

Server guy calls network support...

Server guy: we just got this Priority 1, and its actually a network issue, so we're sending it to you.

Network guy: let me check, our router shows no response from your server. Have you checked your LAN card?

Server guy: hmm LAN card driver is missing, ok we'll keep the record and reload the driver.

The alternative, may have been record sent back to Service Desk, Service Desk then pages Network, Network updates record, sends back to Service Desk, Service Desk then reassigns back to Server.

Also, in a multi-outsourcing environment. It would be better to have different network vendors warm handover to each other rather than communicate via transfer of records.

This is based on experience in managing a multi-outsourced environment with networks that have 3+ service providers working side by side.

Regards
Michael

[Skinnera]

My thought is that this is under the wrong thread? It's Incident Management surely??
_________________
When I say 'CCR', please read 'RFC'.

[ItilyWoman]

At our organization we page a group of IT operation managers that we call the "Priority 1" group for each priority 1 ticket that is assigned. This includes both our Incident and Problem Manager as well as other managers that need to be aware of the incident.

We've experienced problems with the first assigned group throwing the ticket over to another group without properly updating the incident ticket as to why it actually belongs to the second group. For this reason, we too are implementing the warm hand-off idea. The first group can reassign the ticket, but they must then notify the Help Desk and then personally talk to the group they are handing off to.

[UrgentJensen]

(Skinnera,

Agreed, this is IM and should be on the IM forum... oh wait, there isn't one.)

I always like this question. Most of the previous responses are in some way correct, be it 'by the Book', or just common sense, so I don't see this being the real problem here.

I think the way the service is delivered is less important than the culture/politics at play. This perspective is very important.

When you're introducing Incident Management it is still often seen as the domain of the plebs on the Service Desk, and can lack respect, which in turn leads to a continuation of incidents being thrown over the garden fence.

If you're going to have an Incident Management process then link it to appraisals, get business buy in and review, and make failure to comply seriously scary. I have seen great intentions, new processes, completely overrun because there's simply not enough authority afforded to the Service Desk and the IM.

So, for me, that is the battle- empowerment. Any half decent process will work if it's enforced. If people don't comply, throw the (sixth) book at them.

UJ
_________________
Did I just say that out loud?

(Beige badge)