An ITIL project in the real world

Friday, May 26, 2006

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:
    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.


  • might you be willing to share your summary version - 4 slides?

    people still need help selling ITIL

    By Anonymous James Governor, at 6:47 AM  

  • This comment has been removed by a blog administrator.

    By Blogger ITIL Project Manager, at 11:10 PM  

  • James, unfortunately, I am not allowed to share these 4 slides. However, I can describe the content:

    Slide 1: Facts/main issues (ie: weak prioritization, no escalation, long resolution time, nobody wants to own difficult incidents) => we need to change!

    Slide 2: Change 1: setup prioritization based on service criticality and status => aligned on impact on customer; organize escalation

    Slide 3: Change 2: Incidents must be resolved ASAP; when not resolved fast, the "system owner" gets responsibility and authority to get the service restored

    Slide 4: Benefits: IS reactivity aligned on impact on customer

    These are quite basics, but that's where we are now! This is tailored to our (lack of) maturity ;-)

    By Blogger ITIL Project Manager, at 11:12 PM  

  • have you already defined the roles and responsibilities? Would it be ok to share it with me..

    thanks a lot

    By Anonymous Ram, at 11:58 PM  

Post a Comment

<< Home