Start ITIL with Continual Service Improvement

People often ask which part of ITIL companies should implement first. They very often get the (correct) answer that you don’t implement ITIL, you use it to improve your service management. But that’s really just rephrasing the question: which part of ITIL should companies use first to improve their service management?

Terminology and Taxonomies

This is fun: Vinod Agrasala is refining terminology such as Purpose, Goal and objective, Policy, Process & Procedure, Standards & Guidelines, and Assessment, Gap analysis and Audit; and the IT Skeptic is looking at the taxonomy of ITIL V3 Incidents and a list of Request Classes (caution: with all the comments those pages are around 8,000 and 3,000 words).

Vinod:

I am in a focused drive of differentiating between confused terms

The Skeptic:

I think ITIL V3 muddies the definition of Incident, and of Incident Management.

People – Process – Technology – The eternal triangle

The eternal triangle of “People, Process and Technology” is tired and overworked, especially in marketing literature. In itself, these facts don’t make it wrong. But is it good enough?

It’s usually invoked to back a claim that there’s more to consider than just [whatever it is that is already being considered - often a technical product]. And this is nearly always a good thing. Obviously each of the three words embraces a number of related concepts – for example, a consideration of people requirements should bring in questions of skills and motivation as well as sheer numbers of people. But can the triumvirate of People, Process and Technology claim to be everything there is to consider?

.

Information

One thing I think is missing is the dimension of information or data. (Information and data are not the same thing, but we can understand them living on the same dimension, along with knowledge and wisdom. As does content, the term favoured in web-enabled business-to-consumer areas.)

Some people seem to regard information as a detail of technology, but I believe this view leads to incomplete solutions – in other words, information is very definitely something more to consider.

10 Reasons Why Strategic IT Management Initiatives Fail

Dennis Drogseth has published an article 10 Reasons Why Strategic IT Management Initiatives Fail on CIO Update.

Now, I agree with every one of his ten reasons, but I immediately thought of some different angles on the approaches he recommends …

ITSM discussion boards

What discussion boards on IT Service Management do you find useful?

• I have not been active very much on LinkedIn until recently, so I can’t judge the discussion groups there. But there are a great many ITSM or ITIL groups, some with willing experts. Some, admittedly, are dominated by job ads or requests. I’ve yet to find one that shows a good level of activity and content, but the groups are evolving.My impression of the software capability is not good though: yes, it lists recent discussions, but it doesn’t provide a way to jump to the most recent post in a discussion; it doesn’t flag which discussions you’ve participated in, and doesn’t provide any way to subscribe to a discussion or flag it as interesting – all of which are standard features of discussion board software like phpBB, vBulletin (which is not free), or SMF.
• I like the ITIL Community forum: it has plenty of willing experts, and the software base is OK. It suffers from a large number of beginner’s ITIL exam-related questions (which are in scope; there’s a big need) and very basic questions from people who show no signs of having done any research and don’t give details of what they really need. I don’t think that’s a bad reflection on the board, just a bad reflection on humanity. (Look at Java and other programming boards for exactly the same problem.) Note – when I say “willing experts” I don’t mean people willing to answer basic questions. In fact, the ITIL Community has “grumpy experts” and when I grow up I’d like to be one.I do take issue with some of the ITIL Community’s admin policies, e.g. requiring you to post a verification code with every new thread or reply you preview or submit, and disallowing any links posted in messages (see this post, for example). Even for long-term registered users. There are better ways of dealing with off-topic and commercial spam than treating everyone as a bot.There are some excellent discussions and insights, and that’s ultimately what matters most.

Agile Service Management

I’ve been thinking…

1. I am not a professional software developer or data architect, but I’m very interested in these disciplines through ITSM contact with practitioners and teams. (I often feel there’s a great loss of value in the lack of mutual familiarity between service management and development/data communities.) One of the approaches I have been particularly interested over the past year or so is Agile Software Development, the Agile philosophy – see the Agile Manifesto, and some of the key practices associated with Agile development like test-driven development, refactoring and design patterns.
2. I observe that many ITSM projects (”implementations” or improvements) suffer from issues with long timescales, inability to cope with changing requirements, lack of user acceptance, and so on. Not all, but those that do suffer tend to be blind to the causes and show resigned acceptance to such issues – or even to be blind to these issues.

Those issues, and others I haven’t listed, are very like the kind of things the authors of the Agile Manifesto were experiencing. Agile development is very successful in certain environments (though not all – and more traditional “big requirements up front”, “big design up front” methods have strong defenders). Could Agile principles be applied usefully to IT Service Management problems?

No one needs a CMDB

… Did I just write that? But it’s true. No one needs a CMDB for itself, or a CMS, or an SKMS. Even an outsourced service provider whose client has written “must have a CMDB” into the contract doesn’t need the CMDB itself. Anything will do as a CMDB, to avoid contractual penalties. The client has no external standard to hold the provider to. So they write, or should write, more specific terms to give the desired control. And so should organisations trying to improve configuration management for business value rather than compliance.

What good, specific objectives or contract terms are there for a CMDB, or more accurately a configuration management improvement project?

Here’s one.

What’s most important in ITSM in 2009?

When it comes down to it, the same things as ever as important, with even more of a focus on cutting cost and reducing risk. In South Africa we’re lucky that the sub-prime mortgage mistakes were not made by our banks, and the credit crunch has not so far affected consumers and businesses directly. But global companies are facing hard times, global markets are affecting local suppliers – especially suppliers to the car industry, and global aversion to risk affects – rightly or wrongly – “developing” markets.

Here are some things I suggest will be the greatest focus for companies in 2009:

The Three Little Pigs of ITSM Improvement – A Parable

(There are good ways to improve ITSM, and other ways…)

-

In the land of ITSM Continual Improvement, near the city of Process Development, there once lived three little pigs. Now the three little pigs weren’t as happy as the proverbial pigs in strategic, holistic information technology. They were continually being attacked by the wolves. They’d trying calling the wolves “customers”, and it didn’t help. So they got together and agreed that they needed to build stronger, best practice, houses made of brick. But they couldn’t agree on how they should do this.

Gather requirements and sell achievement? Sell requirements and gather satisfaction!

(Yes, I struggled to come up with a snappy title for this post that wouldn’t sound like marketing speak.)

In October, Paul Glen (re-)published an article at TechRepublic: Project managers: Stop “gathering” IT requirements and Hank Marquis published an article on CIO Update: Why IT Service Level Management Fails (And How to Fix It).

• In summary, Paul says that, while a failure to agree requirements is the root of many IT project failures, “gathering” requirements is the wrong attitude. As I’ve also found, customers tend not to be very good at articulating their requirements at the outset of a project (not nearly as good as they are at saying “No, that’s not what I wanted” at the end). Secondly, passively receiving requirements puts IT projects squarely within IT’s responsibility. It’s much better to negotiate or even sell requirements – to my mind, this is actually what customers mean when they complain “I thought it was IT’s job to define requirements”.
• In similarly brutal summary, for which I apologise, Hank says that service level reporting based on well-defined and controlled metrics – like percentage availability and mean time to repair – fail to address what customers want. He advocates dropping all the tightly-controlled (whether actually or theoretically) metrics and focusing on customer satisfaction. He reports on the SERVQUAL method for reporting quality in service industries in general. I haven’t looked into SERVQUAL enough to say whether it specifically is valuable, but I strongly agree with his principle that “quality is what customers tell you it is”.

It struck me that these two recommendations go together. Establishing, defending or analysing requirements (call this stage what you will) happens at the beginning of a service’s lifecycle, and service reporting happens at what we like to think of as the end (apart from service retirement or decommissioning).