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

Our ITIL Incident Management project is slowly beginning - now that IT managers are back from holidays (including myself ;-) ) .

We started with something quite basic: reviewing the support groups in our Incident Management tool. Going to each group one by one, asking them what they really support, simplify naming, add descriptions to groups, making sure that important services have their dedicated group, and shaving off some of the unused groups. That should help us in 2 ways: first, it will be easier for 1st level support to escalate to the appropriate group or analysts, second it will provide more targeted queues to the 2nd level support groups. The list details are 90% complete. We'll get the last 10% by Tuesday next week latest. Then a little bit of advertising, a few code adjustments, and we'll be ready for deployment.

Next week will be our first intense serie of workshops. We'll draft the activities, roles and responsibilities for recording, categorizing and qualifying Incidents, as well as the basic escalation principles, and a very general OLA. Why such a rush? Because we need these basics to start a real discussion with the managers of the support organization. Without some draft proposal, we would face real difficulties for building something constructive. Drafting should be short. Getting the agreements will take more time. I'll tell you how that approach works out.

In 10 days only, we'll have our kick-off meeting. Why a kickoff after the real beginning of the project? Does that make any sense? Actually, we have some short deadlines. If we need to wait until all people involved are available for the kick-off to start doing anything, we'll never be ready in time. So we're doing the preparation work. When everyone will be fully aware of the project, we'll be ready to move fast.