The IT Skeptic - Comments for "Visions of the Future of ITIL: First Vision"

I know

aroos — Wed, 11 Feb 2009 07:55:36 +0000

I know but it does not make the definition any better.

Not likely

Visitor — Wed, 11 Feb 2009 03:52:56 +0000

The lead author of Service Operations (where IM is defined) was David Wheeldon. The same Dave who helped author V2 and V1.

I doubt he "did not know or understand" the V2 material.

What hurts

JamesFinister — Tue, 10 Feb 2009 20:37:09 +0000

Yes things break in IT, and users get annoyed at the time, but generally understand that is the way of the world, after all their home computers go wrong and "I'll fix it in five minutes dear" becomes "Are you ever coming to bed?"

What users and customers alike just can't stand is when a commodity task, such as adding a new user, takes weeks instead of less than a working day. Or when they make a complaint but nobody seems to realise it is a complaint

Real incident

aroos — Tue, 10 Feb 2009 11:08:25 +0000

Guys
Please remember the basic nature of incident. IT Service is faulty and things do not work. (Read Skep's complaints of Vista for example.) According to my experience over 80% of incidents (or service requests) never come to Service Desk, users/customers try to fix them alone. Fighting with IT-solutions eat far too much time from business. In many cases the root cause is that people do not know how to use the system but neither does Service Desk.

Looking this from Customer Service point of view, lousy service quality is the key issue. There should not be so many incidents or service request. This is still the the heart of the matter, ITSM is or should be about improving IT service to acceptable level.

The main fault in V3 is the redefining and misunderstandfing of the concept of incident. It looks like the author did not know or understand what the V2 definition of incident is and wrote down some loose text. To me, this gives V3 the credibilty of subprime loans.

Here is the definition for those who have not bothered to read the book:

In ITIL terminology, an ‘incident’ is defined as:
An unplanned interruption to an IT service or
reduction in the quality of an IT service. Failure of a
configuration item that has not yet impacted service
is also an incident, for example failure of one disk
from a mirror set.
Incident Management is the process for dealing with
all incidents; this can include failures, questions or
queries reported by the users (usually via a telephone
call to the Service Desk), by technical staff, or
automatically detected and reported by event
monitoring tools.

If it looks like bullshit, smells like bullshit; don't taste it.

Aale Roos

types of request

skeptic — Tue, 10 Feb 2009 10:27:00 +0000

Jan, congratulations on winning the Candle in 2008 [do readers know where the candle comes from?

My copy of The Demon-Haunted World: Science as a Candle in the Dark has a nice big candle on the front cover. One of the greatest works of enlightened skeptical thought ever. Far from a perfect book but a must read.]

As for types of request, here's my 2¢:

Real ITSM considers all requests from users to be a Request . After sufficient information is obtained, Real Requests can be classified as :
• Incident: An Incident is defined by Real ITSM as an unplanned interruption to the normal operation of IT or a reduction in the quality of the perception of IT.
A Major Incident is one with a significant risk of the Board of Directors (or Minister/Secretary) hearing about it, or of it getting into the newspapers. See Damage Management, page 82.
• Request For Change: Some organisations allow users to open RFCs directly, others have some form of gating process such as Requests. Real ITSM requires gating via a Request, as one more step in delaying change.
• Proposals: The Service Desk can be a front-end to the demand component of project portfolio management. Think of it as a request for project. These should be declined or ignored for as long as user patience lasts: see Demand Management, page 80.
• Provisioning: User requires access to a service or part of a service, e.g. security permission, menu option, digital certificate, client install, desktop device, phone, etc. These are also best ignored (see Access, page 69).
• Advice: How do I …? Should I …? Which is the best way to …? This category needs to be closely linked to the Known Idiot database, see page 79. And ignored.
• Booking: Scheduled attendance at training, seminar, meeting, reservation of a resource, annual leave. Also best ignored, especially if users have an alternate path for doing this themselves.
• Ordering: Books, desks, catering, stationery, travel... See Booking, above.
• Work Request: Run a report. Move a PC. Install a projector. Paint the kitchen. These make good busywork that draws resources away from projects that are moving too quickly.
• Help: Correcting data arising from user error, restoring a deleted file, sending a document, untangling a mess. Likewise good busywork.
• Feedback: praise, suggestion, idea. Praise should be immediately forwarded to management, while other feedback is best omitted from reporting in the interests of brevity.
• Complaint: complaints are a form of feedback but they are best dealt with separately, so that they can be ignored in a more focused manner and so they can be reported separately (or not at all).

from Introduction to Real ITSM

A more serious version of the list was originally published by me in the article The Evolution of the ITIL Request on ITSMWatch, where I said:

ITIL v4 will, most likely, I predict, finally recognise that the Service Desk deals with generic Requests/Tickets/Issues/Incoming. These Requests have multiple categories. Each category has its own variant of a more general process that applies to all of them, in much the same way as there are several categories of Change which all undergo variants of the general Change process.

as always - definition rules

jvbon — Tue, 10 Feb 2009 00:56:18 +0000

Ian,
many discussions between 'deeply involved' pactitioners come down to matters of definition. Especially when you start from very different perspectives.
The examples brought forward by Charly Betz, starting from a data management perspective, illustrate my point. There obviously are differences in perspective from where the Dutch start, compared to where USMBOK is coming from. But in the end, if we compare defnition sets, we should easily be able to find each other (I'm still working on the ultimate IT Management Compendium!!).
I'm looking forward to having you again as a guest speaker at this year's national Dutch Spring Conference (if we can solve the last details), since that offers us the opportunity to exchange those perspectives - and that's where we can learn most from eachother. Maybe you can throw in a special Master Class for the people in Europe who are really interested in refreshing their perspectives?
And if we can again have Brian Johnson and Paul Wilkinson there (as I expect), we may have another go at the biggest prize of all in the IT Skeptic Awards: The Grand Sagan Candle for IT Skepticism!

Its a service request

ianclayton — Mon, 09 Feb 2009 23:08:20 +0000

Jan - feel free - in my world they are all requests for service separated only by types. In fact there are at least 8 types of service requests that include complaint (as per ISO 9000 lingo). The percentages you mention are very different when service requests are actually recorded! Often they are not thus skewing the percentage towards break-fix.

Glad to hear there is a companion book tabled. As for your rhetorical question about what IT might be doing - don't forget that a service request is the container for ALL input to the service organization, including thr four types of maintenance/change - well at least thats how I describe it in the USMBOK and the new service request management 102 best practice guide...

Why have multiple inputs - after all - its a goal of 'process management/improvement' to standardize all inputs to eliminate variation...

service request - or support request

jvbon — Mon, 09 Feb 2009 22:48:46 +0000

Ian - I'd prefer calling the incident a 'support request' instead of a service request. In an incident the customer simply complains about the fact that they didn't get what was agreed in the SLA (or expected).
In a 'service request', the customer would address an element of the service, which - as you know - is composed of many smaller items in a list, often known as "The Service Catalog".
From what I've learned from practical estimates, incidents can cover 40-70% of calls, where service requests cover 20-30% and change requests cover the rest. This btw is quite depending upon the maturity of the service organization.

The 'service request companion guide' is on the list of books we're developing as the enhancement of guidance provided in the itil v3 books. It will be covered in the Operations Management book. Which btw will finally cover that enormous white spot that itil left open for 20 years...
If all goes well in the IT service organization..., if no changes are requested by customers or kicked off by changing conditions or internal improvement initiatives.., then WHAT are the people in the organization doing all day? Playing cards? I'd say not: they're at least delivering the service by planning, scheduling and performing a lot of regular tasks, and monitoring the systems to see whether everything runs as expected. That very basic responsibility has only been slightly touched upon in the itil books. The only process book that was written on this, afaik, was the Operations Management Pocket Guide, written in 2001 as a companion guide to itl v2.

Ignore incidents (for now) service requests are the key

ianclayton — Mon, 09 Feb 2009 22:10:20 +0000

Jan

Good prompt - the humble service request is the key to service management success. Its the '311', '411', and '511' call combined, whilst incident remains the '911', or '999' as I knew it back in my days in Blighty! Anyway, to me an incident is a type of service request. The business, especially the service industry, has approached it this way from the get go. Its easier to record and report as its all in one record and sliced by classification. The type of request helps set its path through the service organization...

If that were not enough, conservative estimates suggest service requests represent 60-80% of the operational workload and costs. There are major benefits to be gained out of finding and refining a few humble service requests - just as the business has been doing for years. As for ITIL.... I am looking forward to the companion guide that expands on the 1.5 pages on 'request fulfillment'.

And... you can't build a service catalog with any confidence of it being actionable without first pinning down the service requests....

Sometimes good practice has the speed of a turtle

jvbon — Mon, 09 Feb 2009 21:52:32 +0000

The separation of the incident, event and service request processes is still perceived as 'revolutionary', while some companies did that back in 1992 in their very first 'ITIL project'....
ITIL is a hype. At the same time ITIL is one the most misunderstood frameworks of all times. And that misunderstanding (or the ignorance of so-called ITIL consultants with a Foundation certificate) costs us billions every year.

Where some have done this from day one in the early nineties of the last century, others seem to see the light much later. The separation of incident, event and service request was recently advocated as 'a great thing' of itil v3.

As probably only very few know, the whisper is that the joint treatment of incidents and service requests (first page of the Incident Mgt chapter) in itil V2 was not the result of deep discussions in a team of spiritually enlightened experts - but merely the result of an influential tool provider who couldn't separate incidents from service requests in his tool. Anyone with a decent mind hasn't made a fuzz about that and of course applied this differently in their own practice. Only the dogmatic believers, who didn't "adapt & adopt", practiced this as it was preached in the holy books. Bu according to some, this now is 'a great move by the authors of v3' (http://www.itsmwatch.com/itil/article.php/11700_3801266_1).
Sometimes good practice has the speed of a turtle.

From the inside 8-)

Bart — Tue, 26 Feb 2008 15:32:48 +0000

I agree with most viewpoints here - I have been chairing/Cosharing itSMF in Belgium for the last 7 years, and we try to incorporate as many methods of Service Management as possible - but cannot leave out ITIL as well. During the past 7 years, we faced many challenges to bring ITSM to the Belgian world. Since ITIL v3, it is a bit easier, for there is a lot of confusion around and people are looking also to the itSMF chapters for assistance to bring order in the chaos.

But the remark that users or practitioners should protect themselves?

Maybe I miss something, but I fear user's opinions are scarce(and I mean no disrespect for there are many good and experienced folks out there). I once offered to speak on a conference (leave out the country) only to shout at the people to see 'What the h*ll do you THINK'. Because you hear viewpoints from all the big vendor names. When you speak to customers and potential customers to find out their needs, they only reflect what their big vendor is whispering into their ears. I do not find too many people who have an IT Management (or ITSM) opinion of their own - in line with their specific business goals. Needless to say I was not invited to do a presentation.

itSMF BE is not about ITIL, but about (IT Service) Management, offering a platform for all members to learn, discuss and find out whether somebody has an answer to their question(s). The international politics of the itSMF pass by from time to time, but unless they get their things sorted out, many a chapter will only do one thing => let it pass by and see what happens and continue to do the best for their members. We tried to 'change' international rules once, and even twice - but the result is always the same - the same people continue to rule the waves. It is the same old story over and over again = only now, there is a real commercial taste added to it.

People need guidance in any form (see the success of the WIKIpedia), and in the land of the blind, one-eye rules, not?

Bart

US centric

JamesFinister — Mon, 05 Nov 2007 20:44:05 +0000

Of course we have to be careful when discussing legislation of taking an international view. In the UK we can't protect a business process as I believe is possible in the USA. Personally I've never understood how people can protect Pantone colours as part of their corporate identity when I always presumed Pantone would own the rights to all of them.

As for the IoSM... being UK centric, can anyone remind me what a UK organisation has to do to become chartered? I'm sure that would make a big difference to UK take up, but IoSM without that magic word in it does sound a bit empty as a concept.

Marijuana Juice.. marketing 101 and regulatory compliance

ianclayton — Mon, 05 Nov 2007 17:07:12 +0000

Anyway, I don't see the relevance to what was being discussed? The name IoSM is too close and in the same industry area as to be confusing to existing and potential customers - one of the key criteria for proving infringement. I suggest they but a copy of "Trademarks for Dummies" and check it out...

But since the comment is there lets have some fun around this unfunny topic.

Trade descriptions kicks in on eyecatcher byline or advertising claims (marketing) - if they had said - "Its the coke it contains that makes the difference", and it did not contain 'C' - false claim. However, some regulations trump others - the law against putting illegal substances in goods would trump trade descriptions. Also, there are stipulations on the number of years of unfettered use passing and the plain common sense that folks know it doesn't contain 'C'.

Its a plain fact you can advertise a product such as 'marijuana juice' and get away with it if you include a discliamer (does not actually contain marijuana). I think someone did that here in the US in 2007!

Trade descriptions act

Peter Brooks — Sun, 04 Nov 2007 07:32:14 +0000

Coca Cola and Cola Coca
-------
I've wondered how they have managed, with a name like that, to avoid prosecution under the trades description act after they took the cocaine out...

Just to note the Trademark Infringement

ianclayton — Sat, 03 Nov 2007 17:51:01 +0000

Skep

I know I've mentioned this before - but it has to be done wherever their is an expsoure....

The IoSM is a stated trademark infringment of my company's registered trademark - IT Service Management institute. This is why they have created another named organization (Institute of certified Service Managers), which flies just as close to the trademark wind of another previously trademarked term 'Certified Service Management Professional', and probably accounts in part for their slow rollout here.

The other simple reason is that folks would prefer, or actually believe, the itSMF should or is already doing this. The third and most compelling reason is that folks here don't take kindly to the 'totem pole' style of ranking how professional you are. We tend to rely upon track record, references, and results achieved FROM CUSTOMERS!

As is plain to most folks the 'Institute of IT Service Management (IoSM)' is a bit close to the 'IT Service Management institute (ITSMI)'!!! Rather like Coca Cola and Cola Coca, or Windows and Lindows.

Our position is clear, was communicated to itSMF USA in 2004 and resulted in a Board mandate to all members NOT to use or promote the IoSM term (!). As for the itSMF UK they can do what they wish in the UK. If they, or anyone else come to that, earnestly markets and promotes the IoSM under that name in the US - they will be subject to action. The itSMF UK has received suitable notice way back in 2002 when it was first floated, in 2003 when it was launched, and again this year to ensure its removal from the ITIL V3 Glossary.

If anyone wishes to learn more about this unfortunate and frankly infantile strategy of the itSMF UK then please feel free to contact me directly - ian@itsmi.com

If it's ISO, you are talking IEEE

Charles T. Betz — Wed, 08 Aug 2007 02:34:30 +0000

If it's true ISO 200000 unification you want, it seems the IEEE would likely wind up involved at some point. I'm surprised that they haven't taken more of an interest in ITIL to date. This might be re-examined given Carnegie Mellon's activities in the field of service management. If service management education becomes more of a university concern (as referenced elsewhere on this blog), there is little doubt in my mind that IEEE and ACM will start looking very seriously at the whole matter.

See here for pointers to the IEEE and ACM subsections which might be the locii of ITSM interest.

These people know how to run a professional organization. But are they the best home for ITSM? Heavy, heavy academic bias - but perhaps that's what's needed. You'd certainly have hundreds of grad students all over the Skeptic's challenge.

A simple Google turned up this IEEE-published assessment of ITIL. Not sure I want to pay $35 for 6 pages. (And you thought ITIL was expensive!).

Charles T. Betz
http://www.erp4it.com

The fate of grassroots organizations

Charles T. Betz — Wed, 08 Aug 2007 00:47:42 +0000

Volunteer organizations are indeed hard to sustain. The same could be said of others I have mentioned elsewhere on this blog. In fact, there are many who would consider an operational core of 75 truly engaged people a dream come true.

Charles T. Betz
http://www.erp4it.com

Well said...

Visitor — Tue, 07 Aug 2007 16:19:29 +0000

The itSMF USA is riddled with problems that they can’t seem to solve. Before you join or renew your membership, you should ask yourself what value do you really get for that payment. For an industry organization that touts strategy as one of its core values, the board has most certainly confused agenda for strategy.

Another sad realization, the crucial election debacle. To paraphrase the president, the bogus votes didn’t affect the outcome, so, no harm no foul. Excuse me, does anyone see a problem here? When the next great problem surfaces, will this be the strategy the board employees?

Will the last member leaving turn of the itSMF USA lights

ianclayton — Tue, 07 Aug 2007 08:57:00 +0000

Well said once again Skep. It seems to continue to go unnoticed that many of the 35+ Local Interest Groups (LIGs) operating here in the US rely totally upon the sheer generosity of grass roots members. Many of the (practitioner) Presidents have gone unchanged since forming their LIG, and work tirelessly to build agendas, manage local lists of contacts, and email locals to encourage them to turn up and share their experiences.

The whole organization is likely dependent upon less than 75 key members. They see no respite, no replacement waiting in the wings to take over the baton, just more of the same - mandates from the national Board for more effort and a greater bias towards an increasingly commercial and vendor centric product - ITIL.

The rest of my comments on this unnerving situation can be found on my own here (http://itsmi.wordpress.com/2007/08/07/will-the-last-itsmf-usa-member-lea...)

How do I put in a URL Skep?

It beggars belief that some

Visitor — Tue, 07 Aug 2007 08:20:07 +0000

It beggars belief that some folks still can't see through the emperor's clothes.

itSMF represents its cozy inner circle. It demands money right left and center. It acts as a capitalist money making entity. It does NOT represent its members: as stated all over this blog, it doesn't even state it does in its own articles.

The sooner users see this, walk away from it, and create a proper 'user group' the better off we will all be.

The good news is that many users have already walked.