The IT Skeptic - Comments for "ITSM's fixation with capability maturity"

Flashbacks and flared trousers

ianclayton — Thu, 26 May 2011 23:43:35 +0000

CMM - well the model itself it ok. My problem is that its irrelevant how mature your ruddy process is if the customer thinks you suck.

We live in the 'service experiential' economy where a combination of the outcomes, service experience, and occasional hugs from support help satisfy customers, encourage them to be loyal, and then advocates, thus lowering the cost of operation and support.

Where is all that in a capability model? I'd like some of these evangelists to actually leave the building, sit next to a customer who is struggling to enter an invoice or order, and explain the relevance of having a 3.5 level mature incident management process.

How about we measure the maturity of a customer activity - enter sales order? Oh sorry - thats outside-in thinking - doh!

holy of holies

skeptic — Thu, 28 Apr 2011 00:59:17 +0000

Of course maturity is part of the picture. My issue - as always - is when something gets elevated to the holy of holies.

Maturity is a part of the picture

Paddling like heck — Wed, 27 Apr 2011 09:14:10 +0000

Skep,

Like normal, I largely agree with what you say. However.

ITSM maturity assessments, ISO20k assessments - these sort of things have their place, but of course one doesn't try to adopt ITIL because you scored lowly in terms of capability maturity. Black-box ROI is soooo year 2002.

I'm trying to get a 4 year Service Mgt ROADMAP developed (then............agreed...then..............implemented) that covers 4 "operational" streams - sell, build, support/run, plus a stream for each of IT finance, IT HR and IT governance. Each stream will (hopefully) take in:
* Vision for that year
* Customers (who's impacted, key customer interfaces, customer outcomes)
* IT people (structure, training, performance planning, culture)
* Key Processes (goals - for that year, CMM target, characteristics, dependencies (in, out))
* Underpinning technology (prod, tooling)
* Success measures (process mgt, process output, Service Level performance)
* Benefits realisation (function, target, $), some soft benefits around agility & scalability
* Improvement initiatives (contact, name, description, R, A, Start/end, benefits, overall outcomes)

So you'll see that CMM Maturity is one part of one part of my desired roadmap.

Fair enough - Risk Mgt is aggregated somewhere else and is everywhere...

PS: let me know how you're going with that PPT review.

Blind spots

aroos — Tue, 26 Apr 2011 06:40:42 +0000

Remember that measuring value, ROI and risk can be very difficult.

A maturity model is just a list of things that some people believe should be done and measuring maturity is a personal judgement. lt should be simple and transparent, a complex model tries to make the tool look more scientific and reliable while it only creates confusion. With a simple model you can easily see how you could improve the result and then decide would it be a good idea to do it. Unfortunately many people want to hide the mechanics and use complex models. I have seen some cases where the people who created the model did not really understand how it worked. In that case the probability of a calculation error is quite high.

For some reason organizations have a tendency to improve what is already good and ignore some other areas, and it is hardly ever an intentional choice. A maturity model may point out some blind spots in a convincing way.

Aale

maturity profiles are a vision-aligned goal

Stewart Johnson — Mon, 25 Apr 2011 13:48:51 +0000

I've always thought about this differently to the way you seem to think about it.

With the original CMM from SEI all the process areas were measured on the 1-5 scale and, as you talk about in this post, there wasn't much focus on why we should build maturity in one process instead of another or in any particular order.

With CMM-I they now have maturity profiles, and step 1 is to figure out what your organisation's profile should be based on a whole bunch of things (such as risk, value and cost-benefit). To put it in ITIL parlance, your maturity profile is effectively a set of goals that are aligned with your vision. That's the point where you come to those important decisions like "we only need 'level 3' maturity in change".

So I don't see focusing on maturity as a bad thing altogether, so long as there's a reason the organisation is targetting maturity X in process Y.

Hmmm, maybe we're saying the same thing after all.

Don Reinertsen

Charles T. Betz — Sun, 24 Apr 2011 22:54:49 +0000

Cary have you checked out Don Reinertsen's stuff?

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

Love the ETF schtick

CaryKing — Sun, 24 Apr 2011 15:51:17 +0000

I've always liked your ETF comments.

I'm not sure, however, that focusing exclusively on operational risk management is ideal.

It seems to me that costs are a constant constraint for any IT organization. Operational risks, therefore, should be considered within the cost constraint - risks should always be translated to cost probabilites, not just operational statistics. When we discuss things in terms of risk alone, that often leads to ETF.

Additionally, Risk, when evaluated without service levels, often leads to platinum plating of systems. Risks not only need to be evaluated within the context of costs, but within the actual business needs for that system and the systems that may be affected.

What often seems to happen is that risk analysis by technicians not mindful of cost constraints turns into a free-for-all of designing for six sigma reliability - when two sigma may be a more cost-effective choice.

It seems to me that our customers, the rest-of-the-business, can make better investment decisions when we offer them alternatives to system risk using Cost of Quality analyses.

Three or four mutually exclusive, collectively exhaustive choices is what we try to offer for every major decision. Yes, it sometimes takes a little more time - but, it seems to markedly increase the trust and faith customers have in IT's work.

The antithesis of Lean?

Charles T. Betz — Sat, 23 Apr 2011 21:35:44 +0000

I blogged along similar lines a while back... all of these frameworks can distract from the flow of value. They are too granular and encourage silo thinking. Even "improvement as silo" - a complete paradox, but that is the organizational result too often - dedicated "quality" groups. Ugh.