Setting the target goal for service management initiatives

When we want to know how to, say, measure a service desk, we can find quite exact guidance everywhere. But it seems to me the depth and specificity (specifity? specificness?) and usefulness of advice is inversely proportional to the importance of the question. Consider the most important question we need answered in a service management initiative.

The standard consulting model, used in ITIL, is to determine the current "as-is" state through assessment, then decide the "to-be" state, and then work on the gap. ITIL V3 still fails to provide an assessment model, though COBIT does. So too do many consulting firms.

So we can find the as-is readily enough. But what about the other half? How do we pick the target "to-be" state? Very often the as-is and to-be are defined as some composite CMM maturity level from 1 to 5 (actually 0 to 5 - I've met zeroes: companies with one or more processes at a zero maturity level, no detectable trace). A consultant will give you the as-is to two decimal places, but how do we determine the to-be?

Seems to me the standard model is to extract a number from a suitable orifice. If you're a basket case you'll go for 2. If you are mainstream you'll shoot for 3. if you want to swagger you'll aim for 4. And if you want to use the result in marketing your company's services you'll find a consulting firm that will certify you as 5.

This is not exactly scientific or rigorous, and there is no process other than a brief gaze at the navel.

And yet is there a more important decision to be taken than the target maturity goal? The only one more important that I can think of is whether to even undertake the initiative or not. Why do we have whole books of guidance from multiple BOKs on lesser issues but when it comes to setting the broad scope, the ambition - and of course the cost - of the initiative, we allow someone to pick a number (or a number per process for the sophisticated ones)? On what basis? With what advice and guidance? Reached through what reasoning and methodology? None. Not in ITIL V3. Not in COBIT.

Comments

KPIs

Interesting line of thought. It seems to me that process is an enabler to reach goals, not a goal in itself.

The most common business way to set goals is to define Key Performance Indicators (KPIs). The target of implementing your service management initiative is to reach your goals as set out in your KPIs. So implement the process (ITIL or any other framework) and measure against your goals -- customer satisfaction, efficiency, etc.

The problem with methodologies like CMM is that it measures the process but not the outcome of the process. You could have a great repeatable defined process (CMM 3) but customers still may think you stink.

best regards,

Erik Hoffmann
http://www.kpilibrary.com
http://www.mirror42.com

Compliant PRMs and PAMs might help?

I'm still mired in 15504....seems to me if ITIL, CobiT, et al had 15504 compliant PRMs and PAMs we'd go a long way towards addressing at least some of these issues. We may only get ISO 20K, but wouldn't it be nice to have other frameworks too? That way we'd all at least know that my 'Level 2' is the same as your 'Level 2', wouldn't we? In fact, if these Levels can be 'spun', how do you set targets?

I like van Loon's book on some of this:

["There are two reasons to consider definition of Taget Capability Profiles:

First, organizations may wish to define or use a target capability profile that minimizes process risk to successful implementation of a specified requirement.

Secondly, a customer organization may wish to set a target capability profile for supplier selection.....

in both business cases, the focus is upon actively using process capability as a way to reduce risk."]

The ITIL guidance (V4?) and I think CobiT/ValIT might help to point clients in the right direction, but without some agreed standard for determining process capability and a repeatable way of performing assessment, we may still miss the mark.

Is it possible that one framework (ITIL) may put some process attributes at a 'Level 2' while another (CobiT) put them at a 'Level 1.5' ? I don't know. Even in the absence of a standard, using a standard approach like 15504 across all these frameworks might help "harmonize" them in a way that is more meaningful (and more easily and quickly applied) to customers.

Does this make sense? Or am I just ready for the weekend.....

John M. Worthington
MyServiceMonitor, LLC

Future State...

The standard consulting model, used in ITIL, is to determine the current "as-is" state through assessment, then decide the "to-be" state, and then work on the gap

You're right, that is pretty standard consulting... no ITIL magic or special sauce here.

There are deliberate means by which consultants can assist clients in coming to a decision about what future state is right for them. What does the customer need to be able to do/provide that the future state would enable? And, no, it doesn't revolve around buying software (huge red red flag, if that's the answer!)

How do we pick the target "to-be" state? Very often the as-is and to-be are defined as some composite CMM maturity level from 1 to 5

I think this is where most organizations go wrong.

  • Why do you want to be a level x?
  • How does this match up with where you are now?
  • What value does the customer we serve get out of our getting there?
  • How much would that cost?
  • Is it worth it?
  • Against what background are you going to make the assessment?
  • How does this apply to us
    • As a whole organization? (how we deal with IT generally)
    • At a consumer/customer level?
    • As a service provider?
    • On our ability to provide a specific service?

There are many other questions related to this that warrant attention before ever thinking about maturity level. I think conversations about maturity level just distracts from what the focus should be.

Seesm to me the standard model is to extract a number from a suitable orifice. If you're a basket case you'll go for 2. If you are am,instream you'll shoot for 3. if you want to swagger you'll aim for 4. And if you want to use the result in marketing your company's ervices you'll find an consulting firm that will certify you as 5.

If you can't answer the value related questions above, why should I care what the number is?

And yet is there a more important decision to be taken than the target maturity goal? The only one more important that I can think of is whether to even undertake the initiative or not.

I think if we (as an industry) adequately addressed the questions that can keep us on track, we'll be able to answer this one.

kengon

Outcomes

I'm sure this has been said before, but for me, event though I use maturity models, the actual change in state is about outcomes. If a new user request is currently taking twenty days to process, and fifteen percent of them need re work than your choice of to be state is how many days it should take and what rework rate you will accept. Maturity models provide guidance on whether that performance can be sustained in the long term, but they are just a tool.

a best practice approach to making that determination

Ken, your comments are precisely the kind of guidance I'd like to see systematically structured as a best practice approach to making that determination.

There are four questions that i think ought to be a core part of the ITIL BOK, not peripheral addons which cost thousands of pounds on ITIL Live, or a sixth (seventh? eighth?) book you gotta buy, or blog discussions:
- Should you do ITIL?
- To what level should you do it?
- How do you do it?
- How do you show you did it?

ITIL 4 I guess.

I'm just finishing an article on this.

Another approach

My approach in ITSM consulting is this:

1 Find out what are the main problems (issues if you do not like the p-word). This needs to have a customer perspective.

2 Help the customer study itil and see if there are solutions to those issues. It is easy to forget that itil has a lot of good ideas and there are many people who have not yet heard and/or understood those.

3 If yes, start an improvement program, using itil as a tool. Ken's list about cost etc. applies.

- Short term goal: one step at a time, usually there are a lot of things that do not cost much. Keep repeating 1,2,3.

- Long term vision: be ISO 20000 compliant. In this model, my customer will never reach ISO 20000 level, unless their customers require it

Instead of maturity numbers, I use ISO 20000 as a yardstick, 100% being fully compliant. I have seen calculations of what it means as maturity and the numbers vary by process.

Aale

Syndicate content