CMMI: Capability Maturity Model Integration

ISOISO 9001 asks a binary question of an organisation's quality system: does it meet the standard, or not? CMMI asks a different, more graduated question: how good, specifically, is this organisation at doing what it does — and can that be placed on a scale rather than a pass/fail line? It was built by and for software organisations from the outset, which is precisely the gap the previous page identified in ISO 9001's manufacturing origins, and it remains the standard reference point in defence contracting and large enterprise software specifically.

From CMM to CMMI

TheThe model's origin is unusually well-documented and personal. Watts Humphrey joined the Software Engineering Institute (SEI) at Carnegie Mellon University in 1986, after retiring from IBM, at the request of the U.S. Air Force, which needed a way to evaluate the process capability of software contractors as part of awarding defence contracts¹. Humphrey formalised his existing "Process Maturity Framework" into what became the Capability Maturity Model for Software (SW-CMM), first published by the SEI in August 1991, with a fuller Version 1.1 released in January 1993². The model was later broadened beyond pure software process and consolidated with related maturity models into CMMI (Capability Maturity Model Integration), still maintained today, now administered by ISACA following its acquisition of the CMMI Institute in 2016³.

The Five Maturity Levels

Level	Name	What characterises it
1	Initial	Process is unpredictable, poorly controlled, and reactive. Success depends on individual heroics, not the organisation's own process — the same failure mode as an ad-hoc team with no repeatable practice at all.
2	Managed	Projects are planned, performed, measured, and controlled at the project level, but practice can still vary significantly between projects within the same organisation.
3	Defined	Process is characterised and understood well enough to be documented as a standard organisational process, and individual projects tailor it rather than each inventing their own from scratch.
4	Quantitatively Managed	Process performance is controlled using genuine statistical and quantitative techniques — the organisation measures its own process with numbers, not impressions, and can predict outcomes from those numbers.
5	Optimizing	Process improvement is itself continuous and data-driven, based on a quantitative understanding of the common causes of variation inherent in the process — the organisation is actively, measurably getting better at getting better.

TheThe jump worth understanding precisely is Level 2 to Level 3: at Level 2, good practice can exist but lives at the level of individual projects or teams — one team is disciplined, another isn't, and the organisation as a whole can't say what "how we do software here" actually means. Level 3 is where that practice becomes genuinely organisational, documented and shared rather than personal and local.

CMMI Against ISO 9001: A Different Kind of Standard Entirely

It'sIt's worth being precise about what kind of comparison this actually is, because CMMI and ISO 9001 are frequently discussed as if they were direct competitors offering the same thing, when they're structurally different tools⁴:

• ISO 9001 is binary. An organisation is certified or it isn't; there's no "certified at level 3 out of 5."
• CMMI is graduated by design. An organisation is appraised at a specific maturity level, and the entire point is that Level 2 and Level 5 are both real, meaningfully different, non-failing states — the model is built around the idea that maturity is a journey, not a threshold.
• ISO 9001 is generic across industries — the same standard, in principle, certifies a car-parts manufacturer and a software house (via ISO/IEC/IEEE 90003's translation layer). CMMI was software-and-systems-native from its very first version, with no manufacturing translation required.
• Who uses which tends to track context, not universal superiority: government and defence contractors — the model's original constituency — still lean heavily on CMMI appraisals as part of contractor selection; ISO 9001 remains the more globally recognised, cross-industry certification a customer outside the software world is more likely to actually recognise.

In practice the two aren't mutually exclusive — an organisation can hold ISO 9001 certification and separately pursue a CMMI maturity appraisal, and many large contractors do both, since they answer genuinely different questions (does our documented system meet a baseline requirement, versus how mature is our actual process) rather than competing for the same claim.

See Also

ForFor the ISO family standards CMMI is most often discussed alongside, see Quality Management Systems and ISO/IEC/IEEE 90003 and ISO/IEC 12207. For the process-versus-product distinction CMMI's own maturity levels are built around, see Process Over Product, and for the same idea applied to individual project learning rather than organisational maturity, see Estimating Effort and Time, and Why Retrospectives Make It Better. For CMMI's levels applied not to a project or an organisation but to a single person's own study practice — with real precedent from CMMI's own creator, who did exactly this move for individual software engineers — see Personal Learning Maturity, and for how that maps onto the QAA's own formal description of a Bachelor's degree, see What a Bachelor's Degree Is Actually For.

References