Capability Maturity Model Integration (CMMI) Definition and Solutions

Capability Maturity Model Integration (CMMI) topics covering definition, objectives, systems and solutions.

What does CMMI mean?

CMMI stands for Capability Maturity Model Integration.

CMMI is a framework of best practices. The current version, CMMI-DEV, describes best practices in managing, measuring and monitoring software development processes. The CMMI model does not describe the processes themselves; it describes the characteristics of good processes, thus providing guidelines for companies developing or honing their own sets of processes.

It is described on the official CMMI website thusly:

The Capability Maturity Model Integration (CMMI) project is a collaborative effort to provide models for achieving product and process improvement. The primary focus of the project is to build tools to support improvement of processes used to develop and sustain systems and products. The output of the CMMI project is a suite of products, which provides an integrated approach across the enterprise for improving processes, while reducing the redundancy, complexity and cost resulting from the use of separate and multiple capability maturity models (CMMs).

Where did it come from?

CMMI is the successor to CMM (Capability Maturity Model). Both CMM and CMMI were developed at the Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh, Pa. CMM was developed in the late 1980s, and retired a decade later when CMMI was developed. CMMI v1.02 was released in 2000.

The current version, released in August 2006, is CMMI 1.2.

A Little History

Since CMMI inherited much of its structure from CMM, let's take a look at CMM's genesis and reasons for being to get an idea of how both models were meant to be used.

CMM was developed as a result of a study financed by the U.S. Air Force as a way to objectively evaluate the work of software subcontractors. The Department of Defense, concerned over escalating software development costs and issues with quality, established the SEI in the early 1980s, and work on the CMM began in 1988. It was first described in the 1989 book, Managing the Software Process, by Watts Humphrey, director of the software process program at the SEI, and in August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI.

The CMM was originally intended to be a tool to evaluate the ability of government contractors to perform a contracted software project. Though it was designed to measure software development, it has been, and continues to be, applied as a general model of the maturity of processes in both IT and non-IT organizations.

The model identifies five levels of process maturity for an organization:

  1. Initial (chaotic, ad hoc, heroic): The starting point for use of a new process.
  2. Repeatable (project management, process discipline): The process is used repeatedly.
  3. Defined (institutionalized): The process is defined/confirmed as a standard business process.
  4. Managed (quantified): Process management and measurement take place.
  5. Optimizing (process improvement): Process management includes deliberate process optimization/improvement.

There are key process areas (KPAs) within each of these maturity levels that characterize that level, and five measures for each KPA:

  1. Goals
  2. Commitment
  3. Ability
  4. Measurement
  5. Verification

Companies were expected to be formally assessed as to their maturity level. As they achieved each level, they formed a plan to get to the next. However, the rigorous processes required precluded the advancement of many commercial software companies beyond level 1.

Critics also noted that the CMM was too firmly entrenched in the waterfall development model, and didn't address other facets of the software development process such as design and deployment. It didn't adapt to peripheral processes involved in software development, such as acquisition. They complained that CMM generated too much paperwork and too many meetings, and that it wasn't a good fit for many industries.

Industry and government sought to solve the problem by adapting the CMM to other areas. After the original CMM for software (SW-CMM) was released, the Enterprise Process Improvement Collaboration (EPIC), a group of representatives from industry and government, developed and published the Systems Engineering Capability Maturity Model (SE-CMM), and the International Council on Systems Engineering (INCOSE) developed and published the Systems Engineering Capability Assessment Model (SECAM). Other CMMs were then added to the mix, including the Software Acquisition CMM, the People CMM and the Integrated Product Development CMM.

The Electronic Industries Alliance (EIA), along with EPIC and INCOSE, began an effort to consolidate the two systems engineering CMMs, resulting in the Systems Engineering Capability Model (SECM) that was assigned the designation EIA/IS-731. Other organizations also developed CMMs that integrated several disciplines, resulting in CMMs such as the Federal Aviation Administration's integrated Capability Maturity Model (FAA-iCMM). The alphabet soup was getting out of hand, so when the SW-CMM Version 2.0 was completing its review process, the Office of the Undersecretary of Defense for Acquisition and Technology (OSD) decided that the CMM Version 2.0 should be canceled as a standalone CMM, and the CMMI project be undertaken collectively by industry, government and SEI to pull everything together.

The entire process is overseen by a steering group, which is composed of representatives from OSD, Air Force, Army, Navy, other government, SEI and industry. Its mission is to direct and oversee the development of the CMMI product suite, including approving CMMI products for review and public release. SEI handles project management in collaboration with subject matter experts, initially in software, systems engineering, and integrated product and process development. Stakeholder/reviewers are chartered to review, comment and make recommendations on the CMMI products developed. They also consist of representatives from industry, government and the SEI.

So, as you see, CMMI isn't exactly new. Rather, it's an amalgamation and adaptation of the many CMM variants that grew up in response to industry demands. Understand CMM and where it came from, and you'll see the foundation of CMMI. For example, CMMI defines maturity in the same five levels as its predecessor, with the same KPAs. Its models consist of 22 process areas organized into four categories: process management, project management, engineering and support. And it's used in most of the same places—think evolution, not revolution. CMMI brings together the collective wisdom of the various industries that tweaked the CMM to suit themselves.

What is CMMI used for?

Commercial and government organizations use the CMMI models to assist in defining process improvements for systems engineering, software engineering, and integrated product and process development.

Organizations use the processes to help them develop, acquire and maintain products and services, and to benchmark themselves against others. Better processes can mean lower costs and better quality results, as well as more realistic timing estimates for projects.

However, like any framework, CMMI is not a quick fix for all that ails a development organization. SEI cautions that improvement projects will likely be measured in months and years, not days and weeks. Because they usually have more knowledge and resources, larger organizations may find they get better results, but CMMI process changes can also help smaller companies.

The SEI does not offer certification of any form (anyone who tells you otherwise is fibbing, probably for profit). It simply licenses and authorizes lead appraisers to conduct appraisals. Companies may report their results on the published appraisals website, but it is not mandatory.

Why should I bother with it?

SEI intends its models and appraisal methods for use in self improvement, to help raise the level of quality of products and assist companies in better predicting the time and budget required to develop them. The models help create an environment to support these functions in a repeatable way. Continual improvement is built into the models.

Obtaining the greatest value from adopting the models' processes involves three key components:

  • Understanding the new practices
  • Not treating them as engraved in stone, but adapting them to the environment
  • Sticking with the changes long enough for them to make a difference

A formal appraisal can give a company an idea of the maturity of its processes, and help it create a road map toward improvement. After all, you can't plan a route to a destination if you don't know where you currently are. Organizations may tailor the use of the models to suit their own needs and the needs of the specific project. SEI says that the models:

  • Guide process improvement efforts and help organizations establish and achieve improvement goals.
  • Provide a common language for cross-organizational communication and benchmarking.
  • Provide an integrating, organizing framework for organizational endeavors.
  • Help an organization understand what specific practices to perform, how to improve its capability in performing those practices, and what process areas to focus on next.

Organizations may also use the results of appraisals for source selection or verification of another organization's maturity level.

Is CMMI for everyone?

CMMI, for all its strengths, does not suit every organization. As with any framework or methodology, its implementation often fails, not necessarily because of flaws in the concepts, but because the organization's execution misfires.

Issues can be cultural. For example, CMMI has been called "death by process." If your people are not already strongly process-oriented, CMMI is likely unsuitable without extensive training (and possibly some attitude adjustments). Trying to overlay CMMI on existing processes without first doing a gap analysis to see if there's a fit can be a recipe for failure. Also, critics complain that CMMI (like CMM before it) demands a great deal of documentation from users.

Getting there is not necessarily half the fun, either. Appraisals and consultants can be very expensive. SEI says that an appraisal team consists of four to nine members (each of whom can cost more than $1,000 a day). And appraisals, like Rome, are not built in a day—or even two or three. The team doesn't just chat with a few people or look at one project; it does a serious examination of several projects.

What improvements can I expect?

SEI provides reports on performance improvements to give prospective users of the models an idea of improvements some have achieved. For example, one organization reported that achieving CMMI maturity level 3 allowed it to reduce its costs from rework by 42 percent over several years, and another described a 5:1 ROI for quality activities in a CMMI maturity level 3 organization. SEI provides several descriptions of quantified improvements that you can explore.

The following table from the SEI website contains a summary of the performance results reported by 25 organizations, stated in terms of performance change over time:




of Data

Low High
Cost 20% 21 3% 87%
Schedule 37% 19 2% 90%
Productivity 62% 17 9% 255%
Quality 50% 20 7% 132%
Customer Satisfaction 14% 6 -4% 55%
Return on Investment 4.7:1 16 2:1 27.7:1

What's SCAMPI?

The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) provides quality ratings using CMMI models. The SEI licenses partners to perform SCAMPI appraisals and trains the appraisers.

There are three classes: A, B and C. SCAMPI A looks at maturity levels and is the basis for ratings, while B and C look at approach and deployment.

What's the future of CMMI?

CMMI was designed with expandability in mind. SEI has a process in place for the addition of new disciplines to the CMMI product suite; the framework groups best practices into what are called "constellations." A constellation is a collection of CMMI components that are used to build models, training materials and appraisal documents.

The CMMI model architecture was recently altered to support multiple constellations and the sharing of best practices among constellations and their member models. Thus, CMMI for Services and CMMI for Acquisitions will shortly join the development product in the CMMI constellations.

Lynn Greiner works in IT for a multinational corporation by day, and by night is an award-winning technology journalist.

NEW! Download the Winter 2018 digital edition of CIO magazine