Remember to upgrade the staff as well and not only the technology

When launching a new technology or initiative, companies are prepared to spend thousands or even millions on new infrastructure. We are buying this new super duper software package so, we need to spend all this money to upgrade to faster computer hardware and other new infrastructure. One thing management tends to forget is that new technology or initiatives needs to go hand in hand with appropriate new processes and skilled people. You may be sitting with a very expensive pile of CD’s gathering dust and bringing you nowhere if you do not make the effort to upgrade your people and processes as well. People are a company’s most important assets, but still a lot of managers are very reluctant to train their staff adequately. They will rather spend the money on infrastructure and overpaid consultants. The problem is that these very expensive software tools are not used to the fullest capacity if at all when people are not properly trained on how to use it.

Well, I have seen these mistakes made numerous times and it is costing companies millions. It must be that people like to shop for physical things they can see and touch instead of buying “invisible” items like training.

How do you eat an elephant?

When pursuing the ITIL road, it may seem like a daunting task, just too much work and difficult to be worthwhile. This is where patience comes in to play. Like the saying goes: “How do you eat an elephant? A byte at a time.” You just have to plan carefully and be patient. When you have limited resources, you just have to start small. The key however is just to start somewhere and keep on going without stopping. You can start by implementing one process at a time. Break it down even further by limiting it to only certain departments or parts of the IT infrastructure.

You have to set milestones in your project plan and then keep to it. It is also very important to build quick wins into your plan. If you can start to show benefits at an early stage, it will keep people, including yourself motivated. Some of the cynics might also jump on the bandwagon when they see early benefits, giving you more traction to move faster.

If you just start somewhere, it does not matter how small; it will also give you a chance to put theory into practice. Then you will be able to see what works and what does not. People sometime tend to go too deep into the theory and might even go into an paralysis by analysis. The sooner you start to chow on this ITIL elephant, the sooner you will realise benefits and get more support (and resources) from the business. Just remember to start at the beginning which is to put the human resources in place and then train them. For example, if you start with Incident management, get the incident manager on board right from the start. Send him or her on a formal ITIL course so that everybody speaks the same language and that valuable input can be given during the planning phase. This way you ensure that the person who will be responsible for making the process happen buys in right from the start.

If you don’t measure it, you cannot manage it.

If you don’t measure it, you cannot manage it. If you cannot manage it, you cannot improve it. Not having a process and tool to measure your IT department’s performance, is like an athlete not having a stopwatch to measure how fast he goes around the track. The athlete will not be able to know his weak points where he needs improvement, if he does not measure his performance. He will also not be able to know if his performance improves or degrades over time, without using a stopwatch and recording the times.

If something as simple as running around a track uses a system of measuring and recording to continuously improves, why are so many IT departments not doing the same thing?

Once you have a mature process and are able to measure the output of the process, you can start to apply quality improvement methodologies. A well known methodology is the Deming cycle, which is a continuous circle of planning, doing, checking and acting. First you plane the process that needs to be followed, and then you get the people to follow it (do). When people follow the process you can measure it (check). The measurements will be used to make informed decisions to act upon to ensure continuous improvement.

We have kicked off a weekly change management meeting to make sure our change process keeps on improving. In this meeting, we look at the success rate of the past week’s changes and how well changes were planned by comparing planned dates and times with actual dates and times. We also discuss the process itself to see where improvements can be made to streamline it. During this meeting, the tools are also discussed to look at ways to make them easier and more useful. It might be good to have a tool that can be customised to a certain extent, so that you can make it work the way you want it to work.

To conclude, managing IT services without a structured process based approach like ITIL, is like an 800m athlete not knowing how far 800m is and without a stopwatch.

Enabling continuous improvement with ITIL.

One of the major benefits, if not THE benefit of process orientated approaches to managing your IT services and infrastructure is that it enables continuous improvement.

This means that you are never totally satisfied with thee current state of affairs and that you always want to improve your services. I mean, it is the way life is to always set higher standards or aim for higher goals, otherwise life can become a little boring.

The reason why ITIL enables continuous improvement is that it allows you to start measuring everything you do. That is why it is so important to record everything. Technical people normally hate it to do documentation and even worse, they hate it to document everything they do, while they have more important stuff to attend to like fixing a critical server. The benefit of having everything recorded outweighs the hassle of recording it by far. Unfortunately it usually takes a while to realise these benefits which make it even more difficult to get the techies recording the stuff. There are of course several positive ways of getting them to do it, but I will not go into all of that right now.

Anyway, now that you have everybody following a strict process an recording everything they do, you can start measuring everything. By measuring it, you can make informed decisions and take actions to improve it. To be continued…

Where do we start with ITIL?

The ITIL Community Forum Forums-viewtopic-Order of Implementation

From the above forum you will see that everybody has a different take on this. I also have my own views, unfortunately different ones from my employer...

In the above forum, one suggestion is made to start with Service Level Management. Theoretically, it would be the perfect option, but how are you going to negotiate SLA's on your MTTR (Mean Time To Repair) if you are not measuring your MTTR through Incident management to have an idea of your capabilities and of what a realistic MTTR would be for your support teams. It may however be a good idea to start with a Service Catalogue, but that is only an aspect of Service Level Management and not a process.

A lot of people believes that one must start with Configuration management. Again, my believes are that it would be perfect in theory, but in practice it is a different story. How will you keep your CMDB up to date, if you do not have a mature enough Change management process to keep the data up to date? A discovery tool will help, but there are still information that may need manual updates via Change management, e.g. costs, locations, users asset tag nr's etc. Configuration management is aslo one of the most difficult processes in my mind, that is if you want to do it properly...

The best place to start in my opinion is with Change Management. Gartner reports that 80% of infrastructure failures are caused by changes. So, if you can have ALL your changes under control as soon as possible, a lot of these failures will be prevented. That is defnitely a quick win and quick wins is what you want to keep the motivation of support teams up and keep upper manageemnt committed to your project. It may be a while to realise the benefits of Service Level Management or Configuration Management.

A good one would also be Incident Management, it is a fairly easy process and it is also good to start with easier processes so that everybody get's a chance to learn as they go along.

When Change and Incident management are well on their ways you can start to look at the other processes, especially on the Service Support side...

Oh yes and obviously you will need a Service Desk right from the start...

My take on where not to start...

Problem Management - Can't have it without Incident Management

Configuration Management - CMDB will be out of date in no time without Change Management.

Service Level Management - Can start certain aspects, but no baseline without Incident and Change Management to negotiat SLA's with the customer.

IT Service Continuity Management - Difficult and expensive, no quick wins, good to have the CMDB first... Don't get me wrong, it IS important, but not my suggested place to start.

Release Management - You preferably need Change Management first.

Available & Capacity management - Possible to start with, but no real quick wins and more difficult...the ITIL books really get theoretical on these guys and even a bit abstract.

Well, these are only my views, whether you agree or not.....

The Importance of Process Owners

Another factor I soon realised is very important to the successful implementation of ITIL, is to have dedicated, trained and committed process owners.
If you want to have a successful Incident Management process which improves all the time, you will need somebody who is ultimately responsible for the success and who can dedicate the time and focus to drive it and to make sure it actually happens. A lot of organisations, including ours makes one of the following mistakes:

The process owner is non- existent which means, nobody dedicated to drive a particular process.
There is a process owner, but he is bogged down in day to day reactive activities or other "more important" business-driven projects and thus have no time for unneccessary "red tape" like ITIL.
There is more than on process owner for a particular process - a classic mistake. The idea of ITIL is to have a single consistent process throughout the organisation and having to head cooks in this "process kitchen" is sure to mess up the cake. Who will ultimately be responsible if there are more than one owner. At the ITIL implementation at the Korean company I referred to earlier on, they appointed one process owner per process who overseas the particular process over all it's 32 international divisions. This ensure, that the process is consistent troughout all 32 divisions.

The big problem here, is that companies to do want to spend the money on dedicate resources for process owners...obviously a process owner can have a split role, doing other work as well, especially in smaller companies...as long as that other role is not of a reactive firefighting nature. One person can also be made responsible for more than one process. Although these processes should be of similar focus. The Change, Configuration and Release roles can be shared by one person in small companies for example. I believe in large corporates these roles should be fulfilled by dedicated people, and companies who does not fill these roles are not serious enough about ITIL and is most probably lacking the management commitment.

Here at my company we ar trying to convince management that these roles needs to be filled...I think we will get there...eventually...I will keep you posted.

Management Commitment

In my opinion, one of the most critical success factors for implementing ITIL, is Management Commitment... If you are responsible for an ITIL implementation, make sure you have commitement from the top, otherwise ITIL might just become another failed IT project throwing time and moeny down the drain.
And management commitment does not mean, "the manager says his committed". The manager must walk and talk ITIL and continuously show his commitment.
In practical terms this means empowering staff through professional training, tools etc., appointing the right people in the right roles and managing by means of ITIL, e.g. demanding the right reports and taking action...
Kotter's 8 steps to organisational change is actually a good guideline for top management to follow...

Well, management commitment is probably the most important success factor for ITIL, but in my experience, probably also the most difficult to find.... that is why a lot of ITIL implementations just become a black hole sucking up money.
I think there are a lot of IT managers that is under this misconception, that ITIL is a silver bullet to fix all their problems....Just install ITIL (almost like installing a new server) and everything will be OK..... What they do not understand is that ITIL is a major organisational change, including a culture changes. We used to focus only on technology, but now we have to focus on the customer.

Another reason for low manageemnt commitment is also that ITIL is usually an internal IT department endeavour and not a direct requirement from the business....ITIL is a methodology for improving IT and not as such "the business".
To overcome this, an ITIL project should become a business requirement and commitment is needed from all the way to the top, from the CEO.

I recently attended a conference where the speaker was involved in a succesfull ITIL implementation at a major electronics company in Korea. The reason why they implemented ITIL, is because the company's vision is to follow best practices throughout the company in whatever they do, including IT, no matter what it takes...

MOF, ITIL and more of me

As some of you probably know, MOF is Microsoft’s version of ITIL. They basically took ITIL and added their own Microsoft flavour to it. I would not like to go into too much detail on what MOF is here, but if you are interested you can find out more at www.microsoft.com/mof. The 1st version of MOF I came across was very confusing to me. I knew I was on the right track for finding the key to managing IT services, but it definitely was not this version of MOF. Luckily, it was not too long before I came across ITIL. I cannot exactly remember where. I think it was from an article on the Internet talking about MOF and ITIL.

I soon realised that ITIL was the solution to our problems, although I only had a vague idea at that stage what it was about. I became very interested in the topic and read anything on ITIL I could find on the Internet. I bought the book, An Introduction to Service Management by Jan van Bon which I found to be a great introduction. Although, a lot of people might be bored with all the theory. I was ready to pave my way to a successful IT support department using ITIL.

Unfortunately, the company I was working for went into a process of restructuring and downsizing. I think too many other companies was riding the same Internet tidal wave. I was not part of the new structure, so I was one of the chosen few who had to leave. I never had the chance to open the door to my IT department’s potential with my newly acquired key. Luckily, a month after I left I got appointed at a large retailer who needed help in improving their IT processes. I was very excited, as finally I got a chance to implement ITIL in practice.

My background and why I chose ITIL

Computers have been my passion since an early age. I graduated with an electronics engineering degree, but when I finally found a job, I ended up in a computer technical support department cleaning mouse balls and keyboards. Wel, at least I was working with computers...my passion. Luckily, the company I worked for had lots of opportunities in IT and just before I was on the edge of insanity of doing technical support, I got involved in some interesting IT projects. One interesting project after the other followed, including the rollout of large financial systems and large Internet portals. Well, some of the Internet portals were meant to be large, but after the dot bomb, the only thing that was large about it was the expensive infrastructure it was running on.

I moved on and later became the IT support manager of an E-Commerce outsourcing company that was growing at the same rate as the Internet. This was very exciting, as it felt if we were on top of the Internet tidalwave and riding right along with it. Being the IT support manager was even more exciting, as I had all this new technology to implement and manage and being a fairly small company, me and my team of seven guys could fairly easily keep everything under control.

This control did not last for too long. When the company started to expand really quickly in our everchanging dynamic environment, we started to run into problems just too often. If it was'nt an unhappy user who waited more than 2 days for an outstanding issue, it was the mail server that ran out of capacity and then went down for 2 days becuase of an unplanned change. Blaming staretd to become part of our culture and the dynamic environment was not that much fun anymore.

I had to find a solution to this chaos, but coming out of environments where IT support was only reactive and processes were shot down as a total waste of time, I did not really have the answer. That was until I attended a Microsoft seminar on MOF or the Microsoft Operations Framework. I was not sure if it would hold the solution to our problems, but I was willing to find out.

Who, Why, What?

Hi, my name is Arnold and I decided to start a blog on an ITIL implementation. I am currently working in the IT department of a large retail company. The company wants to improve their IT services and decided to implement ITIL best practices. I report to the IT services manager and my main responsibility is to plan and coordinate the implementation of ITIL.

For those who are not familiar with the term ITIL and perhaps ended up here by accident….ITIL stands for the Information Technology Infrastructure Library and it is basically the most widely adopted best practice guideline for managing IT services. But this blog is not here to explain what ITIL is and how it works; there are more than enough sites out there that can tell you that. A good one being www.itilcommmunity.com There you can find a good overview on what ITIL is about as well as information on other sources like ITIL training.

The reason I started this blog is to keep a journal of an ITIL implementation and to share my experiences with like minded people. There is a lot of information on the web, especially theoretical information on ITIL, but it is sometimes difficult to bring the theoretical and practical sides together. Most case studies, usually does not go into the nitty gritty details of an actual implementation. In this blog, I hope to discuss some of the practical challenges we face in implementing ITIL and how we overcame it. I will update my experiences with the implementation on a regular basis as we work on the project. I hope this blog can be of some assistance to you if you plan to implement ITIL and that you may learn from my mistakes and to prevent you from reinventing some wheels.

Next time I will expand a bit more on my own background and why I think ITIL is great.