CMMI — Capability Maturity Model Integration

[js] [/js]

Benefits in Using CMMI

Capability Maturity Model Integration (CMMI) is a product suite developed and maintained by the Software Engineering Institute (SEI) at Carnegie Mellon Univ. to improve the organisational process maturity in the fields of product development, acquisition, and service delivering. CMMI is a process improvement approach that provides organisations with the essential elements for effective process improvement in software engineering, organisational change, and organisational development. The model defines what processes and activities need to be done and not how these processes and activities are done.

The goal of CMMI is process improvement and CMMI can be thought of as a software process improvement framework. It can be used to guide process improvement across a project, a division, or an entire organisation.
CMMI helps to integrate traditionally separate organisational functions, to set process improvement goals and priorities, to provide guidance for quality processes, and to provide a point of reference for appraising current processes.

The CMMI product suite can provide verification that processes are established, maintained, and implemented consistent with state-of-the-art understanding as to what constitutes "world class performance. However, CMMI will not provide validation that an organisation has the correct product for the customers or market or that a product itself is profitable. Use of the CMMI should therefore be undertaken only in conjunction with a complete understanding of the business goals and objectives, the market and customer base, and the overall product strategy.

The CMMI framework is based on proven practices collected from various organisation and fields of application. It is applicable for any organisation. By implementing CMMI, organisations can be assured of improved processes which give benefits like:

• improved schedule and budget predictability
• improved cycle time
• increased productivity
• improved quality (as measured by defects)
• increased customer satisfaction
• improved employee morale
• increased return on investment
• decreased costs of quality

CMMI is being used worldwide for internal process improvement, as a high-value discriminator in supplier selection, and for monitoring on-going product development operations. Its development and use is founded upon two premises:

• the quality of a product is closely related to the quality of the processes used to perform, manage and support its development throughout product definition, design, construction, and testing.
• improving product quality during the development stages reduces rework, costs and time to market. Adoption of the CMMI represents an organisation's commitment to achieving competitive business goals in the world market. Attaining a formal maturity or capability rating by appraisal provides a company with visible demonstration of its commitment to exceeding its customer's expectations.

The CMMI product suite can provide verification that processes are established, maintained, and implemented consistent with state-of-the-art understanding as to what constitutes "world class performance. However, CMMI will not provide validation that an organisation has the correct product for the customers or market or that a product itself is profitable. Use of the CMMI should therefore be undertaken only in conjunction with a complete understanding of the business goals and objectives, the market and customer base, and the overall product strategy.

Evolution of CMMI

The Capability Maturity Model Integration (CMMI) is based on four pillars:

• Capability — a capable process consistently produces output that is within its specifications. Execution of capable process always gives predictable results. — For more information see my post on Process Capability.
• Maturity — maturity means that whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and performs accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation. — For more information see my post on Process Maturity.
• Model — a model is a framework or way of doing something. CMMI only provides a framework to define processes at your organisation and it does not give exact process details. It only guides to implement efficient and effective processes.
• Integration — from a historical point of view CMMI was a fusion of proven practices from a number of different Software and System Development capability maturity models.

CMMI in its current state is an evolution of the SEI's Capability Maturity Model for Software (SW-CMM), the Electronic Industries Alliance Interim Standard EIA/IS 731 model for systems engineering, and the Integrated Product Development Capability Maturity Model (IPD-CMM). SEI had sunset the legacy SW-CMM, and both the CBA IPI and SCE appraisal methods, by December 31, 2005 and thereafter support only the CMMI product suite by now. Historically, in the mid 1980's the US Dept. of Defense needed a way to determine whether their contractors could provide software on time, within budget and to specifications.

SEI at Carnegie Mellon Univ. presented the solution: Capability Maturity Model (CMM) was a way to assess and describe the quality of an organisation's software development. In August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI, Systems Engineering Capability Maturity Model (SE-CMM) was developed and published. The International Council on Systems Engineering (INCOSE) developed and published the so-called Systems Engineering Capability Assessment Model (SECAM). Other CMMs were additionally developed, including: the Software Acquisition CMM, the People CMM, and the Integrated Product Development CMM. Some business domains also produced their own CMMs. For example, the Electronic Industries Alliance (EIA) published in concert with other partners the so-called Systems Engineering Capability Model (SECM) which was termed later EIA/IS-731. At the long run, several issues arose from these models:

• all of the systems engineering models shared similar principles.
• the content of SW-CMM and the system engineering models overlapped
• the systems engineering models were based on a different representation than the SW-CMM and similar to that of ISO/IEC 15504. — These models employed a continuous representation, whereas SW-CMM employed a staged representation (see below).

 

 

CMMI v1.0

CMMI v1.0 was in 2000 the sunrise of integrating the several existing CMM models to one integrated model. CMMI v1.0 included a common set of process areas forming the core of an integrated capability model which integrated process improvement guidance for systems engineering, software engineering, and Integrated Product and Process Development (IPPD). The foundation for the CMMI product suite was laid. The CMMI product suite provided an integrated approach to reduce the redundancy and complexity resulting from the use of separate, multiple capability maturity models (CMMs).

CMMI v1.1

For further model integration, the SEI steering committee formulated more requirements for a Capability Maturity Model-Integrated (CMMI) product suite. The suite should include a framework for generating CMMI products. The generated products should be based on CMMI models for specified disciplines and discipline combinations, training products, assessment materials, glossary terms, and tailoring requirements. The disciplines initially specified include Systems Engineering, Software Engineering, and Integrated Product and Process Development.

CMMI v1.2

CMMI for Development (CMMI-DEV) v.1.2 is an upgrade of CMM v.1.1. The focus of the CMMI v.1.2 effort is on improving the quality of CMMI products and the consistency of how they are applied. Version 1.2 includes the concept of CMMI so-called constellations: these are sets of CMMI components designed to meet the needs of specific areas of business interest.

CMMI v1.3

CMMI High Maturity Lead Appraisers and the CMMI Steering Group at the SEI reviewed subsequently the notion of constellation models v.1.2 at a workshop in late September 2008. As a result, the Steering Group determined that modernising the practices for maturity levels 4 and 5 was a priority. The CMMI Steering Committee targeted CMMI v.1.3 to focus on:

• High maturity
• More effective General Practices
• Appraisal efficiency
• Commonality across the constellations
• All changes to the CMMI product suite (see below) have to meet certain primary criteria.

For more information see my post on CMMI 1.3 — Changes.

CMMI Product Suite

Since CMMI v1.3 the CMMI product suite addresses by the notion "constellations" process areas of different business interest, e.g. it covers the domains of product development (CMMI-DEV), service development (CMMI-SVC), and acquisition (CMMI-ACQ).

The CMMI product suite includes a framework for generating CMMI products, and a set of CMMI products produced by the framework. The framework includes common elements and best features of the existing models as well as rules and methods for generating CMMI products. Users may select discipline specific elements of the CMMI product suite based on their business objectives and mission needs.

The CMMI product suite consists of:

• Framework
• Capability Maturity Model Integration Models
• Training Products
• Assessment/Appraisal Products
• Glossary

CMMI Constellations and Models

Since version 1.2, CMMI includes the concept of constellations. A CMMI constellation is a particular collection of process areas specifically chosen to help improve a given business need within the CMMI framework. It is a set of CMMI components designed to meet the needs of a specific area of interest. With v1.2 three major areas of interest were focused: ((The People CMM (PCMM), which addresses managing and developing organisational workforces, stands apart from CMMI product suite v1.3.))

• Product and service development
• Acquisition
• Services

CMMI constellations give a common approach to implement many Project Management, Organisational Process Management and Supporting process areas of work in an organisation. A constellation can produce one or more related CMMI models — i.e. the published proven practices and related appraisal and training materials. There are now (v.1.3) three areas of business interest covered by related CMMI models: Development, Acquisition, and Services:

• CMMI for Development (CMMI-DEV) addresses product and service development processes.
• CMMI for Acquisition (CMMI-ACQ) addresses supply chain management, acquisition, and outsourcing processes in government and industry.
• CMMI for Services (CMMI-SVC) addresses guidance for delivering services within an organisation and to external customers.

These models/constellations were released as CMMI v. 1.3 in November 2010.

 

 

CMMI models provide guidance to use in developing processes. CMMI models are not themselves processes or process descriptions — the actual processes used in an organisation depend on many factors, including application domain(s) and organisation structure and size. Rather, CMMI contains and is produced from a framework, the CMMI Model Foundation (CMF). The CMF provides the ability to generate multiple models and associated training and appraisal materials. These models may reflect content from different bodies of knowledge (e.g., systems engineering, software engineering, integrated product and process development, ITIL, CobIT, etc.).

CMMI Process Areas

Process vs. Process Area

It's an important distinction to understand between processes and process areas (PAs).
An individual process is realisied by distinctive work instructions specifiying how a prescribed work product is achieved.
Instead a process area specifies goals and proven practices for performing professional work without specifiying how to do this. More, the resulting work product is specified by its characteristics only.

All CMMI v1.3 models define a set of Process Areas (e.g. Project Planning PP or Configuration Management CM).
The process area specifies goals and proven practices for performing professional work (e.g. one goal of PP is "establish estimates" with the proven practice "project scope estimation").

 

Process Areas, Categories and Maturity Levels of CMMI v1.3 models

Process Area (engl.)	Process Area (dt.) ((German CMMI-DEV translations in referral to German Lead Appraiser and Instructor Board))	Category	Maturity Level	CMMI model
AM - Agreement Management	Vereinbarungsmanagement	Acquisition	2	ACQ
ARD - Acquisition Requirements Development	Entwicklung der Beschaffungsanforderungen	Acquisition	2	ACQ
ATM - Acquisition Technical Management	Technisches Beschaffungsmanagement	Acquisition	3	ACQ
AVAL - Acquisition Validation	Validierung der Beschaffungen	Acquisition	3	ACQ
AVER - Acquisition Verification	Verifikation der Beschaffungen	Acquisition	3	ACQ
CAM - Capacity and Availability Management	Servicekapazitäts- und verfügbarkeitsmanagement	Service Establishment and Delivery	3	SVC
CAR - Causal Analysis and Resolution	Ursachenanalyse und -beseitigung	Support	5	ACQ, DEV, SVC
CM - Configuration Management	Konfigurationsmanagement	Support	2	ACQ, DEV, SVC
DAR - Decision Analysis and Resolution	Entscheidungfindung	Support	3	ACQ, DEV, SVC
IPM - Integrated Project Management IWM - Integrated Work Management	Fortgeschrittenes Projektmanagement Fortgeschrittenes Arbeitsmanagement	Project Management	3	ACQ, DEV, SVC
IRP - Incident Resolution and Prevention	Störungsbeseitigung und -vermeidung	Service Establishment and Delivery	3	SVC
MA - Measurement and Analysis	Messung und Analyse	Support	2	ACQ, DEV, SVC
OPD - Organisational Process Definition	Organisationsweite Prozessentwicklung	Process Management	3	ACQ, DEV, SVC
OPF - Organisational Process Focus	Organisationsweite Prozessausrichtung	Process Management	3	ACQ, DEV, SVC
OPM - Organisational Performance Management	Organisationsweites Prozessfähigkeitsmanagement	Process Management	5	ACQ, DEV, SVC
OPP - Organisational Process Performance	Organisationsweite Prozessfähigkeit	Process Management	4	ACQ, DEV, SVC
OT - Organisational Training	Organisationsweites Aus- und Weiterbildung	Process Management	3	ACQ, DEV, SVC
PI - Product Integration	Produktintegration	Engineering	3	DEV
PMC - Project Monitoring and Control WMC - Work Monitoring and Control	Projektverfolgung und -steuerung Arbeitsverfolgung und -steuerung	Project Management	2	ACQ, DEV, SVC
PP - Project Planning WP - Work Planning	Projektplanung Arbeitsplannung	Project Management	2	ACQ, DEV, SVC
PPQA - Process and Product Quality Assurance	Qualitätssicherung von Prozessen und Produkten	Support	2	ACQ, DEV, SVC
QPM - Quantitative Project Management QWM - Quantitative Work Management	Quantitatives Projektmanagement Quantitatives Arbeitsmanagement	Project Management	4	ACQ, DEV, SVC
RD - Requirements Development	Anforderungsentwicklung	Engineering	3	DEV
REQM - Requirements Management	Anforderungsmanagement	Project Management	2	ACQ, DEV, SVC
RSKM - Risk Management	Risikomanagement	Project Management	3	ACQ, DEV, SVC
SAM - Supplier Agreement Management	Management von Lieferantenvereinbarungen	Project Management	2	DEV, SVC
SCON - Service Continuity	Kontinuität des Services	Service Establishment and Delivery	3	SVC
SD - Service Delivery	Serviceerbringung	Service Establishment and Delivery	2	SVC
SSAD - Solicitation and Supplier Agreement Development	Einholen von Angeboten und Entwicklung der Lieferantenvereinbarungen	Acquisition	2	ACQ
SSD - Service System Development	Servicesystementwickung	Service Establishment and Delivery	3	SVC
SST - Service System Transition	Servicesystemablösung	Service Establishment and Delivery	3	SVC
STSM - Strategic Service Management	Strategisches Servicemanagement	Service Establishment and Delivery	3	SVC
TS - Technical Solution	Technische Umsetzung	Engineering	3	DEV
VAL - Validation	Validierung	Engineering	3	DEV
VER - Verification	Verifizierung	Engineering	3	DEV
Process Area (engl.)	Process Area (dt.)	Category	Maturity Level	CMMI model

 

Core Process Areas

In CMMI v1.3 Core Process Areas are common to all CMMI constellations. Since v1.2 the three constellations have 16 PAs in common. Because of the very specific nature of some constellations, the terminology used in those constellations was refined in v1.3.
One such term was the word "project" that was used in all three v1.2 CMMI models. However, for the service providers this term posed difficulties to interpret — since development usually is, deployed in projects, whereas services usually are realisied in teams with corresponding work load. In CMMI-SVC v1.3 "project" was changed to "work". That resulted in changing the PA names such as Work Planning, Work Management and Control, Integrated Work Management.
Even though the PA names changed those PAs are still considered core process areas. There is only one shared PA: Supplier Agreement Management (SAM).

 

 

CMMI Model Characteristics

CMMI models are characterised by

• Process Categories with related Process Areas
• Generic Goals (GG) and generic practices describe the PA's purposes
• Specific Goals (SG) and specific practices to fulfill these GGs
• Capability and maturity levels associated to generic and specific practices

 

 

Process Categories and Process Areas

In CMMI process areas are clustered by categories. All three CMMI v.1.3 constellations have the following three categories in common:

• Project Management
• Support
• Process Management

Process management and process improvement are organisation wide issues. In some firms the process areas of this category will be implemented by teams or projects, in other companies organisation wide.

In addition for each of these constellation resp. model there is a domain-specific category:

• Engineering for CMMI-DEV
• Acquisition for CMMI-ACQ
• Service Establishment and Delivery for CMMI-SVC

 

Generic Goals and Generic Practices

Each process area is defined by a set of goals and practices: Generic Goals (GG) and generic practices describing the PA's purposes and Specific Goals (SG) and specific practices to fulfill these GGs. Generic goals and generic practices are a part of every process area. They describe generically the goals and resp. ways how to achieve them. Generic goals and generic practices are further detailled by specific goals and specific practices (see below). Generic goals apply to more than one PA.

• GG 1 Achieve Specific Goals
  • GP 1.1 Perform Specific Practices

• GG 2 Institutionalise a Managed Process
  • GP 2.1 Establish an Organisational Policy
  • GP 2.2 Plan the Process
  • GP 2.3 Provide Resources
  • GP 2.4 Assign Responsibility
  • GP 2.5 Train People
  • GP 2.6 Control Work Products
  • GP 2.7 Identify and Involve Relevant Stakeholders
  • GP 2.8 Monitor and Control the Process
  • GP 2.9 Objectively Evaluate Adherence
  • GP 2.10 Review Status with Higher Level Management

• GG 3 Institutionalise a Defined Process
  • GP 3.1 Establish a Defined Process
  • GP 3.2 Collect Process Related Experiences

Achieving each of these goals relative to a certain PA significantly improves the performance of the associated process. Achieving each of these goals relative to each PA significantly enables the institutionalization that will ensure the process is repeatable and lasting. The Generic Goals are cumulative related to maturity levels in specifiying how a certain level can be achieved. So saying that a process area is CL3 (or GG3) includes that they are achieving GG1 and GG2 as well. Generic Goals are, in fact, perfectly in parallel with the process capability levels (see below and my post on Process Capability). In other words, Generic Goal 1 (GG1) aligns with Capability Level 1 (CL1), GG2 with CL2, and GG3 with CL3, and so on. So when someone says their process area(s) are performing at "Capability Level 3" she is saying that their process areas are achieving Generic Goal 3. Generic Practices are practices that apply to any PA because, in principle, they can improve the performance of any process. The description of generic practices directly follows the generic goal to which they contribute.

Specific Goals and Specific Practices

Specific Goals apply to only one PA and address the unique characteristics that describe what must be implemented to satisfy the purpose of the PA. In this context a Specific Practice is an activity that is considered important in achieving the specific goal that is mapped to a PA.

In the following as example the Specific Goals and Specific Practices for Process Area PP - Project Planning is stated. PP is a process area at Maturity Level 2 with the purpose to establish and maintain plans that define project activities.

Specific Practices by Goal

• SG 1 Establish Estimates
  • SP 1.1 Estimate the Scope of the Project
  • SP 1.2 Establish Estimates of Work Product and Task Attributes
  • SP 1.3 Define Project Lifecycle Phases
  • SP 1.4 Estimate Effort and Cost
• SG 2 Develop a Project Plan
  • SP 2.1 Establish the Budget and Schedule
  • SP 2.2 Identify Project Risks
  • SP 2.3 Plan Data Management
  • SP 2.4 Plan the Project's Resources
  • SP 2.5 Plan Needed Knowledge and Skills
  • SP 2.6 Plan Stakeholder Involvement
  • SP 2.7 Establish the Project Plan
• SG 3 Obtain Commitment to the Plan
  • SP 3.1 Review Plans that Affect the Project
  • SP 3.2 Reconcile Work and Resource Levels
  • SP 3.3 Obtain Plan Commitment

 

CMMI Representations

Reading Time: 2 minutes Process maturity and capability can have two different representations: staged or continuous. The differences between the structures are subtle but significant.
The staged representation uses so-called maturity levels to characterise the overall state of the organisation's processes relative to the model as a whole.
Instead, the continuous representation of uses so-called capability levels to characterise the state of the organisation's processes relative to an individual process area. Process capability relates to the performances of (some) processes of a certain process area.

 

Maturity and Capability Levels

Reading Time: 4 minutes Process maturity means that whatever an organisation is doing, it is done in a well-documented way, and everyone knows what is expected of them and performs accordingly.
A process is capable if it satisfies its specified product quality, service quality, and process performance objectives. A capable process consistently produces output that is within specifications. Execution of capable process always gives predictable results.
Process maturity levels classify organisations according to their ability to control their various processes. Process capability levels classify the performances of (some) processes of a certain process area done by an organisation, organisational department, or project. Process maturity models define reference and assessment schemes for maturity resp. capability levels in detail.

Process Institutionalisation

Institutionalization is an important concept in process improvement. When mentioned in the generic goal and generic practice descriptions, institutionalization implies that the process is ingrained in the way the work is performed and there is company-wide commitment and consistency to performing the process.
Process Institutionalization ensures that

• process improvement is related to business goals
• processes will be executed or managed consistently
• the processes will survive staff or leadership changes
• commitment to provide resources or infrastructure to support or improve the processes
• historical data will be useful to support future projects

When the requirements and objectives for the process change, however, the implementation of the process may also need to change to ensure that it remains effective. The generic practices describe activities that address these aspects of institutionalization. The degree of institutionalization is embodied in the generic goals and expressed in the names of the processes associated with each goal as indicated in the following table.

Generic Goals and Processes

Generic Goal	Progression of Processes
GG 1	Performed process
GG 2	Managed process
GG 3	Defined process
GG 4	Quantitatively managed process
GG 5	Optimising process

A process can be instantiated by a project, group, or organisational function. Management of the process is concerned with institutionalization and the achievement of other specific objectives established for the process, such as cost, schedule, and quality objectives. The control provided by a managed process helps to ensure that the established process is retained during times of stress. A critical distinction between a performed process and a managed process is the extent to which the process is managed. A managed process is planned (the plan can be part of a more encompassing plan) and the execution of the process is managed against the plan. Corrective actions are taken when the actual results and execution deviate significantly from the plan. A managed process achieves the objectives of the plan and is institutionalized for consistent execution. While generic goals and generic practices are the model components that directly address the institutionalization of a process across the organisation, many process areas likewise address institutionalization by supporting the implementation of the generic practices. Such process areas contain one or more specific practices that when implemented can also fully implement a generic practice or generate a work product that is used in the implementation of a generic practice.

Process Improvement

An organisation can use a CMMI model to help set process improvement objectives and priorities, improve processes, and provide guidance for ensuring stable, capable, and mature processes.
A capability maturity model outlines the characteristics of a mature, capable process. It identifies the practices that are basic to implementing effective processes as well as advanced practices. It also assigns to those practices associated maturity levels ranging from unrepeatable to a mature, well-managed process.
Typically a path for improvement is recommended through the various practices to achieve higher levels of maturity and, therefore, improve an organisation's processes.

CMMI supports two improvement paths using levels. One path enables organisations to incrementally improve processes corresponding to an individual process area (or group of process areas) selected by the organisation. The other path enables organisations to improve a set of related processes by incrementally addressing successive sets of process areas. These two improvement paths are associated with the two types of levels: capability levels and maturity levels. These levels correspond to two approaches to process improvement called "representations" — continuous and staged.

Using the continuous representation enables you to achieve "capability levels." — Using the staged representation enables you to achieve "maturity levels."
To reach a particular level, an organisation must satisfy all of the goals of the process area or set of process areas that are targeted for improvement, regardless of whether it is a capability or a maturity level.
Both representations provide ways to improve your processes to achieve business objectives, and both provide the same essential content and use the same model components.

CMMI process improvement initiatives usually follows the IDEAL methodology. The IDEAL model — Initiating, Diagnosing, Establishing, Acting & Learning. IDEAL is an organisational process improvement and defect-reduction methodology published by SEI. It serves as a roadmap for initiating, planning, and implementing CMMI improvement actions. The IDEAL model is named for the five phases it describes: Initiating, Diagnosing, Establishing, Acting, Learning.

Process Maturity Appraisals

CMMI models provide guidance for developing or improving processes that meet the business goals of an organisation. A CMMI model may also be used as a framework for appraising the process maturity of the organisation. Regardless of which model an organisation chooses, CMMI proven practices should be adapted to each individual organisation according to its business objectives. Organisations cannot be CMMI "certified". Instead, an organisation is appraised (e.g., using an appraisal method like SCAMPI) and is awarded a 1-5 level rating. The rating results of such an appraisal can be published if released by the appraised organisation.

Further Readings