ITSM's fixation with capability maturity
The ITSM community seems to have some fixation with assessing capability maturity, or worse still process management maturity. These are only indirect predictors for what matters: risk and cost-benefits.
Why do we assess maturity? Generally for one of two reasons: To prioritise our efforts or to measure progress.
Assessing capability maturity (what TIPA or ITIL PMM or COBIT measures) or process management maturity (what CMMI measures) is useful to measure progress. (It is only useful if we have a strong objective framework to assess against, or we make sure we get the same organisation and preferably the same person to do subsequent assessments. But that is another post).
Progress is of secondary importance [to initial prioritising. What use measuring progress if we start from the wrong place?] . Before launching into execution, we need to make the big decisions about where to focus our attention, to prioritise spending money across a portfolio. What use is maturity of any sort for that? None. "We are high in maturity at doing X and low at doing Y." So what? Does it matter that Y is low? Sure X is high, but is it high enough?
Not only is maturity useless for making portfolio decisions, it is a dangerous distraction. It is only ETF (Excessive Technical Fastidiousness) that drives us to say "we want everything at maturity 3". This is ITIL as religion: we are making decisions divorced from what matters.
I think there are only three measures directly connected to the desired outcomes when managing portfolio spend; value, risk and cost-benefit. Even Quality is just another view of maturity, another indirect metric. Why would we decide we need a certain level of quality? Because we risk losing business if we don't. (Nevertheless quality has a place, as we'll see.)
Especially in low-maturity organisations, "remedial" ones, I find risk is the best parameter for determining where to work on improving capability maturity. This is along the same lines as the "stabilise the patient" thinking of e.g. Visible Ops handbook (in fact remedial situations are all that the VOH book is good for - I'll do a review one of these years).
In low-value IT shops, it's all about reducing costs, and the ROI or cost/benefit ratio are the directly-related metrics for deciding where to improve.
In high-maturity organisations where IT is strategic and integrated, then the business value of the services delivered is clearly the measure to use, and one aspect of that may be to decide on quality improvement.
In all three cases - risk, ROI and VOI - improving process maturity should be part of the solution not of the planning and decision-making.
Made in New Zealand 
Comments
Blind spots
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 is a part of the picture
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.
holy of holies
Of course maturity is part of the picture. My issue - as always - is when something gets elevated to the holy of holies.
maturity profiles are a vision-aligned goal
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.
Love the ETF schtick
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.
Don Reinertsen
Cary have you checked out Don Reinertsen's stuff?
Charles T. Betz
http://www.erp4it.com
The antithesis of Lean?
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.
Charles T. Betz
http://www.erp4it.com
Flashbacks and flared trousers
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!