Critical Path:
Applying the Capability Maturity Model
By Jeff Gainer
(Author’s note: This article appeared in the May 1998 edition of the itmWeb Report.
Last month in Critical Path, I outlined the principals behind the bottom-up concept of the "best practices" approach to software improvement. To recap, the "best practices" approach seeks to identify and preserve key elements of intellectual capital on a software development organization. By nature, "best practices" is informal. The Capability Maturity Model, however, is a far more prescriptive, structured approach.
Like best practices, the Capability Maturity Model was initially funded as a military research project, but its method of process improvement could not be more different. Where the best practices approach is "bottom up" and quite informal, the Capability Maturity Model is rigid, "top down," and prescriptive. The United States Air Force funded a study at the Carnegie-Mellon Software Engineering Institute to create a model for the military to use as an objective evaluation of software subcontractors. The result was the Capability Maturity Model, published as Managing the Software Process in 1989. The CMM has since been revised and updated; version 1.1 is now in print and the entire text is available on-line at the SEI's Web site.
The CMM ranks software development organizations in a hierarchy of five levels, each with a progressively greater capability of producing quality software. Each level is described as a level of maturity. Level One, the "Initial" level is, unfortunately and overwhelmingly, the most common. Currently an estimated 75% of software development organizations exist at this level, which can be best described as chaotic. At this level, there is little or no formalization, and processes, if any, are ad hoc. Project success depends on individual heroics and more often than not, sheer good fortune. But when the heroes leave the organization, their history of success leaves with them.
At the next, or "repeatable" level, at least basic project management activities are in place, such as configuration management and requirements management. Another step up the scale is the "defined" process level, where basic quality assurance and quality control activities are defined and practiced, such as defined standards, a defined process, structured walkthroughs and formal testing. Beyond this level, the population of software development organizations become more rarefied. At the "managed" level, there are fewer than 2% of software development organizations, those who have formalized processes for collecting and analyzing quality metrics. The highest level, the "Optimized" process, is characterized by self-optimized quality improvement.
Seeking formal assessment and improvement under this model can be time consuming and expensive, but the rewards in the quality of the software product and predictability of quality in future products are very real. Unfortunately, there is often significant resistance in some organizations to a formalized process, particularly in the "cowboy" cultures so common in the United States. Indeed, some organizations are so preoccupied with market and daily demands that a serious process improvement initiative is not only a fantasy, but positively laughable. Some pundits have designated these organizations as "Level Zero." Below these are those organizations which I call "Level Minus-1", those who deny the value of any process improvement on quasi-religious grounds.
Frequently I consult with managers at small and medium-sized organizations who genuinely want to improve their processes, but despair at being able to draw any time or resources from their existing operations. Unfortunately for them, formal process improvement requires time, dedication, and management oversight, things that too many managers are unwilling to commit, regardless of its obvious benefits. Additionally, many smaller organizations rightly view the CMM as designed for large shops, thus they cannot see its direct value to them. For these organizations, I recommend an "formal-informal" approach to process improvement. Management can actively take ownership of and responsibility for process improvement, using the CMM as a blueprint, that is, a guideline for their own plan. This way, they can actively improve their software process without the full demands and costs of formal assessment. It is very possible for an organization to apply sound project management principals on their own and bring an organization's efficiency to a Level 2 or even Level 3, albeit without a formal certification. But then, if the goal is to produce a better product, what does the certification matter, anyway?
Next month in Critical Path: I'll have a report from the Cutter Consortium Summit 97, including a few choice bits of useful Australian slang from the inimitable Rob Thomsett.
Copyright
1998, by Jeff Gainer