An ITIL project in the real world

2006-12-25T16:22:00.000-08:00

My Incident Management project is now closed :-)

After our successfull roll out and a few months closely watching how well each group or analyst follows the process, we have gradually reached the service level we targeted! It wasn't straightforward, certainly challenging, but very rewarding.

The hardest part will be keeping up the good work ;-)

I hope you will have success with your initiatives too :D

2006-11-29T16:13:00.000-08:00

How to put IE7 menu back on top, and hide that new search box

Microsoft did a pretty bold move in removing the user's freedom of choosing where we want our address bar and menu displayed, and forcing their search box to be displayed. Fortunately there are some ways around that change: some registery tweaks.

To put the IE7 menu back on top: create a .reg file with this content:

Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Toolbar\WebBrowser]"ITBar7Position"=dword:00000001

To revert back the change:

Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Toolbar\WebBrowser] "ITBar7Position"=dword:00000000

To hide that extra search box they added, that is redundant if you already have, say... the Google toolbar:

Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\InfoDelivery\Restrictions]"NoSearchBox"=dword:00000001

To bring it back on:

Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\InfoDelivery\Restrictions]"NoSearchBox"=dword:00000000

To allow 16 simultaneous connections (that improves speed of downloading pages:)

Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]"MaxConnectionsPerServer"=dword:00000010"MaxConnectionsPer1_0Server"=dword:0000010...

Hope this helps you too ;-)

2006-08-09T13:04:00.000-07:00

How to measure improvements brought by our Incident Mgt project (3).

MEASURE 3: Market Share

Definition:
Number of user calls recorded per user per month.

What's the use?
I am not sure that "Market Share" is a very good name for this. Does anybody know another way to call it? Anyway, here's what it is good at: this gives you an idea whether 1st level support is doing one of their key tasks, which is... recording calls! Although it can sound obvious that 1st level support should record all calls, as an analyst, if this is not made very clear by management (and supervisors), it is very easy to slip away from it. Ex: "The user called and I solved her problem in 30 secs. Why would I record that? What's the use? It will take me more time to record it than it took me to resolve it!" It is not uncommun for an analyst to prefer to be the "hero" who solves 10 things like a Superman, than solving these 10, and recording what you have done. What extra reward do you get from recording that?

That's when this measure comes in handy. I've been told that industry average for recording calls should be roughly 1.1 record / user / month. Of course it varies a lot from one industry to another. And whether you have a majority of plant workers, or a huge marketing team ;-) But that can give you some idea where you're at with this activity.

Limitations with this measure
The objective is not to record more calls than there really is, to have nice numbers. Actually, if we had very good problem management, change management, availability and capacity management, etc, we should not have so many Incidents no? Still, if your company is big enough, you may be able to use this measure to highlight which L1 support team is not doing that part of their job properly. And believe me, at my place, it is quite obvious.

Another limitation is that it is not taking into account the quality of calls recorded... this would require a softer measure.

2006-08-06T12:51:00.000-07:00

How to measure improvements brought by our Incident Mgt project (2).

MEASURE 2: Percentage of Incidents resolved in time

Definition: Number of Incidents resolved as per agreed on OLAs&SLAs divided by total number of Incidents in the period.

Will it help us? I think that can be an excellent measure. We can use it to identify services that lack proper support, or teams that do not react in a timely manner... It should be a great tool to fine tune our process - but we won't be able to compare with the situation before the project, because we did not have any kind of OLA...

Limitations with this measure
I have to say I like this measure. If Incidents are not recorded, it shows bad. If you stay within targets, it has a positive impact. If you over do it, it does not make the measure any better.

However, that measure alone will not be sufficient. What if analysts do not record anything? Or just a few Incidents that are resolved extremely fast? The numbers will not make any sense... We'll need some more. But I will keep this one.

2006-08-05T03:22:00.000-07:00

How to measure improvements brought by our Incident Mgt project (1).

It's now almost one month that we have rolled out changes for improving the way we handle interruptions of service. What improvements did we achieve yet?

MEASURE 1: Average time to resolve Incidents

Definition: time between initial record of the Incident and resolution by the specialist (not including extra time until user acknowledged that the service is back up and running properly.)

Altogether, our average time to resolve Incidents hasn't changed much yet... It means that analysts haven't really started to change anything towards Incident handling. ie: they are not giving more priority or effort towards this task today than before.

How will we make improvements happen then?
1. In a few weeks, we'll start automatic and Service Desk escalation to management for each and every Incident that is not resolved as fast as expected. This should be an incentive to improve behavior...
2. We will work closely with the teams and analysts that do not resolve Incidents in time. Instead of bothering everyone, we will focus on teams that are not providing a proper response, and focus on Incidents that were not handled in time. This should help teams focus on Incidents according to priorities - and will avoid unnecessary escalation to management.
3. We will advertise team performance. That will show management and teams that other teams can do better.
Limitations with this measure

Although that plain measure is very good from a high level and customer perspective, we will need narrower measures to decide on specific actions to further improve performance. The problem with this global "average time to resolve" measure is that it is influenced by factors that are not related to speed at which analysts try to solve Incidents. Ex:
1. To which extent does level 1 support record Incidents?
  
  At our company, Service Desk specialists tend to overlook Incident recording, specially when an immediate resolution is provided! When management increases or decreases SD focus on Incident recording, there is a dramatic impact on this measure - much more than any other increase or decrease of service support quality!
  
  Of course we need to make sure that we do as much as we can to facilitate Incident recording - at least for the getting a more accurate picture of the situation. This is part of our project actually. It will make us look more efficient but in reality this will not be providing immediate improvement to the user community.
2. Some Incidents can only be resolved with changes.
  
  If we want to really improve the situation when installations or code changes etc are required, we will need to review our procurement policies, contracts with suppliers, organization of support, etc. . This has not been tackled by our project, so there are few chances things improve in this area right now.
Also, it is an "average" which means that few exceptional bad/difficult Incidents can drag the results in such a way that the average is not representative of the quality of service provided. Next, it does not take into account that some Incidents need to be resolved extremely fast, because they have a high impact, and some Incidents may be resolved later than other Incidents, because they have less impact on our customers.

For these reasons, we should probably pick another measure... why not, "Percentage of Incidents resolved in time"?

I'll discuss this in my next post.

2006-07-14T13:50:00.000-07:00

How the Incident Mgt changes were received by the teams...

Well, we had a mix of attitudes and reactions.

For most of them, it sounded all logical - some even questioned why we were not already doing it before.

Some were more reluctant, focusing more on the "why we need to do this" than on the "how can I make it happen".

Some were even clearly against the changes that they will need to go through. However, as they went through a process of analysing and accepting the move, they now seem to be the most supportive ones!

The most difficult will be handling the "silent majority". Those who do not have any comment , that seem to cope with the change, but actually themselves do not plan to change anything in their good old habits...

2006-07-13T12:01:00.000-07:00

The roll-out of our first Incident Management initiatives is completed!

We got everyone trained to our new processes, and to the changes in the tool. This was not an easy task - when you get to the 20th training session you feel like you are repeating yourself a little! The good thing though, was that from session to session, we were able to improve the balance between

theory, ie "What is expected from all of us, why we need to change, what are the roles & responsibilities",,
fun, with a movie + exercise that demo the shortcomings of the "quick and dirty" old way of dealing with Incidents,
practice, with hands on exercises on the tool,

shifting from 60% theory, 15% fun, 25% exercises 3h sessions to 40% theory, 20% fun, 40% exercises 2h30 sessions. For the unlucky remote teams that received a remote training, we had to skip the fun part, and replace the exercises by a quick demo, to squeeze the whole session down 1h to 1h30!

After completing this roll-out, we decided to delay two of the other initiatives of 2 to 3 months, in order to secure the first wave of deployments. Teaching about change, and making sure habits change is not straightforward, and will require careful monitoring and tuning for a few months. If we don't want to waste what we have already done, we need to secure these changes!

2006-06-09T15:04:00.000-07:00

Organizing the roll-out.

We initially planned to deploy the changes gradually to the analysts, gradually meaning: right after they attended the training. But we identified a few incompatibility issues between the old and the new way - we'll have troubles running them in parallel. Not only the tools is adjusted in many ways (categories, prioritization, role based behavior) , but also the analysts will need to change their habits! Some old and new habits will collide. So we will phase the changes differently.

Here's our draft plan (you are the first ones to see it!):

Announce the changes and the plan
Providing links to the documentation, training material and training environment.
(wait one week)
Deploy tool changes 1:
Reviewed call categories. This will not have much impact on the old process, and will allow the users to "train" on the job - getting some questions ready for the training. That will be a hot topic, as we will be categorizing by service now.
Train the analysts on all the changes (spread over 3 weeks)
Deploy tool changes 2 + aligning IT reactivity with priorities:
Reviewed impact, prioritization, "shortcut buttons", queues, etc in the tool. These are the changes that we may deploy to analysts as they get the training, but this adds complexity to our roll-out... So we might as well deploy them once training was done to everyone.
(observe how we are doing for one or two months)
Deploy tool changes 3 + escalation:
Automatic escalation and alarms, follow-up by Service Desk + e-mail escalation (if we do not need to escalate too many calls each day!).

Obviously we've still got some preparation work to do before starting this! And we've only got two weeks left! Wish us luck!

2006-06-07T23:12:00.000-07:00

Our CIO presented the main Incident Mgt process changes to the IS organization!

It was worth lobbying. Finally, he presented the four slides early this week, at the IS quarterly meeting. It was well received. Few comments and questions allowed to re-inforce that the management was fully supporting these changes :-)

Changes on the system are now almost ready, and training material is getting solid. We will be validating both of them in the next week, and should start deployment in about 2 weeks!

2006-05-26T08:36:00.000-07:00

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

them

b) build a few written cases

c) prepare some test cases

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.

2006-04-29T05:02:00.000-07:00

Feedback of the sponsors on our first Incident Management recommendations.

Now all 3 sponsors heard the recommendations from the task force, on how to address some of our support issues with Incident Management. In a few words: they like it :D

Overall, they like that it will help us become more professional and deliver a more consistent level of service. They also like the improved transparency it will provide. And yes, they will push the message down. Actually, before it goes down, we will present it to the CIO, as although the recommendations do not imply that we hire additional resources immediately, in the long term, the new way to manage Incidents will highlight the weaknesses in our support, and we will need to address them.

A few other comments that they made on the presentation:

the project will contribute to improve our efficiency, we should highlight this more.
we'll also need to highlight for the teams what they will gain out of it.
they like that it will make it clear for all groups that they also have a support role.
we need to highlight that when the service is restored with a workaround, support still needs to take actions to address the root cause of the problem.
yes, Incident resolution has priority over projects, but impact on the project must still be taken into consideration.
when we are in problem mode, the problem manager is empowered to get other team members to work on the problem - we used the words "the problem manager has authority to action other team" which they thought was too strong.
the objectives we proposed will improve focus on Incident Management, but we will need to make sure it is in balance with Project Management activities.

So we can carry on with our recommendations. I need to organize a presentation to the CIO, have the necessary changes built in the tool, prepare communication & training, and make sure the sponsors drill down the message through the hierarchy. We've got two months left only!

2006-04-19T14:36:00.000-07:00

Preparing the presentation to our sponsors about "Incident Management Basics"

OK. The workshops we did to find out how we could improve our situation with Incident Management were fruitful. But now I had to prepare the "*ç%## presentation of these basics to our sponsors. The participants said we could just throw the whole project away if the sponsors did not stand for the approach, and push themselves the message to their direct reports. Talking of a challenge!

So I went on, prepared some kind of summary of the workshop, and thought that would be good enough. Nope. I presented that to couple of colleagues, and consultants who were walking around. "Too many details" they said. "What's the point? What do you expect from the sponsors with this? What is the impact on the organization? What's the plan?" Duh!

Here's how I fixed it (thanks to the help of one of these Cambridge Technology Partners consultant):

- trimmed some leaves, and keep them as backup slides (that was the easy part)

- tried to have logic like: facts => findings => recommendations => effort estimates => conclusions. Actually that was quite effective! The hardest part was to recover the facts, findings and benefits, while I had only laid down the recommendations at first, and while trying to keep the spirit of the workshop participants, so they still back me up at the presentation!

- finally understood the concept of have a Title, then a summary, then the rest of the slide. I thought that I was doing a great job with this summary:

I am a fan of ITIL
The reasons why I like ITIL
- ITIL is cool
- ITIL is hot
- ITIL is fun
- Cool people like ITIL

While a more useful summary would rather be:

I am a fan of ITIL
I like it because it is cool, hot and fun, and I'm cool too
- ITIL is cool
- ITIL is hot
- ITIL is fun
- Cool people like ITIL

The great thing with the correct summary, is that people can stick with just reading the title and the summary sentence. You can go on with details below the summary, but you have to make your point in a few words right at the beginning of the slide. Highly efficient! Guess I'll have to do that in my blog now!

Now I'm checking out that the presentation is still reflecting the participants intentions. First echoes on the reviewed presentation are excellent... On Tuesday, we'll be presenting it to two of our sponsors...

2006-04-09T12:09:00.000-07:00

Outcome of the 3 half day workshops on the basics Incident Management.

Last week was a great week :D The 3 workshops we had with representatives from each IS support groups were very fruitful. We agreed on the basics (same as detailed 2 weeks ago), with very few variations, and on how to make the change happen. Everyone was really excited about the topic - they sounded like "true? we're gonna get this?" We also agreed on how to prioritize Incidents, and on how Incidents that are now resolved in time would be escalated.

The best part of the workshops happened while we were trying to find out how to successfully roll out these "Incident Management basics"... We knew it would require strong management support (sounds like a no brainer)... but... how could we get the sponsors to actually support the change? Here's what the team came up with: the sponsors or the IT Vice President himself should present the Incident Management basics to the managers. That way, it won't be the project or the project manager trying to get the change through. It will be the top management telling their team what they want them to do. This is different. I complained to the team: while I was feeling comfortable instructing all IS employees on what habits they would need to change, convincing the sponsors that they would need to present it themselves sounded like another challenge. The whole team quickly replied they would stand by me to present the basic principles to the sponsors (and the VP if possible), and ask them to proceed that way! The afternoon after the 3rd workshop, I've immediately setup a meeting with the whole team and one of the two sponsors in two weeks (he wasn't extremely interested, but accepted the meeting anyway). I'll try to organize the same with the VP and the other sponsor if I can...

Now I need to pack the workshop recommendations together into something that can be easely presented to the sponsors (and the VP?), massage it with the team and some managers, and jump to the next step!

In parallel, we also need to progress on the other intiatives...

2006-03-26T11:48:00.000-08:00

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:

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.
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!)
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!
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)
etc

Next weeks

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

2006-03-11T05:02:00.000-08:00

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.

2006-02-23T12:18:00.000-08:00

Here's how our Incident Management project was announced to the IT staff...

First, it was mentionned at a staff meeting (PC support and Sysops) at the same time as 4 other projects. In 2 minutes max, the sponsor (who had almost forgot to mention it) described it as "more enhancements to the Service Desk tool, and improvements to the escalation process." Not exactly in line with the message I would like to convey - this is a real "process improvement project", that will require staff and managers to change their habits in order to better serve our customers - but that was already better than nothing :D

Actually, to me the objective of the first announcement was only to see if the sponsor was ready to talk about it public. And give the project some exposure.

Then, and that's the better part, it got announced to all the IT staff via an internal IS news a few days later, with details on goals, scope, schedule, project team, along with a link to a full presentation of the project. The announcement was prepared by me but signed by both sponsors.

The goal of that second annoncement was twofolds: display the sponsors' commitment, and let IT staff know that they are going to be involved and impacted.

As many people were on vacation, I could not get much feedback then, out of the encouragements from the colleagues who know how much I have been lobbying for this project! We'll see if the announcement has reached its goal when we do the kickoff meeting in 2 weeks, and when we try to get people collaborate for the design and deployment of the improvements...

2006-02-20T13:38:00.000-08:00

Finally, our Incident Management ITIL project got announced in IT!

But half of the IS staff os on vacation next two weeks... I'm going to have to wait for their return for the official kickoff meeting. At least we can officially get some initiatives started :D

2006-02-06T14:45:00.000-08:00

I've got the second approval for our ITIL Incident Management project!

The first sponsor was allocating my time and consulting money. The second sponsor was allocating 50% of a colleague's time. Also, together, these two sponsors represent 100% of our support and operation groups! So we're starting tomorrow...

The good thing with this time spent gathering signatures and approvals is that it forced the sponsors to stand up for the project and take ownership. It will probably last for a little while... gotta hurry now, and prove that they get the expected return on investment!

2006-02-05T13:36:00.000-08:00

How we built ITIL awareness in our company

As the formal acceptance of the project will still take some time, here's something to keep you interested: how we built ITIL awareness in our company.

As interest for ITIL was starting to show up, we tried a few initiatives to grow the overall awareness... We had a half success. Here's what we did, and how it worked out.

First initiative: 2 days of custom made "Introduction to ITIL" sessions

Internally sponsored by: the quality management guy.

Provided by: one of our suppliers, who had a great experience of ITIL, but who were usually not selling ITIL consulting.

Content: First day was an express walkthrough ITIL processes. Interesting for the ones who had a clue. Not interesting to the others. It was too brief to get them to understand how these best practices in Service Management could really apply to us. They felt we were soooo different it wouldn't be of much help.

The second day was exposing the difficulties, pitfalls, methods on implementing ITIL. When the first day did not convince anyone, the second day only raised more questions and doubts.

Result: I have heard of some successful "Introduction to ITIL" sessions. Ours was certainly not one of them.

Why it failed: One of the reasons for that failure could be that the sponsor of these sessions was totally outside of the "operational field". The managers in charge of operations who were not interested found not interest in what quality was trying to sell to them. Another explanation could be that that initiative was outside of any project. It was kinda linke "Here's ITIL, guys!"-"So what?" Last, you'll probably have a better "Introduction to ITIL" session from a consultant who is used to that kind of exercise. Not from one who does it for the first time, just for you.
Second initiative: ITIL foundation training for all the Service Desk, PC support and local support internal employees. Proposed to any other IT employee if they wish to attend.

Internally sponsored by: The manager in charge of these 3 groups.

Provided by: Pink elephant, or local companies.

Content: That was for sure a better call than the Introduction to ITIL custom made sessions. ITIL foundation training not only helps setup a common language, but also gives a real flavor of the Service Management disciplines.

Result: Mixed. It surely helped setup the common language. It clarified the concepts for the ones who were interested in the first place. But that's not enough. Were we were hoping that managers would magically start initiatives to improve their processes on their own?Did we think they would start to act closer to the best practices because they had heard the good word of ITIL?

Tentative explanation: To get the most of an ITIL foundation course, you should have a project setup in the first place. Only the project will allow a transition from theory to practice. The project makes it happen. The course is just one of the tools used by the project. Also, people know why they are attending these courses then!

So what?

Even if I sound very sceptical about all our efforts, in the end, it still helped us grow. Least you can do is send to the ITIL foundation course all the managers who are interested in the first place - skip the others if there is no project or strong sponsorship. Then, the ITIL fans will be in a much better position to spread the word...

2006-02-01T05:07:00.000-08:00

I got the first signature for our Incident Management project!

2006-01-30T10:23:00.000-08:00

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!

2006-01-27T14:44:00.000-08:00

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 ;-) )

2006-01-19T12:46:00.000-08:00

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!

2006-01-18T12:10:00.000-08:00

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!

2006-01-17T02:31:00.000-08:00

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.

2006-01-17T02:05:00.000-08:00

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

2006-01-13T03:45:00.000-08:00

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

2006-01-12T08:23:00.000-08:00

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

2006-01-11T15:20:00.000-08:00

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

2006-01-10T14:29:00.000-08:00

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!