Chris Dancy of ServiceSphere (@servicesphere on Twitter) tweeted this excellent 10 page (PDF) Executive Overview of IT Service Management (ITSM) and ITIL.

The PDF contains a succinct, and brief overview of the benefits of improving IT Service Management, with some easy to understand demonstrations of visual signs of poor ITSM.

If you are an executive wondering what the fuss is about with ITIL and ITSM, this document is a great summary.

Note, if you have been following this blog for a while, you will note some terminology changes compared to what I have written. This is simply because my experience has been with Version 2 of the ITIL framework, and this document summarizes ITIL utilizing the newer process terminology contained within Version 3 of the framework.

If you are looking into ITIL, I highly recommend checking out ServiceSphere at the above link, on twitter too!


Resistance To ITIL?

February 12, 2010

Resistance? To ITIL?

That can’t be true!

Everyone knows ITIL processes can improve IT service support and delivery costs, improve internal IT service management processes, and even make coffee in the morning!

You can laugh now! Everyone does not know that ITIL can improve internal IT processes. (OK, the part about coffee is untrue as well!)

But for SME’s looking at ITIL, first, it is a journey. And like all journey’s it involves change in the way people work, and changes in what they may be responsible or accountable for. And like any change, we as humans can resist change when we don’t understand the WIIFM. (What’s In It For Me?)

Along that concept, Ann All at ITBusiness Edge has a great article that I want to pull two bits from.

First, your IT team may be as resistant (or more so) to change as anybody else in your organization.  For some technology staffers, it may simply be not understanding the business implications about what ITIL can provide. And for some it may be because they are addicted to the glory of heroic  IT acrobatics, after all, avoiding any incidents or problems in the first place is hardly glamorous. And some technology staff can simply see it as an unnecessary inhibitor or overhead to their getting real work done.

The warning here is that an announcement that ITIL is going to happen on Friday! – Sorry, that won’t work. Like any organizational change this journey will be slow, require 10 times the communication that you thought necessary, and has to be taken in small, incremental steps. (You can try to do it all at once, but unless your teams and your people thrive on ripping the guts out of your business and rebuilding it from the ground up, you will have a hard time of it)

The second piece I wanted to emphasize, is that implementing ITIL processes are not an all or nothing exercise. I know that I have written a lot about this, but here is one excellent example. As the article referenced above states about one journey into ITIL;

… didn’t invest in a new tool until nearly three years into its ITIL initiative,

It is not all or nothing.

People, process then finally tools.

They built their methodology in bite sized pieces, then started looking at service management software tools to help them.

Not the other way around.

You can get updates to this blog by clicking the RSS icon on the Home Page!

ITIL,SaaS, And Blood Red

December 29, 2009

Confession, When I read the post I reference below, the title reminded me of a tune by a fave band of mine, the BoDeans, So I stole the title for this post from a song of theirs titled; Black, White and Blood Red.

Anyway, I have written before that ITIL is a framework of best practices, it is not a follow the dots prescription that every business can use to do things the same way.

As a rough analogy, a recipe presents you with each ingredient, their order of mixing and a required temperature that will provide a consistent result for everybody that uses it. Whereas the ITIL processes present a recommended end state, with some guidance on methods that can help achieve it, but like a football game, the individual plays can be different for each business.

In this post titled SaaS and ITSM – a Marriage Made in Acronym Heaven? Stephen Mann takes a fairly deep look at some research on the delivery of IT Service Management (ITSM) via Software as a Service (SaaS) rather than on premise tool sets.

Note that if you are just getting your feet wet improving ITSM, Mr. Mann’s post is pretty high level. However he presents one good lesson I never thought of, that lesson is that since every business may have a different ITIL path that they are following, care has to be taken when choosing tool sets that the tool can fit your internal processes. As Mr. Mann states;

In Butler Group’s opinion, a SaaS solution must be architected such that the customer is able to self-customise its ‘application instance’ (to reflect in-house processes)

This is a good thing to watch for as beginning a journey towards improving ITSM is hard enough working on improving your own processes, without adding the complexity of being forced into someone elses process models.

UPDATE: Christopher Dancy pointed to a much more in depth look at SaaS & ITIL here;

You can get updates to this blog by clicking the RSS icon on the Home Page!

The Definition Of Insanity

November 19, 2009

Can be defined as doing the same thing, the same way every time, and expecting the results to change. (try W. Edwards Demings’ red bead experiment!)

Building a process oriented business is not a set it and forget it operation. It is defining and monitoring the desired outcomes. And identifying that if a desired outcome does not happen, that you have an opportunity for improvement.

In other words, if the desired outcome fails, what can we do to reduce the risk that it will fail next time?

In talking about process, you need to look specifically at what breaks. You need to look at the why, and the how of what went wrong. Is it a people problem? A process problem? or a system problem?

(within the context of ITIL I give some samples starting in this post titled; ITIL And The SMB Part 3; Incident Management)

Although please note that you do not need to go the ITIL route to become more process oriented.

It can be easy to overlook;

When something fails, there is an associated cost. That cost could be rework, lost time, maybe even lost business. Costs can be soft as well, for example, reduced customer satisfaction.

As an example of improving process efficiency, the large package delivery companies load their trucks in a first-in, last-out manner based on the drivers delivery route. This simple step reduces the amount of time finding the correct packages for offload at each stop, and reduces the risk of missing something. And of course missing packages can negatively affect customer satisfaction.

The More Things Stay The Same

When you start building a process oriented business (not just as an IT function) there are two critical pieces to start with;

1) Define the optimum outcomes. A process is nothing without a business outcome. This defined business outcome is also the measure that you can use to improve and monitor your processes.

2) Continually monitor and improve your processes. There are always opportunities for improvement. There is an old saying in music, that the spaces between the notes are just as important as the notes themselves.

The SMB Takeaway

Like the spaces between the notes, process optimization often comes hidden in the areas as work migrates from one individual or group to another.

Improving them, or identifying why something did not work, you need to understand – you need to look at the what the why and the how of what you are trying to perform.

Was it a person error? a process error? a system error?

You can get updates to this blog by clicking the RSS icon on the Home Page!

Two, well, let me say, rather disconnected events spurred this post!

An Accident That Never Was

First, on the way into work last week I was almost smacked pretty nicely by a 5 Ton truck. It definitely would have been at least a tow truck type accident.

On my local highway there is a point where two highways join (for anyone in Ottawa reading this – the “split” at 174 and 417), and during rush hour, that point comes to dead stop. The truck was behind me on the fast portion – I was watching him in the rear view and saw that he was signaling to get into the right lanes, I could also see that he was looking in his side mirrors. Of course I could also see traffic in front of me was at a standstill. Inertia being what it is, I knew he could not make that lane change or stop in time.

So I wiggled my little car onto the left hand shoulder, right up against the guardrail and actually drove up beside the car that should have been in front of me. I got a funny look from that driver! – but figured that he was just not as observant as I was! Sure enough, that 5 ton got stopped – but close enough to both of our automotive back sides that I had still been behind that other car, it would have been a spectacular surprise and curse fest for all.


There was a bit of adrenaline rush, but it was a non-event. Nothing happened. No emergency; and no spectators. We all continued on towards our destinations.

It reminded me (I should amend that, after the adrenaline rush wore off!) of a discussion I previously had with the president of the company I work for. That conversation was about how aligning along ITIL lines with process and financial discipline had reduced both our IT costs, and the (very) large amount of outages and service failures that we had been having when I joined them.

During that talk, he made the comment; How soon we forget…

The SMB Takeaway

According to the film and television industry – arsonists often stay to watch the fires they start.

I am not stating that your IT staff or suppliers are deliberately setting fires; but if there seems to be too many heroic incidents battling flames and smoke!… (OK, OK dead servers and the like) You should start asking questions.

Because like an accident that never happened, you should not see anything at all. It is not sexy or glamorous, there are no flashing lights or sirens.

But at the end of the day – isn’t that what we want?

PS: I forgot to mention, my car is just over 1 week old – if I had got smacked, I really, really, really would have been pissed!

You can get updates to this blog by clicking the RSS icon on the Home Page!

Photo Credit jaxxon via flickr

Parts 1 and 2 of this provided a quick overview of ITIL, and the basics of Configuration Management.

In this one, I will take the same overview of the ITIL Incident Management process. As stated in the earlier posts, all of the ITIL processes are tightly linked, as each process generally accepts information from, and provides information to the others. However pieces can be lifted and customized for your environment. As quoted in this CIO article;

All one has to do is purchase a set of ITIL books, and adopt whatever ITIL practices one wishes.

Again, the goal here is to demonstrate how the basics of ITIL can assist organizations of all sizes reduce costs.

Incident Management VS. Problem Management

The ITIL Incident Management process and Problem Management process can seem to be the “same” at first glance, however there are key differences.

Incidents are deviations from expected operations, and Problems are the root cause of those deviations.

Problem Management will be covered in a later post. However, as a non technical example, lets imagine that you are a distributor, and you have 15 customers that did not get their orders on time. That is 15 incidents, the issue was that your delivery truck broke down – that is the “problem” So in this case, one problem maps to 15 incidents.

In your technology infrastructure, Incidents are then any issues that provide a loss of service; “email not working”, “can’t print invoice”, etc. Larger organizations will most likely track these incidents through standard “Help Desk” type tools, in smaller organizations it can be as simple as a spreadsheet.

This tracking of incidents is the key point in the Incident Management process. whether you are a 10 person shop or 100. Ensure that someone is responsible for ensuring that these are documented. And that includes the typical “Oh wait while you are here, this has not been working…” type requests, these happen all the time.

Having these incidents, and their resolutions, documented will provide visibility into the IT service response you are receiving, either by your own staff, or by contracted staff. And provides improved monitoring of what was performed and why.

The Benfit

Documenting these incidents will have further benefit that I will describe in Problem Management, but on its own, you will have;

– visibility into the issues (incidents) that are ocurring
– reduced business impact through visibility into the timely resolution of incidents
– Better staff utilization through better coordination of effort
– Getting rid of incidents that are lost or “fall through the cracks”

A small business that I have previously referenced on my site, had gone through two outsourced IT services organizations and were on their third. The first two just “were not acceptable, … poor service” etc.

But like most small businesses, if someone had a problem, they called the provider, who then responded and was to take care of the problem, and then sent an invoice. However the “perception” was always negative. And without concrete information, neither they or their providers really have any evidence on way or the other.

My recommendation? Have one person responsible for the calls, document the issue (incident) and document when it was fixed.

The immediate benefit?

Was it fixed? – yes or no
Was it fixed quickly? – yes or no
was the number of incidents equal to what is appearing on that invoice? yes or no – and why?

The concept of these processes is very simple, the discipline required in ensuring that it happens is the hardest part.

UPDATE: Part 4 is now here:

You can subscribe to this blog by clicking the RSS icon on the Home Page!

As mentioned in part 1 on this site, The ITIL framework is an effective method of reducing the costs of IT service delivery, and improving the quality of IT services.

As can be seen here ITIL is not just for large businesses. Adopting the ITIL framework reduces IT service costs, and increases IT effectiveness for organizations of all sizes. As stated in part 1 of this note, and seconded here the ITIL framework allows you to lift pieces that are specific to your unique environment.

In this post I am going to dive a little deeper into the ITIL Configuration Management process. Larger organizations may find that a blended look at configuration management, incident management and change management together provide the best benefit. If you are at the larger end of the medium business space (i.e. approaching 100 Million revenue) you may be best served by this as well.

Configuration Management – The Benefit

However, I have found that the configuration management process by itself can pay dividends to businesses at the smaller end of the scale. (ie 50 Million and less). The payback comes from reducing the hidden costs of IT services. These hidden costs can include;

– Re-inventing the wheel – hours are spent configuring or building an IT asset, you should not have to waste those hours doing it all over again.

– Efficient and Effective problem solving. your IT resources – either in house or contract. You are paying them to fix something in your environment, not to learn what the environment is first.

– Continuity planing, outages cost money. The difference in the time to recovery can mean the difference between minutes and hours (or days)

– Improve expenditure planning (ie software licensing, and capital expenses)

At the simplest, configuration management is ensuring that accurate documentation exists on all server, and device configurations. Consider it a check list or road map for documenting that asset. This documentation should be of a sufficient level of detail that a person with expected knowlege of that technology can rebuild or recreate that IT assets configuration from the ground up with no other data needed.

Second, configuration management demands that you look at, and document, the end to end configuration of all IT assets and services. For example, you may have an E-mail server that has a fully documented configuration, but the IT “service” of E-mail is not one single server. The “E-Mail service” encompasses every point from someones desktop, through any switches, routers, firewalls or other devices to the email server. (As an analogy, think of an electrical wiring diagram, or the assembly instructions for some piece of assemble it yourself furniture)

Configuration Management – The Example

Consider this all to common scenario; An IT technician has previously modified, but had not documented, the IT infrastructure to allow your web mail, and Blackberry Enterprise Server to work correctly with your E-Mail server. A few months later another technician, not realizing why the changes are there, reverses them, causing interruptions of service. In this case the configuration management process should have documented the relationships of every device and server that produces the “e-mail service”. Whether it is via web mail, or your Blackberry device.

Another example that I ran into a number of years ago, a larger organization had an engineering and testing network dedicated to load and performance testing of network infrastructure hardware. In other words, this network was deliberately designed to push the limits of network devices. An IT technician made a change in the firewall rules that was preventing this testing environment from impacting the regular production network, this change allowed the test data to start flooding the production network with this engineering test data. It took a couple of days for me with the assistance of a skilled network “sniffer” analyst to decipher the problem. Proper documentation of the correct rules and their reasons would not allowed this incident to occur. (or allowed it to quickly reversed)

The Configuration Management “database” is a key component of the ITIL framework for documenting these dependencies. In the larger organizations, there are many vendors willing to sell you these Configuration Management Databases, or “CMDB’s”. In the smaller end of the SMB space this documentation can be contained in any format or tool that you may have. The key is to keep it current and enforce its use.

This Configuration management database should include all relationships associated with the asset or Configuration Item (CI) including any software, procedures service levels and usage. This CMDB documentation will be used for improving the management of all other ITIL processes, and as such must be regularly audited for accuracy. It is not a static piece of information, but a dynamic document that must be immediately updated with any changes to the IT environment. These updates could include new software or tools installed, new security permissions or groups, down to the installation of new IT assets.

UPDATE: Part 3 is now here.

You can subscribe to this blog by clicking the RSS icon on the Home Page!