The Capability Maturity Model: Where Maturity Models Came From

If you have ever filled in a maturity assessment, you have used an idea that is now around forty years old. The Capability Maturity Model, usually shortened to CMM, gave the world the language of "levels" that most maturity models still use. It was built for one specific problem, software projects that failed far too often, but its core insight turned out to apply almost everywhere.

This article is a short history of the Capability Maturity Model, what it got right, where it is often misused, and what that means if you are assessing your own organisation today.

The problem it was built to solve

In the 1980s, software was becoming critical to defence, government and business, and large software projects had a poor reputation. They were often late, over budget and unreliable. The United States Department of Defense, one of the biggest buyers of software in the world, needed a better way to judge which contractors could actually deliver.

The work was taken up by the Software Engineering Institute (SEI) at Carnegie Mellon University. Watts Humphrey, who had led software development at IBM, became the central figure. His book Managing the Software Process, published in 1989, set out the thinking that would become the model.

The insight was simple and powerful: the quality of software depends heavily on the maturity of the process used to build it. Talented individuals could rescue a project, but organisations that relied on heroics could not deliver consistently. What mattered was whether good practice was defined, repeated and improved, regardless of who happened to be on the team.

Ideas that came before

The CMM did not appear from nowhere. Two earlier ideas influenced it:

• Philip Crosby's quality management maturity grid, described in his 1979 book Quality Is Free, showed how an organisation's attitude to quality develops through five stages, from uncertainty to certainty.
• Richard Nolan's stages of growth, from the 1970s, described how organisations' use of computing evolves over time.

Both shared the idea that capability develops in recognisable stages, and that knowing your stage tells you what to work on next.

The five levels

The first version of the Capability Maturity Model for software was published by the SEI in 1991. It described five maturity levels, each with a short name:

1. Initial: success depends on individual effort, and processes are ad hoc.
2. Repeatable: basic project management is in place, so earlier successes can be repeated on similar projects.
3. Defined: processes are documented and standardised across the organisation.
4. Managed: processes and products are measured and controlled quantitatively.
5. Optimizing: the organisation continuously improves its processes based on measurement and new ideas.

Each level was supported by a set of "key process areas", practices an organisation needed in place to claim that level. Organisations were appraised against the model, and contractors began advertising their level as a mark of credibility.

From CMM to CMMI

During the 1990s, the SEI and others created variants for systems engineering, software acquisition and people management. Having several overlapping models became confusing, so they were combined into Capability Maturity Model Integration, known as CMMI, in the early 2000s.

CMMI has been revised several times since. Responsibility moved from the SEI to the CMMI Institute, which became part of ISACA in 2016, and the model is still used for formal appraisals, particularly by organisations that sell to governments and large enterprises.

What it got right

The CMM's lasting contribution is not its five specific levels. It is a way of thinking that applies to almost any capability:

• Process over heroics. If results depend on a few exceptional people, they are fragile. Maturity means good outcomes are repeatable.
• Improvement is cumulative. You cannot skip from chaos to optimisation. Measurement is meaningless until a process is defined; defining a process is pointless until basic discipline exists.
• Knowing your level tells you your next step. A maturity model is a map, and its value is in pointing to the next sensible move rather than describing perfection.

These ideas are why maturity models have spread into change management, cybersecurity, data, customer experience and dozens of other areas.

Where it is often misused

The same history also shows the traps.

Levels as badges

When a maturity level becomes a requirement for winning contracts, organisations are tempted to chase the badge rather than the capability. Documents get written to satisfy appraisers, not to help teams. The lesson: an assessment is only useful if people are honest, and people are only honest when the score is not used against them.

Too many levels to tell apart

Five levels work well for a formal appraisal with trained assessors. In a self-assessment, people often struggle to distinguish adjacent levels, and many answers cluster in the middle. This is one reason the models on this site use three clearly different levels; our methodology explains the reasoning.

Process for its own sake

Higher maturity does not mean more paperwork. A well-run team that delivers reliably with lightweight practices can be more mature than one with thick process manuals that nobody follows. Good maturity models describe outcomes and observable behaviour, not the volume of documentation.

What this means for your assessment

If you are running a maturity assessment today, in software or anywhere else, the CMM's history suggests a few rules:

1. Assess what actually happens, not what the policy says. The gap between the two is usually where the improvement lies.
2. Use the result to choose the next step, not to rank teams. As soon as scores become targets, they stop telling the truth.
3. Expect progress to be gradual. Moving up a level in a meaningful way often takes a year or more.
4. Focus on repeatability. Ask, "Would this still work if our best people were on holiday?"

For software teams specifically, the Software Development assessment looks at how code is planned, built, reviewed, tested and released. For organisations whose challenge is delivery more broadly, the Project & Programme Management assessment covers how work is selected, governed and delivered.

Frequently asked questions

Is CMMI the same as a maturity model?

CMMI is one specific, formal maturity model with defined practices and an official appraisal method. "Maturity model" is the general idea, a set of stages describing how a capability develops, which many other models also use.

Do I need CMMI certification?

Only if your customers require it, which is most common in government and defence contracting. For internal improvement, a simpler self-assessment usually gives you most of the insight for a fraction of the effort.

Why do so many maturity models have five levels?

Largely because of the CMM's influence. Five levels became the default pattern, even in fields where fewer, more clearly separated levels would be easier to use.