CMMI, practically speaking

Despite this, there are many good things about v 1.2, such as the improvements in the appraisal process in v 1.2 - better disclosure statements and the three year appraisal lifespan. Since CMMI is all about process improvement, the fact that CMMI itself is evolving and improving is a good sign, and Ms Bush's concerns are being addressed.

Another valuable presentation came from Gary Guttridge, looking at the integration of CMMI and ITIL (and he delivered some brownie points for this conference, as you're generally more likely to hear about CMMI at ITIL conferences than ITIL is at CMMI ones).

ITIL is a set of best practices for operational service support, and is currently being updated (as Version three) with a services lifecycle framework. It is becoming ubiquitous as a framework for operational support worldwide (although it is perhaps more popular outside of the USA, perhaps) and it is more successful, in terms of uptake, than CMMI.

Guttridge pointed out, however, that there's precious little overlap between ITIL and CMMI, with both communities operating in their own silos. They are also different in approach, with ITIL being more compliance focused (ISO 20000 certification is available), whereas CMMI is about internal process improvement.

Nothing in ITIL should cause problems with CMMI appraisal; but, on the other hand, ITIL capabilities probably wouldn't be recognised explicitly (the same applies to ITIL ISO certification and CMMI appraisal, in reverse). In fact, when Jay Douglass was asked about ITIL support in CMMI-SVC, in another session, he admitted that the SEI was rather US-focused and probably didn't care about ITIL much.

This really should be a CMMI issue, as ITIL is an obvious approach to actually delivering real IT service support in a high maturity organisation – CMMI is at a higher level than ITIL and should help you to implement ITIL effectively (many ITIL "best practices" involve high-maturity processes).

Nevertheless, there are initiatives in CMMI that synthesise a common view from both CMMI and ITIL (Lamri is involved in one) but these are not really mainstream in the ITIL community; neither are they widely adopted. The consensus seems to be that ITIL and CMMI are complementary (most CMMI adopters will probably take up ITIL as well), although Guttridge was rather pessimistic about the possibility of formal cross-fertilisation - people feel comfortable in their silos and tools vendors are very happy about selling tools twice over, once to the developers and once again to Operations.

This is both a pity (because the business is interested in service, not product, delivery from IT these days) and an opportunity for an IT organisation to add value by synthesising both approaches for itself. As tool vendors go, Guttridge singled out MKS for praise, as it supplies a rich configuration management toolset that can support both development and operations at the same time – and since today's mantras for developers include "deliver business services" and "design for operations manageability" this may well merit a look.

"Leo" from GCHQ presented one of the more useful case studies, because it examined the "dark side" of the CMMI adoption process as well as a success story. One of the key people issues you'll meet with CMMI seems to be top management support. Management "sponsorship" and enquiries as to "how's delivery coming?" are simply not enough; management should be saying something like "I understand the CMMI process - now, how can I help.

People implementing process improvement also need rewards - and if the head honcho at the end of a speech recognising progress in process improvement also sticks in a recognition of the long hours put in by the fire-fighters in the organisation, everybody takes away a wrong (but a very realistic) message about the real importance of process maturity. CMMI is about "getting it right first time" and discourages fire-fighting; but many managers got to where they are by being successful fire-fighters (where "success" didn't have any very defensible "lifecycle cost" metrics). This can be a problem.

I've only had room to touch on the presentations at this conference. All levels of familiarity with CMMI were catered for, and CMMI was placed in context against Six Sigma and Lean, as well as ITIL and IBM's RUP process. Case studies came from a range of experienced practitioners ranging from Mark Smith of Accenture to Ramona Demure of AppLabs. The latter was particularly interesting as it covered the journey to Maturity Level 5 in an Indian software QA and testing organisation as an alternative to the usual general development shop.

The conference chair was Peter Mothersill, with over 20 years' experience in senior management in various technology sectors, including periods with ITT, Rockwell Corporation, BAe and Colt Internet. The conference was sponsored by the DSDM Consortium, Holagent Europe, IBM, Lamri, MKS, Pearson Education and Telelogic.

All in all then, an extremely useful conference for anyone (whether contemplating formal CMMI or not) interested in software development process improvement – and, these days, what developer isn't?