Kickoff-meeting and basics for our Incident Management Project.

Kickoff meetings

We had 3 informational presentations on the project, to let managers know what they could expect of the project (goal, objectives, initatives, organization, etc), as well as how it would impact them and their teams.

The analysts and managers of the company that manages our infrastructure have welcomed the project - they feel it will clarify and improve the process for them.

Service Desk & PC support team were also positive, probably because they could see that some very practical problems they have today will be addressed (ex: blurry roles & responsibilities; unadequate call categorization; 1st level not capturing valuable information for 2nd level.)

The application support and development managers seemed more interested in criticizing the project objectives and questioning the reasons for doing this project, than in understanding what it would bring to them, or what it would imply. Most funny quote of one of these guys: "Why do you need several months for this? You could just send an e-mail telling people what to do, and it would be done!"

Actually, one of our key issues is that since a few years, this group has preferred to focus on the more shiny project and development activities than on the support activities. As roles and responsibilities are not defined in our IS department, and as service management best practices are unknown to most of the top management and to that team, nothing was really pushing them to change. But their boss is one of the sponsors, and has realized that they need to improve now... Actually, he came back to me the day after the presentation (to which he couldn't attend, unfortunately), apologizing for the behavior of his team! Let's hope he'll straighten that up! We'll see... Anyway, we will still need to work on gaining more support from them.

Basics

Out of these lively presentations, we also had the opportunity to brainstorm with the Service Desk manager on the basics of Incident Management, and what message to push at the workshop sessions we'll have in the following weeks. In a few words:

1. When there is an Incident, we need to restore the service as fast as possible (sounds familiar? sounds logical? we often forget the basics!) Other activities come next.
2. Service Desk, and second level support teams mut quickly try to troubleshoot the Incident! When all basic troubleshooting fails, the IT service owner becomes the final responsible group for the restoration of the service (unable to push that responsibility to another group ;-) ). [Eventually, when we get more mature, we might say we are triggering problem resolution at that moment - we'll leave that out for now] Authority of the IT Service Owner should then be aligned with their responsibilities... (today some support groups refuse to collaborate with the IT Service Owner on some Incident, because it is not their priority!)
3. Priorities on Incidents are here to help us organize our work - what to work first, what to work next, etc. It is not because an Incident has a low priority that we it must wait one week before being taken care of!
4. When Incidents are not handled as fast as they should be, it has to be escalated a) to management b) in priority (I like that one - it shall take care of groups who say they dont have time to handle low priority Incidents)
5. etc

Next weeks

We now need to get people together, to agree on these basics, and build on them...