Deconstructing ITSM

19 February 2009

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.

(more…)

Advertisements

15 January 2009

What’s most important in ITSM in 2009?

Filed under: BSM,ITSM — Joe Pearson @ 19:13
Tags: , , , ,

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: (more…)

13 January 2009

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).

(more…)

Blog at WordPress.com.