CMM is back to front

I think that CMM is back to front.

ITIL and COBIT use the term “process” much too loosely. I prefer the more general term “practice”. When I refer to "process" I try to mean a “real” process with inputs and outputs and a clearly defined transaction between them. Processes can be made repeatable, practices generally can’t.

In the real world as I experience it, we need to start measuring right away, especually to drive personnel performance management. This means finding KPIs and other measures that work right now in a world made up of a mix of processes and practices, and none of them tidily standardised and repeatable unit transactions.

The Capability Maturity Model (CMM and its almost incomprehensibly dweeby descendant CMMI) is widely adopted as a way of measuring process maturity, although it is in fact a way of measuring the maturity of managing the process not the maturity of how they are performed/delivered/executed. This is because the assumption is made that managing process is the same anywhere so you can use the same assessment model. By getting to mature management you reach the final phase where you are optimising the process, so therefore - the assumption goes - you get better at the actual execution of the process.

Whereas of course the model to measure directly how mature the actual execution is depends entirely on what the process is for. To measure that you need real capability maturity, generally measured using a process-specific model based on ISO 15504, a.k.a. SPICE. (E.g. a new SPICE-based ITIL assessment framework is called TIPA, or of course - although it never once mentions 15504 - COBIT 4.1 contains a maturity model.) But coming up with a process-specific execution maturity model is hard, whereas using a generic management model out of the box is easy. Which may explain the popularity of CMM-derived maturity models as a one-order-removed proxy for actual process maturity.

Anyhoo, CMM says we are to mature through the steps of: making it repeatable, defining/standardising it, and only then measuring it (in the sense of managing by measurement, i.e. measuring for assessment). Now to me the idea that we have to wait until maturity 4 to start measuring and maturity 5 to start improving might make sense on a physical production line but I dont think it makes sense in an IT organisation dealing with wetware production and virtual products. Measure early and measure often I say. If you can't find good metrics then measure anyway. (If you don't believe this can be done, read How to Measure Anything, one of the great business books.)

Then let people know they are being measured - that's the whole point of measurement. Make them accountable for the results. If the metrics aren't terribly good or specific they'll complain. What a great incentive to make better metrics which involves making process defined and repeatable.

I put it to you that CMM is the wrong way round. It should be: measured, repeatable, defined/standardised. And it should ALL be optimising from day one: don't use CMM as an excuse to leave process improvement until last.

Comments

Comment removed

Joe, you spam my site again and I promise you the IT Skeptic will be having a product roast.

Measure from the beginning

Absolutely with you.
It seems to me that most of IT's work is quite repeatable, although, perhaps not in the development areas.

Standardize the process and the tasks and measure it as soon as possible.
Get an activity diagram with swimlanes and a RACI with clear accountabilities defined for tasks and use cases going from week 1.

Using Design For Six Sigma, Time-Driven Activity-Based Costing, Standardized Bills of Material and Work Breakdown Structures, all driven with appropriate workflow engines seems to me to be the basic industrialization of IT so that we can measure execution and improve.

How else will you know what the cost of your services are? How else will you justify how much staff you have? Geez, how else will you know what services, and how many, you deliver?

Do it. Measure it. Fix it. Rinse. Repeat.

Troy DuMoulin and Rodrigo Flores called it "bottom up" service catalog development.
Seems to me it can/should lead to better thinking through of the outside-in customer experience, lean - what Ian Clayton's been talking passionately about for years now.

I'm not sure how much this really relates to ITIL, although ITIL does discuss some of this in CSI. Fundamentally, this is just good management - from Fredrick Taylor, Juran, Deming, Drucker...

You'll be surprised how fast this can be done...

A further comment on standardizing and measuring processes.

Just start.

You will be surprised just how fast this goes. Start with your top 10.

And, you'll be surprised just how much this improves your execution of these processes. Clients are always surprised just how many different "perceptions" of processes there are - this clears things up.

This is a great way to get your staff talking, get them involved. It's a great way to help them through the changes. Check out the Fair Process approach (HBR). This really pays off in staff morale building.

You don't need fancy tools - you can start with Visio. Although it is better to use a UML tool that's not expensive so you can more easily tie the Activity Diagrams, RACI and Use Cases together. Consult a book on how to create Work Breakdown Structures - the best ones for this purpose are from a manufacturing point of view. Create Legos of processes - mini-process sets that can be recombined.

Once we get our clients started with this, we just check in on them regularly - gotta keep thing moving and make sure they're not stuck.
Don't worry about ITIL or good practices references - just what you're doing now. You can modify things later.

Really, this works. This pays off huge in improved execution.

get them moving

One point Cary: I think you should start measuring in order to initiate the journey of defining process and making it repeatable. I don't find it so easy getting current process written down. People need to want to help, and that's where measurement comes in, to get them moving, up off their butts and on the journey. That is, before you even start to understand what's there, measure whatever inputs and outputs you can find.

For example, start measuring how many service desk tool tickets are being closed - by group and by individual. Suddenly staff start recording work they previously didn't bother. Suddenly they want the ticket assigned to them instead of insisting that all they need is an email. Suddenly they want better categories. Suddenly they want themselves and others to work more efficiently etc... and awaaaaaay we go!

Dweeby

As far as I know CMM and CMMI are meant for software development which is really hard to measure. But agree that the model is not so useful for service management.

A good choice for maturity assesment is ISO 20000. It does not describe levels but you can asses how far you are from the standard requirements. Unfortunately ISO 20000 is also full of non-processes.

Aale

PS
R U trying to put off us foreigners; and it looks like you are using the word out of context?
According to Urban Dictionary. Dweeby: Of, relating to, or befitting the characteristics of a dweeb (a despised person whom people look down on because they're despicably unorthodox and awkward in every aspect; uncool, nerdy, geeky).

cmmi service

re aroos i've just discovered cmmi for services http://www.sei.cmu.edu/cmmi/tools/svc/ which looks interesting.

I hadn't thought about Skep's point before but he's right. Like any phrase there's flaws in it but I do like "You can only manage things you can measure". If you're not measuring, your management is chaotic.

And skep - would you PLEASE stop coming up with new standards that I haven't heard of! my list of "important stuff to get a clue about" is growing faster than I can handle. Just added ISO15504

CMMI-SVC

CMMI-SVC looks very good as a measurement tool, except it is couched in the dweeby language and thinking of CMMI. I suspect it is inaccessible to we mere mortals.

Actually I don't agree that "You can only manage things you can measure". Good managers don't need measurement, they use measurement.

Syndicate content