The Capability Maturity Model (CMM) is a development model created in 1986 after a study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. The term "maturity" relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.
The model's aim is to improve existing software development processes, but it can also be applied to other processes.
In 2006, the Software Engineering Institute at Carnegie Mellon University developed the Capability Maturity Model Integration, which has largely superseded the CMM and addresses some of its drawbacks.[1]
The Capability Maturity Model was originally developed as a tool for objectively assessing the ability of government contractors' processes to implement a contracted software project. The model is based on the process maturity framework first described in IEEE Software[2] and, later, in the 1989 book Managing the Software Process by Watts Humphrey. It was later published as an article in 1993[3] and as a book by the same authors in 1994.[4]
Though the model comes from the field of software development, it is also used as a model to aid in business processes generally, and has also been used extensively worldwide in government offices, commerce, and industry.[5] [6]
In the 1980s, the use of computers grew more widespread, more flexible and less costly. Organizations began to adopt computerized information systems, and the demand for software development grew significantly. Many processes for software development were in their infancy, with few standard or "best practice" approaches defined.
As a result, the growth was accompanied by growing pains: project failure was common, the field of computer science was still in its early years, and the ambitions for project scale and complexity exceeded the market capability to deliver adequate products within a planned budget. Individuals such as Edward Yourdon,[7] Larry Constantine, Gerald Weinberg,[8] Tom DeMarco,[9] and David Parnas began to publish articles and books with research results in an attempt to professionalize the software-development processes.[5] [10]
In the 1980s, several US military projects involving software subcontractors ran over-budget and were completed far later than planned, if at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the Software Engineering Institute (SEI).
The first application of a staged maturity model to IT was not by CMU/SEI, but rather by Richard L. Nolan, who, in 1973 published the stages of growth model for IT organizations.[11]
Watts Humphrey began developing his process maturity concepts during the later stages of his 27-year career at IBM.[12]
Active development of the model by the US Department of Defense Software Engineering Institute (SEI) began in 1986 when Humphrey joined the Software Engineering Institute located at Carnegie Mellon University in Pittsburgh, Pennsylvania after retiring from IBM. At the request of the U.S. Air Force he began formalizing his Process Maturity Framework to aid the U.S. Department of Defense in evaluating the capability of software contractors as part of awarding contracts.
The result of the Air Force study was a model for the military to use as an objective evaluation of software subcontractors' process capability maturity. Humphrey based this framework on the earlier Quality Management Maturity Grid developed by Philip B. Crosby in his book "Quality is Free".[13] Humphrey's approach differed because of his unique insight that organizations mature their processes in stages based on solving process problems in a specific order. Humphrey based his approach on the staged evolution of a system of software development practices within an organization, rather than measuring the maturity of each separate development process independently. The CMM has thus been used by different organizations as a general and powerful tool for understanding and then improving general business process performance.
Watts Humphrey's Capability Maturity Model (CMM) was published in 1988[14] and as a book in 1989, in Managing the Software Process.[15]
Organizations were originally assessed using a process maturity questionnaire and a Software Capability Evaluation method devised by Humphrey and his colleagues at the Software Engineering Institute.
The full representation of the Capability Maturity Model as a set of defined process areas and practices at each of the five maturity levels was initiated in 1991, with Version 1.1 being published in July 1993.[3] The CMM was published as a book[4] in 1994 by the same authors Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis.
The CMM model's application in software development has sometimes been problematic. Applying multiple models that are not integrated within and across an organization could be costly in training, appraisals, and improvement activities. The Capability Maturity Model Integration (CMMI) project was formed to sort out the problem of using multiple models for software development processes, thus the CMMI model has superseded the CMM model, though the CMM model continues to be a general theoretical process capability model used in the public domain.[16] [17]
In 2016, the responsibility for CMMI was transferred to the Information Systems Audit and Control Association (ISACA). ISACA subsequently released CMMI v2.0 in 2021. It was upgraded again to CMMI v3.0 in 2023. CMMI now places a greater emphasis on the process architecture which is typically realized as a process diagram. Copies of CMMI are available now only by subscription.
The CMM was originally intended as a tool to evaluate the ability of government contractors to perform a contracted software project. Though it comes from the area of software development, it can be, has been, and continues to be widely applied as a general model of the maturity of process (e.g., IT service management processes) in IS/IT (and other) organizations.
A maturity model can be viewed as a set of structured levels that describe how well the behaviors, practices and processes of an organization can reliably and sustainably produce required outcomes.
A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes.
The model involves five aspects:
There are five levels defined along the continuum of the model and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief".[18]
Within each of these maturity levels are Key Process Areas which characterise that level, and for each such area there are five factors: goals, commitment, ability, measurement, and verification. These are not necessarily unique to CMM, representing — as they do — the stages that organizations must go through on the way to becoming mature.
The model provides a theoretical continuum along which process maturity can be developed incrementally from one level to the next. Skipping levels is not allowed/feasible.
Between 2008 and 2019, about 12% of appraisals given were at maturity levels 4 and 5.[19] [20]
The model was originally intended to evaluate the ability of government contractors to perform a software project. It has been used for and may be suited to that purpose, but critics pointed out that process maturity according to the CMM was not necessarily mandatory for successful software development.
The software process framework documented is intended to guide those wishing to assess an organization's or project's consistency with the Key Process Areas. For each maturity level there are five checklist types:
| Type | Description | |
|---|---|---|
| Policy | Describes the policy contents and KPA goals recommended by the Key Process Areas. | |
| Standard | Describes the recommended content of select work products described in the Key Process Areas. | |
| Process | Describes the process information content recommended by the Key Process Areas. These are refined into checklists for:
| |
| Procedure | Describes the recommended content of documented procedures described in the Key Process Areas. | |
| Level overcome | Provides an overview of an entire maturity level. These are further refined into checklists for:
|