We presented the changes that will be implemented to improve our Incident Management to the CIO. He likes it.
So we are now transforming all that was defined into something real.
1) Make a 4 slides summary of the whole thing, so that the CIO can push it down to the top management. Getting from the original 45 slides to the reduced "executive summary" of 12 slides we presented to the CIO, down to 4 slides was quite an exercise, but I think we were able to keep the message through. We' ve almost completed that one.
2) Prepare the training that will ensure everyone gets the details of what is expected from them. That's a tough one, because we don't want to be the annoying lecturers preaching to a crowed of bored IT guys who are just waiting for the end of the speech to go back to their corporate lives and do the same'o thin' they've always been doin'. So we'll try to take it from different angles:
3) Change the tool configuration so that it is very close to the revised processes, enabling it, facilitating it, but also enforcing it. We have also withheld some goodies that will allow them to work faster, so that they get the goodies and the constraints at the same time!
4) Documenting the process, roles & responsibilities, and setting up the reporting to measure the process. These will be key points for the effects of the change to last.
That's where we are right now!
So we are now transforming all that was defined into something real.
1) Make a 4 slides summary of the whole thing, so that the CIO can push it down to the top management. Getting from the original 45 slides to the reduced "executive summary" of 12 slides we presented to the CIO, down to 4 slides was quite an exercise, but I think we were able to keep the message through. We' ve almost completed that one.
2) Prepare the training that will ensure everyone gets the details of what is expected from them. That's a tough one, because we don't want to be the annoying lecturers preaching to a crowed of bored IT guys who are just waiting for the end of the speech to go back to their corporate lives and do the same'o thin' they've always been doin'. So we'll try to take it from different angles:
- a) Get them through a 3 episodes story where they have to analyse what the different actors did right or wrong, how they could have done better. Of course, the first episode will at first sight looks like IT did a great work: Incident resolved in less than 1 minute!
Next episodes will show actually what happens when...huh... affected end user was not properly identified, service was not properly identified, call wasn't recorded, escalation was done without providing any information, diagnosis was not recorded, solution wasn't recorded, etc!
We're also thinking of some twist so that there is something funny in the characters, to ease the message.
The key point being getting them to tell what the support did wrong, and getting them to think of the consequences can be.
b) build a few written cases, that they have to analyse, so that they can get in situation without fealing too threatned.
c) prepare some test cases, role based, that they have to play, with the re-configured incident management tool, so that they learn the difference between doing it before and after. If we can, we will also make sure that they get switched to the new configuration right the day after the traing.
3) Change the tool configuration so that it is very close to the revised processes, enabling it, facilitating it, but also enforcing it. We have also withheld some goodies that will allow them to work faster, so that they get the goodies and the constraints at the same time!
4) Documenting the process, roles & responsibilities, and setting up the reporting to measure the process. These will be key points for the effects of the change to last.
That's where we are right now!
Any additional idea would be welcome.
posted by ITIL Project Manager at
8:36 AM
|
4 comments
