The ones that infuriate me are those that map ITIL keywords to discrete features of their product; with varying degrees of compliance with the actual meaning of the word: “Oooh! Oooh! IT Continuity. We do that. The administrator can do a backup."

ITIL is technology-agnostic. You can do ITIL with Post-it notes, and the way things are going it won’t be long before 3M are advertising Post-it notes as “ITIL compliant."

The fact is vendors are full of it when it comes to ITIL. It is far too easy to slap the word "ITIL" on an operations tool. This only serves to debase what ITIL means and to confuse the community (I've got more to say about the debasement of terminology at my blog).

You can sympathize with the vendors (as much as one can). They can hardly ignore ITIL, yet OGC and itSMF both let an opportunity slip by when they ignored product compliance. No doubt they had good reasons for standing aloof from the whole sordid business but they have left unregulated an area that cries out for some control.

Today, there is no formal independent certification of ITIL compliance for tools. Pink Elephant provides PinkVerify commercial licensed certification but, in my experience, this is not a good indicator of compliance to some of the criteria that follows.

OGC set up individual professional certification early on, and now finally ISO/IEC has given us organisational certification (the 20000 standard). The product vendors have no choice but to make their own claims, and nowhere to go other than Pink to verify them in the event their claims are in fact correct.

But it seems to me there are some obvious criteria for a reasonable person's definition of “ITIL compliant." So if you adopt ITIL, ask your prospective vendor these questions about their supposedly ITIL-compliant or ITIL-supporting tool (including some PinkVerified ones):

Who says it is compliant or that it supports ITIL? To what maturity and in what capabilities? Just because they think it supports Incident Management at maturity Level 2 is of little relevance if you need a service level management tool to get you to maturity 4.

How many of their product designers are certified ITIL masters? Is the chief product architect? If none, then who are the ITIL masters who consult on design? Ask for a conference call to discuss compliance.

Just because your vendor uses ITIL terminology that does not mean they support ITIL. The ITIL processes are clearly defined in the red and blue books. If it doesn’t work to these processes (and a wide range of the variants that arise at implementation) it doesn’t support ITIL. It is too easy to change the words on a few screens and declare compliance.

Part of the benefit of any standard framework is standard terms, so that new staff, service providers, auditors, trainers and contractors can all quickly understand your organisation and communicate clearly. So it is not OK if an incident is called something other than an incident (especially if an incident is called a problem and a problem is called a fault). Confusion will be endless. Suddenly every vendor has ITIL. Most IT operational tools claim to “support ITIL” or to be “ITIL compliant." Recently one vendor announced they are seeking “ITIL certification,” no less.

The ones that infuriate me are those that map ITIL keywords to discrete features of their product; with varying degrees of compliance with the actual meaning of the word: “Oooh! Oooh! IT Continuity. We do that. The administrator can do a backup."

ITIL is technology-agnostic. You can do ITIL with Post-it notes, and the way things are going it won’t be long before 3M are advertising Post-it notes as “ITIL compliant."

The fact is vendors are full of it when it comes to ITIL. It is far too easy to slap the word "ITIL" on an operations tool. This only serves to debase what ITIL means and to confuse the community (I've got more to say about the debasement of terminology at my blog).

You can sympathize with the vendors (as much as one can). They can hardly ignore ITIL, yet OGC and itSMF both let an opportunity slip by when they ignored product compliance. No doubt they had good reasons for standing aloof from the whole sordid business but they have left unregulated an area that cries out for some control.

Today, there is no formal independent certification of ITIL compliance for tools. Pink Elephant provides PinkVerify commercial licensed certification but, in my experience, this is not a good indicator of compliance to some of the criteria that follows.

OGC set up individual professional certification early on, and now finally ISO/IEC has given us organisational certification (the 20000 standard). The product vendors have no choice but to make their own claims, and nowhere to go other than Pink to verify them in the event their claims are in fact correct.

But it seems to me there are some obvious criteria for a reasonable person's definition of “ITIL compliant." So if you adopt ITIL, ask your prospective vendor these questions about their supposedly ITIL-compliant or ITIL-supporting tool (including some PinkVerified ones):

Who says it is compliant or that it supports ITIL? To what maturity and in what capabilities? Just because they think it supports Incident Management at maturity Level 2 is of little relevance if you need a service level management tool to get you to maturity 4.

How many of their product designers are certified ITIL masters? Is the chief product architect? If none, then who are the ITIL masters who consult on design? Ask for a conference call to discuss compliance.

Just because your vendor uses ITIL terminology that does not mean they support ITIL. The ITIL processes are clearly defined in the red and blue books. If it doesn’t work to these processes (and a wide range of the variants that arise at implementation) it doesn’t support ITIL. It is too easy to change the words on a few screens and declare compliance.

Part of the benefit of any standard framework is standard terms, so that new staff, service providers, auditors, trainers and contractors can all quickly understand your organisation and communicate clearly. So it is not OK if an incident is called something other than an incident (especially if an incident is called a problem and a problem is called a fault). Confusion will be endless.
Suddenly every vendor has ITIL. Most IT operational tools claim to “support ITIL” or to be “ITIL compliant." Recently one vendor announced they are seeking “ITIL certification,” no less.

The ones that infuriate me are those that map ITIL keywords to discrete features of their product; with varying degrees of compliance with the actual meaning of the word: “Oooh! Oooh! IT Continuity. We do that. The administrator can do a backup."

ITIL is technology-agnostic. You can do ITIL with Post-it notes, and the way things are going it won’t be long before 3M are advertising Post-it notes as “ITIL compliant."

The fact is vendors are full of it when it comes to ITIL. It is far too easy to slap the word "ITIL" on an operations tool. This only serves to debase what ITIL means and to confuse the community (I've got more to say about the debasement of terminology at my blog).

You can sympathize with the vendors (as much as one can). They can hardly ignore ITIL, yet OGC and itSMF both let an opportunity slip by when they ignored product compliance. No doubt they had good reasons for standing aloof from the whole sordid business but they have left unregulated an area that cries out for some control.

Today, there is no formal independent certification of ITIL compliance for tools. Pink Elephant provides PinkVerify commercial licensed certification but, in my experience, this is not a good indicator of compliance to some of the criteria that follows.

OGC set up individual professional certification early on, and now finally ISO/IEC has given us organisational certification (the 20000 standard). The product vendors have no choice but to make their own claims, and nowhere to go other than Pink to verify them in the event their claims are in fact correct.

But it seems to me there are some obvious criteria for a reasonable person's definition of “ITIL compliant." So if you adopt ITIL, ask your prospective vendor these questions about their supposedly ITIL-compliant or ITIL-supporting tool (including some PinkVerified ones):

Who says it is compliant or that it supports ITIL? To what maturity and in what capabilities? Just because they think it supports Incident Management at maturity Level 2 is of little relevance if you need a service level management tool to get you to maturity 4.

How many of their product designers are certified ITIL masters? Is the chief product architect? If none, then who are the ITIL masters who consult on design? Ask for a conference call to discuss compliance.

Just because your vendor uses ITIL terminology that does not mean they support ITIL. The ITIL processes are clearly defined in the red and blue books. If it doesn’t work to these processes (and a wide range of the variants that arise at implementation) it doesn’t support ITIL. It is too easy to change the words on a few screens and declare compliance.

Part of the benefit of any standard framework is standard terms, so that new staff, service providers, auditors, trainers and contractors can all quickly understand your organisation and communicate clearly. So it is not OK if an incident is called something other than an incident (especially if an incident is called a problem and a problem is called a fault). Confusion will be endless.

Since ITIL is all about quality management, ask your vendor how their tool supports this out-of-the-box (OOTB)? For instance, how does it support determining targets? How does it measure and report improvement over time? Does it explicitly implement a Deming Cycle (Plan, Do, Check, Act) in the tool?

Service Management is nothing without Service Level Management. Regardless of whether it is a tool for Availability, Capacity, Service Desk, Configuration, whatever … ask them how it is SLA-aware and how it contributes to the monitoring and reporting of SLAs.

SLAs are multi-item written contracts. The contract defines who it is with, what period, who are the key people, what the vertical escalation path is. Each item can define support response times, time-to-repair, percentage availability, performance, resource usage, etc.

Setting a threshold time in which an Incident should be picked up or closed or whatever is not an SLA. It is one service level objective that might form part of an SLA if it could be defined on a per-customer basis. Do not allow vendors to redefine the term SLA to suit their own purposes.

SLAs relate to a service. This may seem obvious, but SLAs are not related to an asset or anything else: they define the levels for the service. One individual objective within an SLA might relate to a metric for an individual asset. SLAs don’t.

Does the tool support workflow? (Pretty odd if a process-compliant tool doesn’t). Does it come with the “standard” ITIL workflows (clearly flowcharted in the red book and blue book) pre-defined? How does the documentation explain implementing the tool in support of ITIL process?

Pretty much every one of the larger players provides services to implement their tool in an ITIL environment, but check what comes OOTB and what is in the manuals. If there is hardly a mention of ITIL then you know their service guys have the tough job of putting lipstick on a pig.

Does the tool consolidate information to a service view? Tools that cannot measure and communicate in terms of a service are not ITIL tools (though they can provide a foundation of data for ITIL tools).

For example, a monitoring tool should show current status of a service; a Service Desk should show current status of a service based on incidents, problems and changes; a Service Desk and/or SLA tool should provide historical reporting of consolidated availability information and cumulative statistics by service.

How many of their field implementation staff or partners have certification beyond ITIL Foundation? Foundation training is known in my part of the world as “sheep dipping." It is a basic process that everyone in IT operations should undergo. It provides just enough knowledge to be dangerous (I should know, being a Foundation practitioner himself).

If your organization is of any size or complexity, you probably want more highly trained people, although you should look at the broader skills and experience of the individuals involved. Nevertheless, their overall level of training is a good measure of their genuine commitment to ITIL.

The big vendors generally excel here. The small players often pay lip service. Or worse they have no field support at all beyond one product tech at the local distributor. ITIL is about process not tools: you need process people on the ground to help you implement it.

Specifically for Service Desks

Are Incident and Problem and Change all separate entities? (i.e., An Incident does not morph into a Problem: it spawns a Problem.) The Incident must continue to exist (and be resolved) as a distinct entity from the Problem. Changing the type of a record from Incident to Problem is not ITIL.

Do they provide Incident Matching OOTB? Incident Matching does not mean simple keyword searching—it is a clearly-defined ITIL process. (See the Service Support manual, page 102.)

Do they support Known Error and Workarounds as entities with associated workflow OOTB? Many tools have never heard of these. Some have them as categories of Problem, which is probably okay though strictly they should be another entity spawned from the Problem. Service Desk Level 1 staff need to be able to look for Known Errors and find the Workaround.

Do they assess impact and report it meaningfully? Displaying the CMDB tree in a pretty GUI is not impact assessment.

Finally, ask around. Many ITIL professionals will have additional important criteria from their own experience. If you have one you would like to add to the list, let me know at www.itskeptic.org. I would also love to hear your stories of the responses you got to some of the questions.