How did I get into ITIL?

Still 35hours to go until I get that 30 minutes meeting with the main sponsor! Until then, while we're waiting, I thought I could let you know a little bit about how I got into ITIL...

Getting to process improvement
15 months ago, a new IS manager joined our company. He was coming from the pharmaceutical industry, where processes and measures are part of the day to day life of every employee. He was quite surprised to see the total lack of processes and procedures in his new environment... How can you manage your staff without objectives? How can you set objectives if roles and responsibilities are not defined? How can you define roles and responsibilities if there is no process? I had just completed the project of deploying a "Ticketing System" accross our IS department and was supposed to move into his group (PC support, Service Desk and non-corporate support). He proposed to me to setup a Process Improvement group, to start a "continuous process improvement" approach. What that ment wasn't so clear to me, but I took the challenge anyway.

Discovering ITIL
Starting up our new process improvement discipline, I quickly ran into a few issues: how to organize all these processes? How to name them? What to do when you have no process defined? Were there some best practices that we could use, instead of re-inventing the wheel?

I looked on Google, and found: ITIL, Cobit, Six Sigma....

I discovered that ITIL is not only largely accepted, but it also provides a lot of guidance to do efficient IS Service Management. And my colleagues from the operations team had also already heard about it. And our main IS service supplier was talking ITIL... Encouraged by our new boss, we slowly started growing the awareness of the support group through a large ITIL foundation certification campain - but without any project yet, as we were still not able to gain acceptance from the whole top management team.

I also started attending our local itSMF conferences, which was a real eye opener. Other companies do it. It is not just a British thing! They have the same difficulties, the same issues, the same hopes.

ITIL is more than a batch of theorical processes
Month after month, the better I was understanding the 11 ITIL disciplines, the clearer it became that IT Service Management is actually all we ever wanted to do, but were totally unable to, because we never knew how to tackle it! There was a bigger picture that made sense! If only our IS top managers had had a good understanding of these disciplines, then we would be more efficient today. And maybe we could have spared a few re-orgs ;-) There it was: a better vision. Real customer service. But still, we were not able to gain acceptance from the whole top management team.

Get back to earth
Six months ago, a few weeks before I received my Manager's Certificate, an unfortunate change happened: my manager, that was so fond of processes, measures, objectives, etc, was called out of IS by another division to run some special project... His approach was more appealing to that other division than to the IS guys. Bad luck for ITIL! The rest of the IT top management had yet to adher to the approach, and bringing some improvements in these circumstances was gonna be a real challenge!!!

As I was still allowed to work in this field (I'm half jocking), I built up a new strategy with my process friendly colleagues (there are some): stop talking Incident Management, Service Management, ITIL, best practices. Instead, use the words that my organization already understands: escalation paths, criticality, priority, logging when something does not work, logging how it was repaired, agree on when analyst are supposed to work on the things that broke, etc. Start simple. Start with a project for setting up the basics... of Incident Management. Once that project will be completed, grow from there.

So there we are: trying to get this Incident Management project started!

I have now reworked the project plan and the project charter, clarifying the few points that were raised last week. Next Wednesday, at 9AM, the main sponsor and I will meet to see if we can start getting the "signatures" (starting with his ;-) )

Feeling a little bit despaired today...

Well you know what? It seems that issues are popping up as I'm trying to get the project charter signed off. I really need to fight for the only resource that was planned for the project (NB: I'm still allowed to work on it for now :p). And some are asking to remove a key initiative from the project: the one that would establish clearly the roles and responsibilities of the IS groups all along the Incident lifecycle!

It looks allright with our SAP project - there are more dependencies from the Incident Management project to the SAP project (this is what I had already identified, one of the drivers for doing the project) than there are dependencies from the SAP project into our Incident Management project. I should have tomorrow the official confirmation from the guy in charge of organizing support for the SAP project...

However, now that the project is getting closer to the official sign-off, some managers are getting anxious that it could be dragging too much of their resources :D That should be an easy one to tackle ;-)

I'm not so surprised at the difficulties we're facing. With all concerns expressed now, they can be managed upfront, clearing the way to the project! But I wouldn't be surprised if we have to deal with a few bumps - and maybe some big ones!

What is this first ITIL project about?

Here are more details on what we are trying to do: as I explained in the very first post, we want to go ITIL discipline by discipline, and we are trying to start...Incident Management.

This Incident Management project is supposed to start ASAP, and finish in September. The proposed project is made of 9 initiatives - 4 easy ones and 5 tougher ones, spreading the deliverables all along the project. In summary here's what we'll do:

• In the Service Support tool, review support group names and categorization, base them on services, not on organization hierarchy.
  
• Write and deploy guidelines for qualifying Incidents correctly (ie identify what is high priority, which group it can be escalated to, etc.)
  
• Setup some general OLAs within IS, organize escalation paths, define how crisis are handled.
• Clearly identify roles and responsibilities along the Incident Lifecycle (but that's a tougher one.)
• Organize communication through the Service Desk.
• Allow users to submit calls and view status online.
  

... the sponsors talked about the project for 45 minutes. Basically, they agree with it! We have some rework to do on the plan - identify clearly which of the initiatives have dependencies with our SAP project, and which do not.

The 3rd sponsor likes the project charter as well... We only need the CIO acknowledgement, and we can start!

Building the case for an ITIL project

That can be a real challenge. Here are the lessons I learned trying to get something started in the company where I work:

• Lesson #1) Do not build a case based solely on the fact that your IT is inefficient and that adhering to best practices will solve the problem.
  
  That does not work (I tried!) It is badly received by all managers that have patiently been trying to improve the support services in their group. Why would so-called best practices be any better than what they are doing? And these best practices are no different from what we already do anyway! We have more urgent matters...
  
  
• Lesson #2) Do not try to implement an ITIL discipline accross the organization without a project
  
  Implementing an ITIL discipline will change habits, organization, roles and responsibilities. In lack of a formally accepted project, the benefits of your initiative will be largely outweighted by the efforts you will invest in making these changes happen - you might even get nothing in the end!
  
  As most ITIL disciplines are cross-functional, you need strong support from top management to be able to implement real improvements. In lack of such a support, in lack of project supported by top management, the changes you can bring are limited to the groups which are under the control of the manager requesting the change. And even then, a project will help focusing, following up, controling we stay on track and get the right deliverables...
  
  I tried one year to bring improvements without a project. I will not brag about the results!
  
  
• Lesson #3) Build the case based on needs expressed by the management
  
  Now that's not a new thing. Be close to your "customer". Ask them where they feel the pain. Ask them what they think is not working properly. Scope the discussion around a specific ITIL discipline (of course this implies that you know your topic well). Write carefully all their needs. All their requirements.
  
  Organize these requirements. See if that ITIL discipline implementation could help. Turn it around from their point of view. Check what they haven't mentionned. Why? Maybe that part of the process is working just fine!
  
  Then build the project with their words, focusing on their requirements, and staying within the scope of a specific ITIL disciple. The project must be their solution to their problem.
  
  This is how I have finally built the case for this "Incident Management" project. It seems that it will come through now... I can't wait to confirm...

2 of the 3 sponsors like our Incident Management project charter! That was a tough job. Now on with the last sponsor, and with the CIO... If we get this through, I tell you some on the technique we used to build the case...

Running an ITIL project - my experience, day by day, live!

Interested by ITIL? How it works in the real world? You've found the right blog! I'm just about to start running a program of ITIL projects in our company. Week after week, you will read here all the details about this experience.

The context
We are an international chemicals industry based in France, with multi-billion dollar sales, and more than 4000 employees. Our IT department had disconnected IS initiatives towards support improvement over the years, but the quality of our services and support is still not up to the wishes of our customers. We are not a process and control oriented company - we are more creativity oriented (business wise, that is.)

Where are we with ITIL?

• We have had a helpdesk for more than 10 years - part of the IT organization understands that it could help if it turned into a Service Desk.
• We already have a service desk/service support tool, that we are not using to its full potential yet.
• We have got some change management procedures implemented (because the operation of our infrastructure and the development of our applications are outsourced)
• We have no other service support or service delivery discipline in place.
• During the last 16 months
  • we have also been slowly implementing some basics of process improvement (a hard work in our highly unformal environment ;-) )
  • got a part of the IT organization ITIL foundation certified.
  • there was a gradual awareness increase within the IT organization. It is crucial. Without commitment from the management and the organization, you cannot get cross-group improvements. Do we have that commitment now? Maybe...
  
  Where are we at today?
  You must have the picture now. There's plenty of room for improvement, and the grounds seem ready. We decided to start with the obvious: Incident Management.
  
  I just finalized a project charter for "Incident Management", got it reviewed by a bunch of people, and am now in the process of getting the signatures of the top management. I'm presenting it tomorrow to some of the sponsors! So.... see you tomorrow!