ITIL product compliance

[updated: it seems salient to revisit this post. To the vendor who proudly declared on this blog that your product is "ITIL aligned" you might like to measure that "alignment" against this list. ("Aligned" is the new slippery-speak now that "compliant" is on the nose)]

The IT Skeptic’s ITIL Compliance Alignment Criteria

OGC and itSMF let an opportunity slip and let down their constituencies when they ignored the whole area of product compliance [Update: OGC have of course reversed their position on this and decreed a standard for ITIL software compliance]. There are some obvious criteria for a reasonable person's definition of “ITIL compliant”. Here are some searching questions to ask your prospective tools vendor, from the IT Skeptic.

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 that 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. (The IT Skeptic has more to say about the debasement of terminology).

You can sympathise with the vendors (as much as one can sympathise with software vendors… speaking as an ex-vendor myself). They can hardly ignore ITIL, yet OGC and itSMF both let an opportunity slip and let down their constituencies when they ignored the whole area of 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. The IT Skeptic’s experience is that this is not a good indicator of compliance to some of the following criteria [Note that Pink later objected to my associating "compliance" with PinkVerify which I thought was a semantic dance akin to the aligned/compliant nonsense])

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 that their claims are in fact correct.

But it seems to the IT Skeptic that 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):

1. 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.
2. How many of their product designers are certified ITIL Masters/Managers? 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.
3. Use of ITIL terminology. 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.
4. Use of ITIL terminology. Just because it uses ITIL terminology does not mean it supports 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.
5. ITIL is all about Quality Management. How does the tool support 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?
6. 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.
7. 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.
8. 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.
   From the top down: if an incident is raised against a service how to track how long the incident is open as a measure of the outage? How to know when an SLA is in danger of being violated?
   From the bottom up: when a server or network device goes down, how to know what service(s) is impacted? How to roll up / consolidate device outages into a consequent service outage time?
9. 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? (For example does it support diverging workflows for major or minor change? For requests and incidents?) 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.
10. Does the tool consolidate information to a service view? (“service” as defined by ITIL – there’s a grossly-abused term) 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.
11. How many of their field implementation staff or partners have certification beyond ITIL Foundation? Foundation training is known in the IT Skeptic’s 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 (the IT Skeptic should know, being a mere Foundation practitioner himself). If your organisation is of any size or complexity, you probably want more highly trained people, although of course 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.
12. Specifically for Service Desks:
    1. 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.
    2. Do they provide Incident Matching OOTB? Incident Matching does not mean simple keyword searching - it is a clearly defined process [Service Support, p 102].
    3. 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 OK 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.
    4. Do they assess impact and report it meaningfully? Displaying the CMDB tree in a pretty GUI is not impact assessment. If this device is removed will the service still function? How many servers can be removed from the farm without degrading performance past SLA bounds?
    5. Do they provide Forward Schedule of Change OOTB?
    6. How to support a CAB? E.g. what reports when preparing CAB minutes and briefing papers before meeting? How to help them collaborate without having to physically meet, for minor changes that still need a ruling?

What do you think? Do you have any more to add? How does Version 3 change this list (I think not much, but I'm still reading)?