Capability Maturity Model Integration — CMMI

Overview
[Top]

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 organizational 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, organizational change, and organizational 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 organization.
CMMI helps to integrate traditionally separate organizational 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 organization 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.

Benefits in Using CMMI
[Top]

The CMMI framework is based on proven practices collected from various organization and fields of application. It is applicable for any organization. By implementing CMMI, organizations can be assured of improved processes which gives 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 premise:

• 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 organization’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 organization 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
[Top]

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 organization 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 organization’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).

History of CMMI

CMMI v1.0
[Top]

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
[Top]

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
[Top]

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
[Top]

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 v1.3 — Changes.

CMMI Product Suite
[Top]

Since CMMI v1.3 the CMMI product suite addresses by the notion “constellations” process areas of different business interest, e.g. it covers the doamains of product development (CMMI-DEV), service development (CMMI-SVC), and acqusition (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 consist of:

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

CMMI Constellations and Models
[Top]

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:^[1]

• Product and service development
• Acquisition
• Services

CMMI constellations give a common approach to implement many Project Management, Organizational Process Management and Supporting process areas of work in an organization. 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 organization and to external customers.

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

CMMI constellations. ©: ECC International, http://eccinternational.com

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
[Top]

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”).

Core Process Areas
[Top]

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 v1.3 constellations

CMMI Model Characteristics
[Top]

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

CMMI model components. © SEI, Carnegie Mellon Univ.

Process Categories and Process Areas
[Top]

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
[Top]

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 Institutionalize a Managed Process
  • GP 2.1 Establish an Organizational 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 Institutionalize 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
[Top]

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: Maturity and Capability Levels
[Top]

Process Maturity means that whatever a company is doing, the company does it in a well-documented way, and everyone knows what is expected of them and performs accordingly. Using mature processes performance is not dependent on heroes, and decisions are made on proper situation analysis.

Process Maturity can have two different representations: staged and continuous. The differences between the structures are subtle but significant. The staged representation uses so called maturity levels to characterize the overall state of the organization’s processes relative to the model as a whole. Maturity levels apply to an organization’s process improvement achievement across multiple process areas. Maturity levels are related to process areas: being mature to foster the processes of a certain process area.

CMMI staged representation: for an established set of Process Areas across an organisation

In CMMI there are five maturity levels numbered 1 through 5. These maturity levels relate to the maturity of a company, how well it performes all processes of a certain or of all process areas of it’s process model. They classify organisations according to their ability to control their various processes. As well they describe an evolutionary method for improving an organisation from one that is ad hoc and immature to one that is disciplined and mature or optimised.

1. Performed — This is where everyone starts: your company is making products and you’re earning money, so evidently you’re doing something right. But you’d have a hard time describing precisely how you’re doing it. Your project teams may be managing by the book, but they certainly can’t tell you which book. You’re performing, but you don’t really know why or how well.
2. Managed — At this level, your company’s project teams are well-functioning according to ordered methods that are well-documented. There’s no guarantee that one project team is managed by the same methods as another team, however, and each time a new project is started, you may find the team reinventing the wheel.
3. Defined — This is where all of the methods are well-defined across your company, and all of the projects perform according to those methods rather than figuring them out on their own.
4. Quantatively Managed — The projects perform according to the same methods as at the “defined” level, but at the quantitatively managed level the projects will have plenty of hard data to back their decisions and performance. This enables the projects to make sound decisions and quickly identify deviations, and it obviously requires that the defined processes have been followed for a while.
5. Optimizing — At the last level, the organization continuously focuses on optimizing its work processes. This requires plenty of statistics from the quantitatively managed level.

Process maturity is usually shown in a staged model.

CMMI capability/maturity characteristics

The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations.
To be assessed at a higher level a company must control all elements of the preceding level.

Instead, the continuous representation of CMMI uses so called capability levels to characterize the state of the organization’s processes relative to an individual process area. Process capability relates to the performances of (some) processes of a certain process area.

CMMI continuous representation: for a single Process Area or a set of Process Areas

Continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization’s immediate business objectives, or those to which the organization assigns a high degree of risks. The four capability levels are numbered 0 through 3.

• 0 — Incomplete: The work is done in a way that one or more of the specific goals of the process area are not satisfied and no generic goals exist for this level.
• 1 — Performed: the needed work to produce work products is accomplished, the specific goals of the process area are satisfied.
• 2 — Managed: the work is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description.The process discipline reflected by capability level 2 helps to ensure that existing practices are retained during times of stress.
• 3 — Defined: the processes are tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related experiences to the organizational process assets.

The continuous representation focuses on process area capability as measured by capability levels whereas the staged representation focuses on overall maturity as measured by maturity levels. Capability levels apply to an organization’s process improvement achievement in individual process areas. These levels are a means for incrementally improving the processes corresponding to a given process area.

A critical distinction between capability levels 2 and 3 is the scope of standards, process descriptions, and procedures. At capability level 2, the standards, process descriptions, and procedures can be quite different in each specific instance of the process (e.g., on a particular project).
At capability level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit and therefore are more consistent, except for the differences allowed by the tailoring guidelines.
Another critical distinction is that at capability level 3 processes are typically described more rigorously than at capability level 2. A defined process clearly states the purpose, inputs, entry criteria, activities, roles, measures, verification steps, outputs, and exit criteria.
At capability level 3, processes are managed more proactively using an understanding of the interrelationships of the process activities and detailed measures of the process and its work products.

Process Institutionalisation
[Top]

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 relate 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.

A process can be instantiated by a project, group, or organizational 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 organization, 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
[Top]

An organization 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 organization’s processes.

CMMI road of process improvement

CMMI supports two improvement paths using levels. One path enables organizations to incrementally improve processes corresponding to an individual process area (or group of process areas) selected by the organization. The other path enables organizations 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 organization 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 organizational 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
[Top]

CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization. Regardless of which model an organization chooses, CMMI proven practices should be adapted to each individual organization according to its business objectives. Organizations cannot be CMMI “certified”. Instead, an organization 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 organization.

Further Readings
[Top]