Measuring Levels Is Not Enough

As indicated, most organizations that follow a model-based approach to process improvement designate a process improvement team, typically called the Software Engineering Process Group (SEPG), to spearhead the effort. Working under the auspices of a senior management sponsor, the SEPG is responsible for documenting, deploying, and improving the processes suggested by the corresponding model.

Imagine that six months ago your senior management directed your SEPG to achieve CMMI maturity level 2 within a year. As an SEPG member, you have invested extensive (some might say "excessive") time and effort generating all the required policies, procedures, templates, measures, checklists, and training materials, but you are now having trouble getting the development projects to pilot and adopt any of these new process components .

Being a reasonable, proactive change agent, you solicit your sponsor's assistance. The sponsor eloquently reminds project personnel how important it is to reach their target maturity level and urges them to be more open to helping the organization achieve this distinctive honor . The sponsor instructs software quality assurance personnel to be more aggressive in explaining the value of all this new process stuff and in identifying process deviants. But nothing really changes; the process assets continue to gather dust and the SEPG's frustration continues to mount.

Why are the project teams being so difficult and how can the SEPG achieve maturity level 2 if they don't get with the program? Why aren't they helping the SEPG to be successful?

But wait a minute . . . why is the organization doing process improvement? They're not really doing it to "achieve CMMI maturity level 2"; they're doing it to improve . They shouldn't be forcing the projects to grunt through a pile of administrivia to accommodate the CMMI; they should be employing process aspirin to relieve project pain. Perhaps they can exploit the CMMI to help the projects achieve greater success!

Let's check this hypothesis by determining which of two possible results would be preferred:

1. The organization is assessed at CMMI maturity level 2, but the projects achieve no measurable improvement; or
2. The projects achieve measurable improvement, but never achieve CMMI maturity level 2.

Unless there are compelling business reasons to reach a particular CMMI level (i.e., your customers will not allow you to bid on work unless you have been assessed at maturity level 2), if your answer is A, you've probably been in the "quality" organization too long!

On the other hand, if the SEPG continues to help the projects succeed, its value will be recognized and the group will overcome much of the natural resistance to change. In addition, if the projects continue to demonstrate sustainable improvement, the CMMI level will ultimately come. Remember that using the CMMI is merely one tactic to achieve a higher-level (no pun intended) business strategy through the execution of successful projects.

The CMMI maturity level is intended to be a leading indicator of the organization's process capability, but the real value of process improvement is in running more successful projects. The organization shouldn't merely measure the CMMI maturity level; it should also monitor the additional value derived from the implementation of these improved process elements.

Many organizations use the acronym SPI to mean "Software Process Improvement." The organization should consider keeping the SEPG focused properly by changing the meaning of "SPI" to Software Project Improvement and establishing the SEPG's motto as: "If we are not helping the projects achieve measurable improvement, we are failing!" The projects do not exist to help the SEPG achieve success, but rather the other way around.

One of the critical steps in beginning (and continuing) with a CMMI assessment is to develop a process capability baseline, which serves as the basis for determining what to improve and to assess progress along the way. These desired outcomes might include:

• Delivered quality
• Productivity
• Schedule
• Reduced overtime
• Defect injection rate
• Defect discovery rate
• In-process defect removal efficiency
• Defect distribution