Like a broken record...

No, it's not my rendition of Einstein's definition of insanity...

So I've been saying the same thing over and over again lately... maybe because it's so succinct and readily accessible to even the least process-oriented among us.

It goes something like this:

"CMMI is a model from which we build process improvement systems."

That's it.

All you need to understand to internalize this is the notion of a model and the notion of a process improvement system.

If you can wrap your head around these two notions the CMMI and what it's not simplifies a lot.

How?  Just consider the notion of a model: an idealized, often fictitious, representation of a particular instance of reality, that's usually missing much of the detail that the real object represented by the model would include.  What that means is that models can't be applied directly as a solution.  One must take a model, learn from it, then combine it with their own knowledge and context of how they plan to use it in order to create something in the real world. Mixed into this would be the details to make what started as a model into a usable system.

Think: model of an aircraft or home or building. Even human models used in magazines are two-dimensional -- lacking in everything that makes them real humans except their appearance. Even life-sized enlargements of a photo are still just models. In fact, if we explore the fashion model idea further we could see many more appropriate parallels between the idea that a model is as incomplete as it is an idealistic version of reality.

I'm finding more and more that it's this basic gap in people's understanding of what a model is, and/or in their ability to take a model and build something from it that gives rise to so many failed CMMI implementations. And, it's these (often spectacular) failures that provide the casual observer their negative impressions of what the CMMI is and how it's meant to work or what it's meant to do.

In a recent conversation with someone hired to speak on agile methods and to contrast them with CMMI, it was this misplaced impression that he began the conversation. As soon as we discussed the concept of "model", his (very authoritative) opinion on the matter was shifted.  In fact, the content of his lecture was altered. He could completely see how CMMI and agile methods are not intrinsically at odds. After all, how can a model be at odds with a development approach when one of the model's elements says, in effect, "pick a development approach"?

So, what does it take to take a model and from it create a real-life system?
That'll be my next topic.

(Hopefully sooner than in a month.)
;-)