As seen elsewhere...

A recent thread over on the extremeprogramming Yahoo! group delved into whether or not CMMI sucks. One sub-thread was orbiting on the topic of Generic Practices.

As some folks know, the Generic Practices are what lead to the "institutionalization" of process improvement. In discussing this concept, the following lengthy (in text) but concise (relative to studying CMMI) explanation was given as a way to understand "institutionalization" by understanding the "Capability Levels" in CMMI.

The full post is here. The relevant text follows with small edits indicated by []s:

=-=-=-=-=-=
"Institutionalization", besides being a ridiculously long word, refers to the depth to which you have knowledge of your process. Institutionalization also often implies the extent to which your processes are ingrained into your organization, but really, when you look at what institutionalization involves it's more about how well you know your processes, not how widespread any given process may be throughout your organization.

At the lowest level at which anyone gets any 'credit', "institutionalization" is hardly the term appropriate for the state of the process. This is "level 1" where the process gets done, but by no means is it something you'd say any forethought, planning, or commitment was put forth into getting the process done.

The next level (level 2) is where we start to see some concerted effort towards treating the process as though it's something we cared about.

We see that the process is something someone in charge wants to be done (a.k.a. "policy"), we see that we know what tasks are involved in executing the process (a.k.a. "plan"), we see that resources have been allocated towards doing these tasks and that the tasks have been assigned as someone's responsibility.

If training for the project's execution of the process is needed, that's done at this level as well. We'd also expect that we'd see the outputs of the process as something we cared about so we'd control the outputs so that we could appropriately version, find, and update those outputs over time.

Given how much we've already invested in this process, it makes sense then to involve those folks who hold a stake in the outcome and to monitor the process' progress and activities, making changes to the plans, scheduling, or resources as needed to keep the process rolling.

We'd also want to keep tabs on whether the process is meeting the objectives of why we wanted the process done in the first place. And, finally, we'd review all of these process-oriented activities with people who can make decisions about the cost/ benefit/ value/ funding/ resources associated with the process fairly regularly over the life of the project.

These activities comprise what CMMI calls a "managed" process. An organization needs to know what process it's going to follow and what makes up that process if it's going to manage it. Thus comes the notion that the process is "institutionalized" as a "managed" process. We know enough about the process to manage it.

Beyond this level are 3, 4, and 5. Sometimes it's easier to understand "why" level 3 by looking at levels 4 & 5 first. At level 5 you know enough about your process that you can optimize it by eliminating the "noise" in the process.

A noisy engine can often be quieted by simply tuning it. Adjusting fuel, air, timing. But there's nothing outside the engine that's causing it to be noisy, it's just the engine itself. A noisy engine usually means inefficiency. The noise is just a symptom of that inefficiency. The same is true for processes. But in processes, true noise elimination is something that can realistically only be done mathematically. So, at level 5, the noise is found and reduced using models and statistics. Noise usually isn't spread all over the process, it's usually limited to some particular subset of the process. Usually, it's just some sub-process of the process on which statistics are applied.

Before you can get to this point, however, you must first be able to eliminate (or at least control) external factors that unnecessarily influence your process. This isn't "noise" because noise comes from the process, just like in an engine. And, just like in an engine, this is more like a rattle or a knocking sound, or even blunt-force damage. Something is either very broken or badly impacted by something related to, but not in control of, the engine. [In other words, the engine/process in not fully in control.] But, unless we know what the engine is expected to look like and operate we don't really know where to look to eliminate the issue. We need (with engines) the engine's shop manual which includes its diagrams and models. With processes, it's the same.
[]
We need to be able to model them before we can determine what's supposed to be there and what's not. [I.e., we need to know what an "in control" process looks like and what it's capable of doing.] The engine shop manual has performance specifications, and so do the processes at level 4. Capability Level 4 produces the models and performance expectations for each process as well as for the project itself. Without these we can't get to level 5 because, while there's certainly noise in the system at level 4, there are also too many other special causes of variation [let alone whether or not the process is in control] that must be eliminated before we can start to optimize in level 5.

Together, levels 4 & 5 are very much parallel to what many people know today as "Six Sigma".

So, now there's level 3. What's in there? If levels 4 & 5 are about getting to the point where we know so much about our processes that we can use statistics to eliminate process variation and noise, then capability level 3 must be where we eliminate chronic waste. How do we discern the chronic waste from the "necessary" activities? Well, we must first define the process so that we can then improve it.

There's no point in trying to improve a process that's not defined, and, there's no point in trying to define a process that's not even managed, and no point in trying to manage a process that no one does, wants, or needs.

This is what the generic practices of CMMI do. They create an infrastructure to better understand the process toward the ability to optimize it. Starting with doing the process, then managing it, then defining and improving it, then getting into statistics to model and predict performance which ultimately opens the door to optimization.

Believe it or not, organizations at (true) levels 4 & 5 are highly agile. They can pretty much roll with anything that's thrown at them. True level 4 & 5 organizations are NOT straight-jacketed by their processes, they're actually freed by them. If anyone is in (or has been in) a so-called "level" 4 or 5 organization and felt stifled, I'd wager the organization was not really "in it" for the improvements.