What is Maturity Levels ?

To support those using the staged representation, all CMMI models reflect maturity levels in their design and content. A maturity level consists of related specific and generic practices for a predefined set of process areas that improve the organization’s overall performance. The maturity level of an organization provides a way to predict an organization’s performance in a given discipline or set of disciplines.

A maturity level is a defined evolutionary plateau for organizational process improvement. Each maturity level matures an important subset of the organization’s processes, preparing it to move to the next maturity level. The maturity levels are measured by the achievement of the specific and generic goals associated with each predefined set of process areas.

There are five maturity levels, each a layer in the foundation for ongoing process improvement, designated by the numbers 1 through 5:

1. Initial

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Maturity Level 1: Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually does not provide a stable environment to support the processes. Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes. Maturity level 1 organizations are characterized by a tendency to over commit, abandonment of processes in a time of crisis, and an inability to repeat their successes.

Maturity Level 2: Managed

At maturity level 2, the projects of the organization have ensured that processes are planned and executed in accordance with policy; the projects employ skilled people who have adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions. The process discipline reflected by maturity level 2 helps to ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

Maturity Level 3: Defined

At maturity level 3, processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization’s set of standard processes, which is the basis for maturity level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization’s set of standard processes according to tailoring guidelines. (See the glossary for a definition of “organization’s set of standard processes.”)

A critical distinction between maturity levels 2 and 3 is the scope of standards, process descriptions, and procedures. At maturity level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (e.g., on a particular project). At maturity 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.

Maturity Level 4: Quantitatively Managed

At maturity level 4, the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing processes. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance is understood in statistical terms and is managed throughout the life of the processes.

A critical distinction between maturity levels 3 and 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are typically only qualitatively predictable.

Maturity Level 5: Optimizing

At maturity level 5, an organization continually improves its processes based on a quantitative understanding of the common causes of variation inherent in processes. Maturity level 5 focuses on continually improving process performance through incremental and innovative process and technological improvements. Quantitative process improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement.

What is Capability Levels ?

To support those using the continuous representation, all CMMI models reflect capability levels in their design and content. A capability level consists of a generic goal and its related generic practices as they relate to a process area, which can improve the organization’s processes associated with that process area.

The six capability levels, designated by the numbers 0 through 5, are as follows:

0. Incomplete

1. Performed

2. Managed

3. Defined

4. Quantitatively Managed

5. Optimizing

Capability Level 0: Incomplete

An “incomplete process” is a process that either is not performed or partially performed. One or more of the specific goals of the process area are not satisfied, and no generic goals exist for this level since there is no reason to institutionalize a partially performed process.

Capability Level 1: Performed

A capability level 1 process is characterized as a “performed process.” A performed process is a process that satisfies the specific goals of the process area. It supports and enables the work needed to produce work products.

Capability Level 2: Managed

A capability level 2 process is characterized as a “managed process.” A managed process is a performed (capability level 1) process that has the basic infrastructure in place to support the process. It is planned and executed in accordance with policy; employs skilled people who have 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.

Capability Level 3: Defined

A capability level 3 process is characterized as a “defined process.” A defined process is a managed (capability level 2) process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines, and contributes work products, measures, and other process improvement information to the organizational process assets.

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

Capability Level 4: Quantitatively Managed

A capability level 4 process is characterized as a “quantitatively managed process.” A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the process. Quality and process performance is understood in statistical terms and is managed throughout the life of the process.

Capability Level 5: Optimizing

A capability level 5 process is characterized as an “optimizing process.” An optimizing process is a quantitatively managed (capability level 4) process that is improved based on an understanding of the common causes of variation inherent in the process. The focus of an optimizing process is on continually improving the range of process performance through both incremental and innovative improvements.

Process Areas

A process area is a cluster of related practices in an area that, when implemented collectively, satisfy a set of goals considered important for making improvement in that area.

There are 22 process areas, presented here in alphabetical order by acronym:

• Causal Analysis and Resolution (CAR)
• Configuration Management (CM)
• Decision Analysis and Resolution (DAR)
• Integrated Project Management +IPPD (IPM+IPPD)(*)
• Measurement and Analysis (MA)
• Organizational Innovation and Deployment (OID)
• Organizational Process Definition +IPPD (OPD+IPPD)⁶
• Organizational Process Focus (OPF)
• Organizational Process Performance (OPP)
• Organizational Training (OT)
• Product Integration (PI)
• Project Monitoring and Control (PMC)
• Project Planning (PP)
• Process and Product Quality Assurance (PPQA)
• Quantitative Project Management (QPM)
• Requirements Development (RD)
• Requirements Management (REQM)
• Risk Management (RSKM)
• Supplier Agreement Management (SAM)
• Technical Solution (TS)
• Validation (VAL)
• Verification (VER)

(*)This process area has "+IPPD" after its name because it contains a goal and practices that are specific to IPPD. The material specific to IPPD is called an "IPPD addition." All process areas with IPPD additions have "+IPPD" after their name.

The continuous approach to Process Improvement

In this approach to Process improvement, you select the processes that are important to your business objectives. Since there are 22 process areas to choose from, this is usually too many to focus on when starting out. You may need to narrow your focus. For example, you may find that your competitor always releases its product before yours. You may choose to focus on improving your engineering and project management processes.

Building on this decision, you select all the Engineering process areas as a starting point: Product Integration, Requirements Development, Requirements Management, Technical Solution, Validation, and Verification. You also select Project Planning and Project Monitoring and Control.

You may at this point decide that eight process areas are still too many to focus on initially, and you decide that the requirements process is really where the problems are. Consequently, you select the Requirements Development and Requirements Management process areas to begin your improvement efforts.

Next you decide how much improvement is needed in the requirements area. Do you have any processes in place already? If you do not, your process improvement objective may be to get to capability level 1.

Do you have your requirements development and management processes in place for each project, but they are not managed processes? For example, policies, training, and tools are not implemented to support the processes. If your requirements processes are in place but there is no supporting infrastructure, your process improvement objective may be to get to capability level 2.

Do you have all your requirements development and management processes and their management in place, but each project performs these processes differently? For example, your requirements elicitation process is not performed consistently across the organization. If this is the case, your process improvement objective may be to get to capability level 3.

Do you consistently manage and perform your requirements development and management processes but do not have an objective way to control and improve these processes? If this is the case, your process improvement objective may be to get to capability level 4.

Do you want to ensure that you are selecting the right subprocesses to improve based on quantitative objectives to maximize your business? If so, your process improvement objective may be to get to capability level 5 for selected processes. In the description of each process area, remember to look for amplifications introduced by the phrases “For Hardware Engineering,” “For Systems Engineering,” and “For Software Engineering.” Use all information that has no specific markings and the material in the boxes labeled “Continuous Only.”

As you can see from this scenario, you need to understand which processes need improvement and how much you want to mature each process. This way of proceeding reflects the fundamental principle behind the continuous representation.

CMMI for Software Development

The CMMI for Development constellation consists of two models: CMMI for Development +IPPD (Integrated Product and Process Development) and CMMI for Development (without IPPD). Both models share much of their material and are identical in these shared areas. However, CMMI for Development +IPPD contains additional goals and practices that cover IPPD.

Currently, only one model is published since the CMMI for Development +IPPD model contains the full complement of practices available in this constellation, and you can derive the other model from this material. If you are not using IPPD, ignore the information that is marked “IPPD Addition,” and you will be using the CMMI for Development model. If the need arises or the development constellation is expanded, the architecture will allow other models to be generated and published.

CMMI for Development is the designated successor of the three source models. The SEI has retired the Software CMM and the IPD-CMM. EIA has retired the SECM. All three of these models are succeeded by CMMI for Development.

The best practices in the CMMI models have gone through an extensive review process. CMMI version 0.2 was publicly reviewed and used in pilot activities.

The CMMI Product Team evaluated more than 3,000 change requests to create CMMI version 1.0. Shortly thereafter, version 1.02 was released, which incorporated several minor improvements.

Version 1.1 incorporated improvements guided by feedback from early use, with more than 1,500 change requests submitted as part of the public review, and hundreds of comments as part of the change control process.

CMMI version 1.2 was developed using input from nearly 2,000 change requests submitted by CMMI users. More than 750 of those requests were directed at CMMI model content. As you can see, not only is CMMI widely adopted, but it is improved based on the feedback received from the community.

How CMMI was born ?

Since 1991, CMMs have been developed for myriad disciplines. Some of the most notable include models for systems engineering, software engineering, software acquisition, workforce management and development, and integrated product and process development (IPPD).

Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the discipline-specific models used by each group, including their architecture, content, and approach, have limited these organizations’ capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities.

The CMM Integration^SM project was formed to sort out the problem of using multiple CMMs. Using information from these popular and well-regarded models as source material, the CMMI Product Team created a cohesive set of integrated models that can be adopted by those currently using the source models, as well as by those new to the CMM concept. Hence, CMMI is a result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.

Recently, the CMMI model architecture was improved to support multiple constellations and the sharing of best practices among constellations and their member models. Work has begun on two new constellations: one for services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). Although CMMI for Development incorporates the development of services, including the combination of components, consumables, and people intended to meet service requirements, it differs from the planned CMMI for Services (CMMI-SVC), which focuses on the delivery of services. The CMMI models that have been available in the community prior to 2006 are now considered part of the CMMI for Development constellation.

About Capability Maturity Model

In its research to help organizations develop and maintain quality products and services, the Software Engineering Institute (SEI) has found several dimensions that an organization can focus on to improve its business. Figure below illustrates the three critical dimensions that organizations typically focus on: people, procedures and methods, and tools and equipment.

This is not to say that people and technology are not important. We are living in a world where technology is changing by an order of magnitude every ten years. Similarly, people typically work for many companies throughout their careers. We live in a dynamic world. A focus on process provides the infrastructure necessary to deal with an ever-changing world, and to maximize the productivity of people and the use of technology to be more competitive.

Manufacturing has long recognized the importance of process effectiveness and efficiency. Today, many organizations in manufacturing and service industries recognize the importance of quality processes. Process helps an organization’s workforce meet business objectives by helping them work smarter, not harder, and with improved consistency. Effective processes also provide a vehicle for introducing and using new technology in a way that best meets the business objectives of the organization.

The SEI has taken the process management premise, “the quality of a system or product is highly influenced by the quality of the process used to develop and maintain it,” and defined CMMs (Capability Maturity Models) that embody this premise. The belief in this premise is seen worldwide in quality movements, as evidenced by the International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) body of standards.

CMMs focus on improving processes in an organization. They contain the essential elements of effective processes for one or more disciplines and describe an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness.