We've been writing a few things recently around "process maturity"—and not just for ITA/ITD. For instance, about ASG's Senior Director of Solutions Management, Mike Oitzman's view that a certain degree of organisational maturity is needed before a full CMDB implementation is likely to be successful.

This reminds us that we don't see very much in the way of IT development or operations process that wasn't around 20 years ago—the jargon is a bit different and the implementing technology is sometimes cheaper, that's all—we've known how to "do" IT in general ever since the days of Fred Brooks (see the Mythical Man Month). Things really haven't changed much: when you start a new initiative you worry about whether the technology works; but when it goes wrong, it's probably the people issues and (lack of) process that bit you on the ankle.

But there are very simple ways of dealing with this. Deciding what will be defined as "success" before you start helps; as does defining some metrics for business service delivery and managing stakeholder expectations. And, it's a very good idea to review any initiative after it's been delivered, to see if it met your success criteria and delivered on stakeholder expectations. If it fell short in any way, why not work out why—and really, really resolve not to do those things again—and, while you're about it, share this knowledge with the rest of the organisation? After all, trying something that is broken over and over again in the hopes that it'll work next time, doesn't have a great track record (apart from in rebooting Windows desktops, perhaps); and why would any organisation only want some of its projects to follow "best practice"?.

What we're really talking about here is "organisational maturity" and "process improvement". As we've pointed out, we know, in general, how to deliver IT services to the business. When we fail it's not (usually) because we don't know how to do it or don't have the technology, it's because we don't have the maturity to use our knowledge and technology effectively. We buy technology from our favourite suppliers regardless of whether it really meets our needs (possibly because we're lazy or because our manager gets wined and dined by the rep); we choose inefficient solutions because they let us grow our empire; we optimise the delivery cost rather than the lifecycle cost of a solution because that's easier to measure; we don't share knowledge because we won't get our bonuses if the rest of the organisation doesn't make mistakes that make us look good; we never analyse what went wrong in case we get blamed for any issues we identify; and we certainly never measure anything properly in case our boss doesn't like what the measures show.

All these dysfunctional things are the signs of a "low maturity" culture which, unfortunately, can be an exciting and remunerative place for "heroes" to work in. That is, for people who enjoy risk and firefighting, and who just love getting a reputation for working hard by building everything several times over and getting paid bonuses for fixing their own mistakes on 03:00 am callouts. The trouble is, low maturity is great for heroes and rotten for the organisation as a whole, especially when it's going into a recession.

There is a better way. Get it right first time. Deliver what the business wants in a realistic timescale and go home at 17:00 and play with your kids or go out to the theatre. And one way of arriving at that "better way" is CMMI (Capability Maturity Management Integrated) process improvement from the SEI at Carnegie Mellon, following a journey from Maturity Level 1 (ML1) to Maturity Level 5 (ML 5). And now we've lost just about everyone reading this, because "everyone knows" that CMMI bogs you down in paper and stops you getting anything done; it stifles creativity; it's incompatible with Agile; it's only for big companies and the defence industry in the USA; it's totally impracticable and costs a fortune without delivering anything.

Well, what "everyone knows" is wrong—although there are a lot of CMMI anti-patterns that can justify "what everyone knows" if they're all you're looking at. For a start, you can try claiming "CMMI certification" [actually, you can't certify against CMMI] for the whole organisation on the basis of an informal appraisal of a team of three people working for the Icelandic office 10 years ago—and then give give the whole CMMI thing to the marketing department for use in your advertising campaigns. And, no, that isn't a "Bloor Recommendation".

That scenario won't impress anyone who knows about CMMI, who'll want to see details of your appraisal on the SEI website (the published appraisals list is here) and to ask about the kind of appraisal you underwent, and who carried it out; and to know about the scope of the appraisal; and about the timetable for repeat appraisals [an appraisal over 2 years old is considered invalid by the SEI]. We could write a white paper about how to waste money on doing CMMI wrong—but we suggest that you don't bother to buy it from us. However, the possibility of dysfunctional CMMI, especially when management picks up the idea and doesn't follow it through, perhaps explains why there's apparently a movement towards "viral CMMI", which doesn't use the CMMI word. And this is not just about companies like ASG coming up with multilevel maturity models of their own.

A story. We once met someone who was trying to introduce CMMI Process Maturity into a firm that was also introducing Agile eXtreme Programming. Eventually, the two teams had to meet; and so, with very deep misgivings, they did. The CMMI people expected to meet a bunch of cowboys and the XP people expected a lot of boring old farts carrying stone tablets and chisels.

The meeting went something like this:

[CMMI guru]: Well, where's your process manual?

[XPcowboy]: {Picks up the well-thumbed Kent Beck bible from his desk, nervously} "We have this book, the book what Kent wrote..."

[CMMI]: {doubtfully} "But that's in your library, right, or on the bookshelf? What do you actually use day-to day?"

[XP] {incredulously} "No, we all have our own copies, I read mine every day on the bus home... What are these 'bookshelves' whereof what you speak? What arcane SEI technology is this?"

[CMMI] {surprise} "Right, I'll tick off "process" then. Now, what about "User Requirements..."

[XP] {with rising confidence} "We have all these "user stories" on cards stuck to that whiteboard over there..."

[CMMI] {light dawning} "I see; and the whole team can see them all the time and keeps them up to date... Right, another tick..."

And they all lived happily ever after....

Although we suspect you'd have to pick your CMMI guru for this to work. And your XP team too—there a lot of "pseudo agile" teams doing "XP But". As in: "we do XP but we don't bother with pair programming... and all that testing is a PITA... and users really get in the way of getting prototypes writ..." A typical CMMI guru might just really annoy an "XP But" team like this. And a jolly good thing too.

But the sort of misunderstandings evident prior to this scenario could explain why there is "viral CMMI". Some people are reading about the CMMI process improvement techniques and using them in their own process improvement scenarios. Just not calling them CMMI—and not going in for formal CMMI appraisals. We're enthusiasts for ITIL v3 but we've always said that quite a lot of ITIL needs a high maturity level, in CMMI terms, to work—whether you use CMMI jargon or not. And we're interested that a friend of ours is, in effect, using an unofficial SCAMPI (Standard CMMI Appraisal Method for Process Improvement) appraisal process for her ITIL implementations.

ITIL represents a specific service delivery process; CMMI—despite the new CMMI-SVC for services—is really more at the meta-process level, we think; so ITIL and CMMI should be complimentary. But is this "viral", unacknowledged, CMMI a "good thing"? Well, it is probably a sign of the increasing grass-roots acceptance of capability and maturity management (when something succeeds, you stop talking about it and just do it). And, Pareto probably applies: informal CMMI may give you 80% of what is on offer for 20% of the cost, especially if you are working with a generally low maturity organisation. It is also probably a good starting point for adopting "proper" CMMI in the future.

However, in Part 2 of this article, we'll be talking to a company that has gone in for real CMMI appraisal at ML5—and look at just why you might want to do this.