The IT Skeptic - Comments for "Create a variance register for ITIL and other frameworks"

whatever has come up

skeptic — Fri, 27 Nov 2009 19:45:59 +0000

Ideally: yes. But I'm a pragmatic critter. I tend to come up with a starting list as I consult.
"I advise you do X"
"We want to do it Y because Z"
"OK I'll put that in the register"

Then other entries will emerge during maturity assessments, audits etc It is an evolving document and doesn't aspire to be comprehensive - it just lists whatever has come up so far and (hopefully) been thought about

The Nature of Best Practice...

kengon — Fri, 27 Nov 2009 15:44:30 +0000

Skep,

Sorry it's been soooo long since my last post... things have been "interesting" for me as of late.

I have no issue with any of the dictionary/lexicon talk. I think it's a smart move to have a generally recognized list of terms and then specialize as you need to. This is a recommendation that I will always make, regardless of how large/small the client is or the initiative that I am working with them on.

The thing that no one has mentioned yet is your opener and that is the relationship to general/good/best/commonly accepted practices. You wrote:

register of variances from best/generally-accepted/good practice frameworks such as ITIL

While you've certainly identified and discussed one of them (the dictionary), your statement implies broad applicability across frameworks and I think that you are right.

The problems that it presupposes are:

Would a mere mortal be able to identify a general/good/best/commonly accepted practice if it came and kicked them in the teeth?. Not sure that this is the case today in defining it's characteristics (generally speaking, not to get on my soapbox about preferences for frameworks)
Are products (such as ITIL) constructed well enough to make it easy to determine what/where those practices are?

These are not insignificant challenges to the "best practice" view of things. Without these things, you still deal with the variation that comes from each person having their own interpretation of the published guidance. With that said, additional questions come to mind:

If you don't have a good way of describing such practices, how do you determine a variance? How would you note same in the register?
What resources do you have to identify such practices?
Wouldn't this require some sort of "practice catalog" that is the essential reference (to compare and contrast)?

It seems to me that we certainly are "living in interesting times"...

kengon

variations

skeptic — Fri, 27 Nov 2009 08:19:31 +0000

I'm not just refering to variations in terms but also variations in process, such as the "we don't have a CAB, we do it this way" example I used, and variations in role e.g. "there is no one incident manager, it is split over these two roles" - anything that might cause confusion or misunderstanding or false expectations.

Gloassry for every assignment

DavidM — Fri, 27 Nov 2009 05:20:09 +0000

Rob,

One of the 1st things we do with any new contract is to establish a glossary. Before ITIL V3 it was just organization based (V2 wasn't comprehensive or consistent enough). Since V3 it's 3-column, term, internal use, ITIL reference.

I don't know how else to approach the issues we face.

What's also interesting is that very often seeing the glossary for the 1st time produces an "Ah ha" moment in the organization. :-))

In other words... yep, you're right. So what else is new... and we're back to business as usual (at least for us :-)).

David

The backstory on one pocket guide solution

ianclayton — Thu, 26 Nov 2009 19:48:11 +0000

Here I am sitting on a Delta flight at 25,000ft on free wifi thanks to eBay - amazing technology we live with... anyway, the back story on that pocket guide story was a bit shocking, a shockingly simple answer to a familiar issue. I can't disclose who or where as they are still friends but - there was a merger afoot and an audit scheduled by the other organization, which claimed to be 'ITIL compliant'. Now this was a few years back so we are talking ITIL V2. The other organization had hundreds of IT folks trained by a well known US company to the Foundation level. Hundreds.

The organization I was working with had two Service Managers, trained by me. They had no available training budget due to the merger, so we had to think quick as everyone knew the 'audit' could lead to redundancies if failings were found. Their practices were fine, in fact their support system was sophisticated way beyond ITIL concepts (those who have heard the smilies profiling story in my classes will recall bits of this story), and in-house developed. A major analyst firm had recently awarded their support organization a top trophy. Yet, the audit could reveal non-compliancy... with ITIL, or at least ITIL as it was interpreted and 'implemented' by the other organization.

So, I decided to pay my friends a visit as they were in sunnier climes, and interview staff, department by department, to better understand the language used on a day to day basis. I looked at management reports as well as those that were sent to customer communities. The cost to recast the language and retrain not just the IT staff but many customers in 'incident', 'CMDB', and so on, was enormous given the standard strategies suggested by brand name vendors.

The conclusion - the pocket guide. We extended it as I said to describe service management as it was in place at the organization, and it matured quickly into a very handy 120 page piece of internal marketing collateral. It was ready just in time for the 'auditors' visit. Guess who got the first copy. Suitably impressed, the chap toured the organization with the pocket guide in hand, using it as a trusty universal translator for the local terms.

Its amazing how quickly ITIL was accepted by the organization using the pocket guide - not as a 'solution' but as a useful contribution... it also allowed them to paint their own identity onto the initiative.... which removed much of the fear change often creates. It also helped expose huge failings and gaps in the ITIL terms used by the other organization. Remember, 'adopt and adapt' as itSMF UK used to say...

It is required

Mark O'Loughlin — Wed, 25 Nov 2009 22:12:49 +0000

Hi Rob,

I use a similar approach and find that it is especially needed for organisations looking to achieve ISO certifications. Many organisations tools and language do not always follow ITIL terms. Ian, I have also used the approach of creating a pocket guide which has been used successfully. I LEAN towards finding the right balance.

Common sense translation pocket book

pjotrg — Wed, 25 Nov 2009 21:32:05 +0000

"we discussed this at the bar in Holland a few years ago" Well........... no doubt in presence of some hotshots form the Dutch ITIL maffia ;-)

What Ian says further on is about as shocking as it is true: "they just needed a copy of the pocket guide" (however this might get my job worthless and obsolete), because..... ITIL is nothing but common sence....If we have a book that tells us how to call "things" (from our common sense) in a standard language every body all of the sudden knows ITIL. Pretty frightning though............

thanks Ian

skeptic — Wed, 25 Nov 2009 19:57:40 +0000

Ah is that where I got it from? thanks Ian!

Universal Translator for Key Terms

ianclayton — Wed, 25 Nov 2009 19:23:00 +0000

Rob - you missed it - well it was not actually written on a blog.... we discussed this at the bar in Holland a few years ago...

This is exactly what I do onsite ... scrub, sort and straighten (Lean :-)) common terms. In fact on one project tens of thousands of dollars was 'saved' or deferred by creating a specially branded pocket guide that matched locally used terms to ITIL and other equivalents.

Its a standard and I believe best practice to get the language and verbiage working first and to help overcome the toxic shock of ITIL to some. When the client was 'audited' for ITIL "compatibility", they were able to explain that 'ticket' meant 'incident' and so on.... and passed. It meant as many as 5,000 staff did not need to attend basic Foundation training to learn a new language.... they just needed a copy of the pocket guide... which included a bit more than just terms of course.

This idea also addresses a major issue introduced by ITIL - the inconsistencies between the glossaries in each book, the use of the term within the book itself, and the separate Glossary pocket guide.

Its easier to grease the skids of change when the various stakeholders can recognize a piece of themselves in the oncoming train..... Thanks for reminding us all of a simple but key first step.

Lost in Translation

Jour — Wed, 25 Nov 2009 16:09:22 +0000

Such list is essential. And even more important when English is not a business language for the organisation. Localized ITIL vocabulary reflects preferences of the most active ITSMF-[local] members which doesn't mean 'majority of the community'. And therefore creates more ambiguity.
So non-English version could look like this:
[ITIL] - [translation] - [how we call it] - [what ITIL call this way].
For example,
Incident - Инцидент - Проблема - Problem
Problem - Проблема - Бага - ITIL doesn't use that term.
Service Owner - Владелец услуги - менеджер сервиса - Service Manager.

Babilonian structure of the Glossary added to wild-grown terminology of the particular organisation provide a sound basis for total misunderstanding.