Capability maturity model

Origin

Watts S. Humphrey and the Software Engineering Institute, Carnegie Mellon University; Mark Paulk and colleagues (version 1.1), 1986 (framework begun); 1991 (CMM); 1993 (version 1.1)

Level

401 · Expert

Fits

Scale-up, Enterprise

Time to apply

One working session to rate 3 to 5 processes, then a quarter to move one of them up a level

What you need

a list of 3 to 5 repeatable processes, such as campaign launch, weekly reporting and lead handoff · the last 5 to 10 runs of each process, with planned and actual dates and results · one person who owns each process and can change how it runs

The capability maturity model (CMM) is a five-level scale that rates how predictable and controlled an organization’s processes are. The Software Engineering Institute (SEI) at Carnegie Mellon University began the work in November 1986 so the US government could assess its software contractors. Watts Humphrey described the maturity framework in 1988 and in his 1989 book. The SEI published the model in 1991 and released the standard version, 1.1, in 1993.

The idea is older than software. The SEI report says the framework was first inspired by Philip Crosby’s quality management maturity grid in Quality Is Free, adapted to software by Ron Radice and colleagues at IBM under Humphrey, who brought it to the SEI in 1986.

What are the five levels?

The five levels are Initial, Repeatable, Defined, Managed and Optimizing, and each one describes the problem that dominates at that stage. The 1993 report calls them an ordinal scale, meaning a higher level means more maturity, with no claim about the distance between levels.

The CMMI names come from the CMMI Institute, which also lists a level 0, Incomplete.

How does a level change the results?

Higher maturity narrows the gap between planned and actual results. The SEI report names three effects: actual results move closer to targets, the spread around the target shrinks, and the targets themselves improve as rework falls. At level 1, a team that plans ten similar launches for the same date will see them land all over the calendar.

Each level also adds specific practices. The model groups them into 18 key process areas: six at level 2, such as requirements management, project planning and quality assurance, seven at level 3, two at level 4 and three at level 5. To reach a level, the organization has to satisfy every key process area of that level.

Why can’t you skip levels?

The SEI says skipping levels is counterproductive, because each level is the foundation for the next. A level 1 organization that tries to define a standard process before it can plan and track projects is usually unsuccessful, since managers are overwhelmed by schedule and cost pressure. Measurement at level 4 depends on defined processes, because without them there is no common basis for interpreting the numbers.

The report adds a nuance. A level 1 team can still use a higher-level practice, such as peer review, and profit from it. The practice just does not reach its full potential until the foundation exists.

Does the evidence support it?

Partly. In a 1994 SEI study of 13 organizations, Herbsleb and colleagues found a median productivity gain of 35% a year, a median 39% yearly drop in post-release defect reports and a median of 5.0 in value returned per dollar spent. They warn that all participants had good experiences, other factors contributed, and the figures show what is possible in a supportive environment. A 1996 survey by Herbsleb and Goldenson found maturity associated with better performance, with efforts that generally took longer and cost more than expected.

Critics have a case too. James Bach (1994) argued the model reveres process and ignores people, and that organizations chase ratings. In 1991, Bollinger and McGowan published a critical look at the SEI’s capability evaluations, and in 1997 Fayad and Laitinen asked in the Communications of the ACM whether process assessment is wasteful. The SEI itself later published a note arguing that CMMI and Agile methods can be used together.

How do you apply it to marketing operations?

Treat the five levels as a reading order, not a certificate. The SEI wrote version 1.1 around large government contractors and said other organizations must tailor it. The mapping below is our own reading, not an SEI or CMMI product.

Keep two limits in mind. First, rate processes separately, as Hammer’s process audit does for business processes in general. Second, the CMM does not cover people. The SEI published a separate People CMM in 1995 for hiring, training and retention.

The model also differs from the staged scales for data and digital marketing. A data maturity model rates how data is collected and used, and BCG’s digital marketing maturity study rates technology and teams. The CMM rates how predictable the work is. Level 5 describes continuous improvement, the idea behind kaizen and the PDCA cycle; the SEI report itself cites Imai’s work on small evolutionary steps for this logic. Pöppelbuß and Röglinger count hundreds of maturity models since the CMM, and Becker and colleagues note that many are poorly documented, so check what each stage claims.

A Growth Lab plan starts from a rating of the few processes that decide launch speed and report trust.

How to apply Capability maturity model, step by step

1. Pick processes, not departments. A team does not have a maturity level, a process does. List 3 to 5 processes that repeat, such as campaign launch, weekly performance reporting and lead handoff to sales. Result: a short list of named processes, each with an owner.
2. Define the unit of work. The CMM measures projects against their targets. For marketing, name the unit: one campaign, one report, one lead batch. Result: for each process, a clear thing you can count and compare across runs.
3. Rate each process from evidence. Pull the last 5 to 10 runs and compare planned dates and results with actual ones. Wide, unexplained gaps and results that depend on who ran it point to level 1. Written plans that were tracked point to level 2. Result: one level per process, each backed by a run history.
4. Close the level 2 gaps first. The SEI report says skipping levels is counterproductive, because each level is the foundation for the next. Before writing a company-wide standard, make sure every run has a plan, an owner and a tracked outcome. Result: no process with a missing plan or owner.
5. Write the standard once. At level 3 the organization has one documented way of working that each project tailors. For campaigns that means one brief template, one naming convention and one approval path. Result: a single standard that new people are trained on.
6. Measure only where volume allows. Level 4 asks for quantitative limits, which need enough runs to mean anything. Track a few numbers, such as days from brief to launch or tracking errors per launch, only for processes that run weekly or more. Result: a control range for one or two processes, or an honest decision to stay at level 3.
7. Re-rate every six months. Use the same evidence rules and the same people each time. Result: a trend by process, which shows whether the work is moving up or only the documentation is.

Examples

Hughes Aircraft's software division, 1987 to 1990

A public case from the [SEI's 1994 benefits study](https://www.sei.cmu.edu/library/benefits-of-cmm-based-software-process-improvement-initial-results). In 1987 the first SEI-assisted assessment rated the Software Engineering Division of Hughes Aircraft, about 500 professionals, at level 2. A second assessment in 1990 found it a strong level 3. The SEI report puts the cost of the two-year move at 75 person-months plus a $45,000 assessment, and lists the changes: a process group, key training and a comprehensive technical review process.

A dental clinic group's lead handoff

Illustrative, no real clinic implied. Five clinics each hand web enquiries to reception their own way. Over 10 weeks, callback times run from 4 minutes to 3 days, and the fastest results come from one receptionist who leaves in spring. That is level 1: the outcome depends on a person. The first step is level 2, not a new CRM. Each clinic writes down who calls back, within how long, and logs the actual time. Only then does a shared script make sense.

A payments company's promotion review

Illustrative, no real company implied. Every ad and email for a financial product needs a compliance check before it goes live. The marketing team has a checklist, but 3 of the last 12 launches skipped the review when a deadline slipped. The process is written down yet not followed under pressure, which the SEI report describes as the sign that a process is not yet institutionalized. The fix is an owner, a hard gate in the launch tool and a count of skipped reviews, before any talk of optimizing.

When to use it

Use it when work is repeated, results vary a lot between runs or between people, and the team keeps adding tools without the work getting steadier. It gives a shared order of operations: plan and track first, standardize next, measure after that.

When not to use it

Skip it for a small team running a handful of one-off campaigns a year, where there is no repeat to standardize and no volume to measure. Do not use a level as a KPI or a vendor-style certification target. The model is a diagnostic for the work, not a score for the people.

Common mistakes

• Chasing the level. James Bach called this level envy in 1994: organizations aim at the next rating instead of at the problem the rating was meant to reveal.
• Rating the whole department with one number. Lead handoff can be level 1 while weekly reporting is level 3, and the average hides the one that hurts.
• Writing a company-wide standard (level 3) before plans and tracking exist (level 2). The SEI report says such attempts usually fail because managers are overwhelmed by schedule and cost pressure.
• Applying level 4 statistics to a process that runs six times a year. With so few runs, ranges around the average say nothing.
• Treating the process as the only lever. The CMM itself says it does not address how to hire, motivate and retain competent people.

FAQ

What are the five levels of the capability maturity model?

In the SEI's 1993 version they are Initial, Repeatable, Defined, Managed and Optimizing. The SEI summarizes their capability as unpredictable, disciplined, standard and consistent, predictable, and continuously improving. CMMI, the successor, keeps five levels but names level 2 Managed and level 4 Quantitatively Managed.

What is the difference between CMM and CMMI?

CMM is the original software model the SEI published in 1991. CMMI grew out of it, according to the SEI, and now spans domains beyond software. The CMMI Institute, which moved from Carnegie Mellon to ISACA on 1 March 2016, maintains it and added Data Management, People Management and Virtual Work domains in 2023.

Can the capability maturity model be used outside software?

Yes, with care. The SEI wrote the CMM for large government software contractors and said smaller or different organizations must tailor it. Others applied the logic to workforce management, data and business processes. Marketing teams can use the five-step logic, not the 18 software process areas.

Does a higher CMM level improve results?

The evidence is positive but limited. The SEI's 1994 study of 13 organizations found median gains of 35% productivity a year and 5.0 of value per dollar invested, but all had good experiences and the authors call the figures indicators of what is possible. A 1996 survey by Herbsleb and Goldenson found maturity associated with better performance.

Sources

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, Capability Maturity Model for Software, Version 1.1, CMU/SEI-93-TR-024, Software Engineering Institute, 1993
2. Software Engineering Institute, Capability Maturity Model for Software, Version 1.1, library record
3. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis, Charles V. Weber, Capability Maturity Model, Version 1.1, IEEE Software 10(4), 1993
4. Watts S. Humphrey, Characterizing the Software Process: A Maturity Framework, IEEE Software 5(2), 1988
5. Watts S. Humphrey, Managing the Software Process, Addison-Wesley, 1989, Internet Archive record
6. Philip B. Crosby, Quality Is Free: The Art of Making Quality Certain, McGraw-Hill, 1979, Internet Archive record
7. Software Engineering Institute, Transforming Software Quality Assessment (history of the Software CMM and CMMI)
8. James Herbsleb, Anita Carleton, James Rozum, Jane Siegel, David Zubrow, Benefits of CMM-Based Software Process Improvement: Initial Results, CMU/SEI-94-TR-013, 1994
9. James Herbsleb, Dennis Goldenson, A Systematic Survey of CMM Experience and Results, 18th International Conference on Software Engineering, 1996
10. James Bach, The Immaturity of the CMM, American Programmer 7(9), 1994, republished on Satisfice
11. Tom Bollinger, Clement McGowan, A Critical Look at Software Capability Evaluations, IEEE Software 8(4), 1991
12. Mohamed Fayad, Mauri Laitinen, Process Assessment Considered Wasteful, Communications of the ACM 40(11), 1997
13. Frederick P. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Computer 20(4), 1987
14. Bill Curtis, William E. Hefley, Sally Miller, People Capability Maturity Model, CMU/SEI-95-MM-002, 1995
15. Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad, Sandy Shrum, CMMI or Agile: Why Not Embrace Both!, CMU/SEI-2008-TN-003, 2008
16. CMMI Institute, Maturity levels
17. CMMI Institute and ISACA, FAQs on the acquisition, 3 March 2016
18. ISACA, ISACA updates CMMI model with three new domains, April 2023
19. CMMI Institute, CMMI performance solution
20. Michael Hammer, The Process Audit, Harvard Business Review, April 2007
21. BCG, Dominic Field, Shilpa Patel, Henry Leon, Dividends of digital marketing maturity, 2019
22. Jörg Becker, Ralf Knackstedt, Jens Pöppelbuß, Developing Maturity Models for IT Management, Business and Information Systems Engineering 1(3), 2009
23. Jens Pöppelbuß, Maximilian Röglinger, What Makes a Useful Maturity Model?, ECIS 2011

Last updated Oct 9, 2026

Ilia PushinFounder, PUSHERS & COO Fintech ServiceIlia builds operating systems for growing companies in fintech and healthcare. Since 2021 he has run cross-border payments at ARBI Exchange, a licensed currency exchange in Thailand, including KYC and AML and the move into new jurisdictions.About the authorLinkedIn