CMMI - Capability Maturity Model Integration (Chrissis et al., 2005)

Theory Publication Information

Citation Information

Why Was the Model Created?

During the 1980s and 1990s, organizations struggled with software development and system engineering quality and consistency. Different organizations used different terminology and approaches for capability and maturity assessment. The Software Engineering Institute (SEI) at Carnegie Mellon University developed the original Capability Maturity Model (CMM) for software in 1991 and subsequently created additional models for other domains. However, by early 2000s, multiple separate CMM models existed (CMM-SW for software, SE-CMM for systems engineering, IPD-CMM for integrated product development). This model fragmentation created confusion and implementation challenges for organizations operating across multiple domains.

CMMI (Capability Maturity Model Integration) was created to integrate multiple existing CMM models into unified, coherent framework. CMMI Version 1.1 was released by SEI in 2002, with the influential textbook by Chrissis, Konrad, and Shrum published in 2005 providing comprehensive guidance. CMMI provided single framework applicable to software development, systems engineering, integrated product development, and services. CMMI enabled organizations to adopt single maturity model across multiple domains rather than managing multiple fragmented models.

CMMI became foundational to IT process improvement globally. The framework provided repeatable, structured approach to process capability assessment and improvement. CMMI enabled organizations to identify process capability gaps, prioritize improvement initiatives, and systematically increase organizational maturity. CMMI now stewarded by ISACA following CMMI Institute acquisition. The framework remains central to IT governance, quality management, and capability assessment practices worldwide.

Core Concepts and Definitions

CMMI centers on several core concepts:

• Capability: The range of expected results that can be achieved by following a process. Process capability characterizes ability to produce expected outputs consistently.
• Maturity: The extent to which an organization has explicitly and consistently deployed formally planned and controlled processes. Maturity reflects organizational consistency and process discipline.
• Process Area: A cluster of related practices that, when implemented collectively, satisfy a set of goals. Process areas organize practices into logical, implementable units addressing specific organizational concerns.
• Maturity Level: A defined evolutionary plateau representing increased organizational capability. Maturity levels provide roadmap for process improvement progression.
• Staged Representation: CMMI model organized into maturity levels. Staged approach provides sequential, evolutionary improvement path.
• Continuous Representation: CMMI model organized by capability levels per process area. Continuous approach enables process-area-specific improvement.
• Practice: Activities and methods recognized as contributing to achievement of goals in a process area. Practices provide actionable guidance for improvement.

What Does the Model Measure?

CMMI is a maturity model rather than a psychometric scale. It assesses organizational process capability and maturity at the process-area and organization level, not individual-level attitudes or perceptions. Core assessment concepts include:

• Capability level (continuous representation): For each process area, one of six levels: Incomplete (Level 0), Performed (Level 1), Managed (Level 2), Defined (Level 3), Quantitatively Managed (Level 4), and Optimizing (Level 5).
• Maturity level (staged representation): An overall organizational maturity rating (Levels 1 through 5: Initial, Managed, Defined, Quantitatively Managed, Optimizing) based on achievement of specified process areas.
• Specific and generic goals:Whether a given process area’s specific goals and the generic goals for institutionalization have been met.
• Specific and generic practices: Presence or absence of prescribed practices supporting each goal.

Formal appraisals (under SCAMPI-A, and more recently CMMI’s Benchmark / Evaluation / Sustainment appraisal types) assess these through document review, interviews, and evidence sampling. CMMI does not publish psychometric reliability or validity coefficients in the way measurement theories do.

Source note:Claims below are drawn from the Chrissis, Konrad, and Shrum textbook (CMMI-SE/SW/IPPD/SS v1.1 edition), the CMMI v1.1 and subsequent model documents published by SEI/CMMI Institute/ISACA, and commonly cited secondary treatments. The structural elements verified against the book’s Table of Contents include the four process area categories, the 25 process areas, capability levels 0-5, maturity levels 1-5, and generic goals GG 1-5. Historical claims about precursor CMMs and successor constellations, together with the year-to-year evolution narrative, are drawn from secondary sources rather than direct body-text verification.

Preceding Models or Theories

CMMI built upon and integrated several prior approaches. The specific preceding models listed below (CMM, SECM, CMM-SW, SE-CMM, IPD-CMM, P-CMM, TQM, ISO 9000) are drawn from secondary sources rather than the Chrissis et al. TOC itself; TOC-limited, full book unavailable:

• Capability Maturity Model (CMM), SEI (1991): Original SEI model for software engineering maturity. CMM established maturity level concept and process-based improvement approach.
• Systems Engineering Capability Model (SECM, 1992): SEI model for systems engineering maturity. SECM provided systems engineering perspective on capability and maturity.
• Software Engineering CMM (CMM-SW, 1993): Enhanced software CMM. CMM-SW became widely adopted in software industry.
• Systems Engineering CMM (SE-CMM, 1997): Comprehensive systems engineering maturity model. SE-CMM incorporated advanced systems engineering concepts.
• Integrated Product Development CMM (IPD-CMM, 1997): CMM for integrated product development. IPD-CMM addressed cross-functional team and product integration concerns.
• People CMM (P-CMM, 1995): CMM for workforce capability. P-CMM addressed human resource management and workforce maturity.
• Total Quality Management (TQM, 1980s-1990s): Quality management discipline providing foundation for continuous process improvement philosophy.
• ISO 9000 Quality Standards: International quality standards. CMMI incorporated quality management concepts from ISO standards.

Describe The Model

CMMI provides unified maturity assessment model integrating multiple process improvement domains through maturity levels and process areas describing practices and goals for organizational process improvement across software development, systems engineering, and services.

CMMI Staged Representation - Five Maturity Levels

• Level 1: Initial: Processes unpredictable, poorly controlled, reactive. Success depends on individual efforts rather than established processes. Organization lacks repeatable processes.
• Level 2: Managed: Requirements managed, processes planned and executed, work products monitored and controlled. Some processes institutionalized but discipline variable across organization.
• Level 3: Defined: Standard processes documented and communicated, processes tailored from organizational standards, integration across functional groups. Processes are proactive with preventive mechanisms.
• Level 4: Quantitatively Managed: Processes measured and controlled, quantitative objectives for quality and performance established. Statistical techniques used to manage processes.
• Level 5: Optimizing: Organization focuses on continuous process improvement and innovation. Processes enable rapid adaptation to changing circumstances.

CMMI Process Areas

The CMMI-SE/SW/IPPD/SS v1.1 edition documented by Chrissis, Konrad, and Shrum organizes 25 process areas into four categories. For Process Management, Project Management, and Support, the book further groups process areas as "Fundamental" or "Progressive" to indicate prerequisite relationships among them. For Engineering, the book discusses process areas under "Engineering Process Areas and Recursion" rather than a Fundamental/Progressive split.

• Process Management: Organizational-level process areas addressing the infrastructure needed to sustain process improvement across the enterprise.
• Project Management: Process areas for planning, monitoring, and controlling projects, including integrated product teams and supplier arrangements where applicable.
• Engineering: Process areas for the technical work of developing and delivering products, spanning requirements, technical solution, product integration, verification, and validation.
• Support: Cross-cutting process areas providing infrastructure and analytical capabilities that support all other process areas.

The 25 process areas in this edition span software engineering, systems engineering, integrated product and process development (IPPD), and supplier sourcing disciplines. Selected process areas are active only when particular disciplines are in scope for an appraisal.

CMMI Continuous Representation - Capability Levels

Continuous representation enables organization to target specific process areas for improvement:

• Level 0: Incomplete: Process area either not performed or only partially performed. Organization lacks implementation of process.
• Level 1: Performed: Process area requirements satisfied. Process produces required results but organization lacks formal process documentation and discipline.
• Level 2: Managed: Process area managed at project level. Requirements managed, processes planned and executed, results monitored.
• Level 3: Defined: Standard process defined and tailored from organizational standards. Process integrated with other processes.
• Level 4: Quantitatively Managed: Process area managed quantitatively with statistical process control. Performance targets established and managed.
• Level 5: Optimizing: Process area optimized for continuous improvement. Innovation and process optimization institutionalized.

CMMI Constellations

• CMMI for Development (CMMI-DEV): Addresses software development, systems engineering, and product development. Primary constellation for technology organizations.
• CMMI for Acquisition (CMMI-ACQ): Addresses management of acquisition processes for outsourced development and services. Enables buyer-side capability assessment.
• CMMI for Services (CMMI-SVC): Addresses management and delivery of services. Enables service organizations to assess and improve capability.

Main Strengths

• Unified framework: CMMI integrates multiple models into single unified framework. Integration reduces model fragmentation and enables comprehensive capability assessment.
• Comprehensive coverage: CMMI addresses software development, systems engineering, acquisition, and services. Broad applicability across technology domains.
• Practical maturity levels: Five maturity levels provide clear evolution path for organizational improvement. Levels provide measurable progression framework.
• Process area organization: Process areas organize practices into logical, implementable units. Organization enables focused improvement efforts.
• Dual representations: Staged and continuous representations enable different improvement strategies. Flexibility accommodates organizational preferences.
• Industry adoption: CMMI widely adopted in software and systems engineering industries. Adoption demonstrates practical value and effectiveness.
• Proven effectiveness: Organizations using CMMI report improved quality, schedule adherence, and cost predictability. Framework delivers measurable business benefits.

Main Weaknesses

• Complexity and documentation burden: CMMI requires extensive process documentation and measurement infrastructure. Documentation burden increases implementation time and cost.
• Assessment cost and expertise requirement: CMMI formal assessments expensive and require experienced assessors. Assessment cost creates barriers for smaller organizations.
• Heavyweight methodology perception: CMMI perceived as heavyweight process framework. Perception creates resistance in agile and lean organizations.
• Small organization applicability: CMMI implementation challenging for small organizations lacking process infrastructure. Framework assumes organizational scale.
• Agile method tension: CMMI structured, plan-driven approach conflicts with agile methods. Integration with agile practices remains challenging.
• Technology evolution pacing: Technology changes faster than CMMI guidance can be updated. Model guidance may become outdated relative to technology advances.
• Focus on process vs. outcomes: CMMI focus on process maturity may not guarantee superior business outcomes. Process maturity does not automatically translate to business success.

Key Contributions

• Unified multiple capability models: CMMI integrated CMM-SW, SE-CMM, IPD-CMM, and other models. Integration eliminated model fragmentation and enabled single organizational framework.
• Extended maturity-based improvement approach: CMMI maturity levels became industry standard for process improvement. Maturity concept influenced IT governance and process management globally.
• Provided comprehensive process guidance: CMMI provided detailed process area descriptions and practice guidance. Guidance enabled organizations to understand and implement process improvements.
• Enabled quantitative process management: CMMI provided foundation for statistical process control and quantitative management. Quantitative approach improved process visibility and control.
• Created assessment and certification industry: CMMI assessment programs created professional assessment community. Assessment industry enabled independent capability verification.
• Reported process-improvement benefits: Published CMMI implementation reports, many authored by SEI-affiliated practitioners or client organizations, describe quality and productivity improvements. Independent, peer-reviewed evaluations are limited and results vary substantially across studies.
• Influenced government procurement requirements: US government acquisition organizations adopted CMMI requirements. Government adoption drove industry adoption of CMMI.
• Provided foundation for IT governance frameworks: CMMI concepts incorporated into COBIT, ITIL, and other IT governance frameworks. CMMI principles became foundational to IT governance discipline.

Internal Validity

CMMI is a prescriptive maturity model rather than an empirical theory, so it is not subject to construct-validity testing in a psychometric sense. Considerations typically raised about its internal consistency include:

• Logical maturity progression: The argument that maturity levels represent increasing organizational capability is logically sound. Progression from ad-hoc to optimized reflects increasing process discipline.
• Comprehensive process coverage: CMMI comprehensively addresses multiple process domains. Comprehensive coverage addresses diverse organizational concerns.
• Empirically grounded: CMMI developed from analysis of high-performing organizations and research on software engineering practices. Empirical grounding provides credibility.
• Consistent with quality principles: CMMI reflects established quality management principles and continuous improvement philosophy. Consistency with proven approaches improves validity.
• Self-reported organizational benefits: Organizations reaching higher maturity levels commonly report improved quality, productivity, and predictability. These reports are largely self-reported or SEI-adjacent; the causal contribution of CMMI itself (versus other concurrent process changes) is difficult to isolate.
• Integrated across domains: Unified framework integrating multiple domains provides coherent organizational perspective. Integration enables comprehensive capability assessment.

External Validity

External validity considerations concern generalizability of CMMI across diverse organizational contexts:

• Broad industry adoption: CMMI adopted across software, systems engineering, aerospace, defense, and other industries. Adoption across industries demonstrates applicability.
• Large organization success: CMMI successfully implemented in large organizations. Framework proves effective at enterprise scale.
• Small organization challenges: CMMI implementation challenging for small organizations lacking resources. Scalability to small organizations limited.
• Cultural variation: CMMI adopted in organizations across different national cultures and business cultures. Cultural adaptability demonstrated.
• Agile method integration challenges: Organizations adopting agile methods report difficulty integrating CMMI. Integration with agile practices remains challenging.
• Services sector applicability: CMMI for Services constellation extended framework to services. Services sector applicability demonstrated but requires specialization.
• Startup and rapid innovation contexts: CMMI implementation challenges in startup environments and rapidly innovating organizations. Framework assumes stable organizational context.
• Government procurement emphasis: CMMI driven by government procurement requirements. Over-emphasis on government procurement may limit commercial market adoption.

Relevance to Technology Adoption

CMMI addresses technology adoption by establishing that technology decisions should support organizational process improvement and capability development. CMMI requires organizations to assess technology against organizational process maturity needs, evaluate technologies against process area requirements, and adopt technologies enabling process improvement. This enables process-aligned technology adoption that strengthens organizational capability rather than ad-hoc technology acquisitions.

Barriers to Process-Aligned Technology Adoption Identified

• Lack of process maturity: Organizations without mature processes struggle to adopt technologies effectively. Immature organizations lack foundation for technology utilization.
• Technology-first focus: Organizations emphasize technology solutions without understanding process implications. Technology focus without process context leads to failed implementations.
• Inadequate change management: Technology adoption without change management support fails to achieve benefits. Change management gaps reduce adoption success.
• Skill gaps: Workforce may lack skills to effectively use adopted technologies. Skill gaps prevent technology value realization.
• Process resistance: Existing processes may resist change induced by new technologies. Process-technology misalignment creates organizational friction.
• Cost and resource constraints: Process improvement and technology adoption require sustained investment. Resource constraints limit improvement initiatives.
• Measurement and metrics inadequacy: Organizations unable to measure technology impact on process performance. Measurement gaps prevent assessment of technology value.

Leadership Actions the Framework Prescribes

• Assess current process maturity: Conduct CMMI-based assessment to understand current organizational maturity. Assessment establishes baseline for improvement.
• Establish process improvement strategy: Develop strategy for process maturity progression aligned with business objectives. Strategy guides technology adoption decisions.
• Define process standards: Develop organizational process standards and process improvement strategy. Standards enable consistent process implementation.
• Align technology adoption with process needs: Evaluate technologies against process improvement requirements. Process alignment ensures technology supports organizational goals.
• Plan change management: Develop comprehensive change management supporting technology adoption and process change. Change management increases adoption success.
• Develop workforce capability: Provide training and capability development supporting process improvement and technology adoption. Workforce development enables effective technology utilization.
• Establish measurement infrastructure: Implement metrics and measurement systems enabling process performance monitoring. Measurement enables data-driven improvement.
• Monitor and continuously improve: Track technology implementation outcomes against process improvement objectives. Continuous monitoring enables process refinement.

Following Models or Theories

CMMI has evolved through multiple versions and is commonly discussed alongside related process-improvement frameworks. The specific successor constellations (CMMI-DEV, CMMI-ACQ, CMMI-SVC) and adjacent frameworks (COBIT, ITIL, ISO/IEC 15504, Lean, Agile, DevOps) listed below are drawn from secondary sources rather than the Chrissis et al. TOC itself; TOC-limited, full book unavailable:

• CMMI Evolution (2002-present): CMMI evolved from version 1.1 (2002) through 1.3 (2010) with ongoing updates and enhancements. Evolution reflects growing maturity of model and incorporation of lessons learned.
• COBIT (Control Objectives for Information and Related Technology): IT governance framework incorporating CMMI maturity concepts. COBIT applies maturity framework to IT governance and control.
• ITIL (Information Technology Infrastructure Library): IT service management framework. ITIL incorporates continuous improvement philosophy and process maturity concepts.
• ISO/IEC 15504 (Software Process Assessment): International standard for software process assessment based on CMMI concepts. Standard provides international process assessment framework.
• Lean Software Development:Lean manufacturing principles applied to software development. Lean approach provides alternative to CMMI’s heavy-weight process focus.
• Agile Process Improvement: Integration of CMMI concepts with agile development methods. Agile approach provides lightweight process improvement.
• DevOps and Continuous Improvement: DevOps practices incorporating CMMI process improvement principles. DevOps enables continuous delivery with process discipline.

References

1. Chrissis, M. B., Konrad, M. D., & Shrum, S. (2005). CMMI: Guidelines for process integration and product improvement. Addison-Wesley Professional.

Further Reading

1. Software Engineering Institute. (2010). CMMI for development, version 1.3. Carnegie Mellon University.
2. Paulk, M. C., Curtis, B., Chrissis, M. B., & Weber, C. V. (1993). Capability Maturity Model for software, version 1.1. Software Engineering Institute Technical Report CMU/SEI-93-TR-024.
3. Paulk, M. C., Weber, C. V., Garcia, S. M., Chrissis, M. B., & Bush, M. (1995). Key practices of the Capability Maturity Model, version 1.1. Software Engineering Institute Technical Report CMU/SEI-93-TR-025.
4. Humphrey, W. S. (1989). Managing the software process. Addison-Wesley.
5. Forrester, E., Buteau, B., & Shrum, S. (2007). CMMI and six sigma. Addison-Wesley Professional.
6. Software Engineering Institute. (2010). CMMI for services, version 1.3. Carnegie Mellon University.
7. Higuera, R. P., & Hamill, L. Y. (1992). Software process improvement at Hughes Aircraft. IEEE Software, 9(4), 18-23.
8. Florac, W. A., Carleton, A. D., & Barnard, J. R. (2000). Statistical process control: Why, when, how. CrossTalk, 13(5), 2-8.
9. Bamford, R. C., & Deibler, W. J. (1993). Road to quality. IEEE Software, 10(6), 75-79.
10. Chrissis, M. B., Konrad, M., & Shrum, S. (2010). CMMI for Development, 3rd Edition (v1.3).

Series Navigation