CHIPS Articles: CMMI — What, Why? Part 1

Overview

The Software Capability Maturity Model® (CMM®) was produced by the Software Engineering Institute in 1991 to provide guidance for software organizations to use when developing processes. Its successful application resulted in the development of other CMMs for a myriad of disciplines, including systems engineering, software acquisition, and workforce management and development. Some of these were developed by national bodies, and some by individual organizations. For example, I architected and implemented the Electronic Data Systems Value Delivery Framework utilizing maturity modeling principles. Although these models have proven useful to many organizations, the use of multiple models has been problematic.

The differences among these discipline-specific models limit an organization's ability to successfully focus their improvement efforts across the various disciplines employed. Further, applying multiple models that are not integrated within and across an organization is more costly in terms of training, appraisals and improvement activities.

The CMM Integration project was formed to address the problem of multiple CMMs. The CMMI Product Team's mission was to combine three source models into a single improvement framework for use by organizations pursuing enterprise-wide process improvement. The team built a CMMI Framework which permits the generation of multiple CMMI models addressing various disciplines (see Figure 1). The first model created was the CMMI for Systems and Software Engineering. Currently available CMMI models are shown in Table 1.

Additionally, there are two different representations available for each model— staged and continuous. Consequently, an organization has to decide (considering both disciplines and representations) which of the available CMMI models best fits their process improvement needs.

Representations

The staged architecture, employed in the Software CMM and others, is portrayed in Figure 2. Each Maturity Level has specific Process Areas (PAs) associated with it. The Maturity Level 2 Process Areas focus on getting documented processes in place at the project level. Maturity Level 3 provides a framework of standard processes for leveraging best practices across the organization. Maturity Levels 4 and 5 focus on detailed process and product metrics for control and improvement. The staged architecture provides a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels, each serving as a foundation for the next.

The continuous architecture, also illustrated in Figure 2, was first implemented in the Systems Engineering CMM. It focuses on specific Process Areas; each PA can be rated at a Capability Level ranging from 0 to 5. These Capability Levels are analogous to the Maturity Levels of the staged architecture, but applied at the Process Area level. Each Capability Level has an associated Generic Goal, discussed in the next section. The continuous architecture has the advantage of providing a fairly well-defined improvement path for a specific PA. It allows the organization to select the order of improvement that best meets their business objectives. However, using the continuous architecture can make it difficult to provide guidance to an organization which is attempting to rationally allocate limited improvement resources across a number of PAs.

The staged architecture, employed in the Software CMM and others, is portrayed in Figure 2. Each Maturity Level has specific Process Areas (PAs) associated with it. The Maturity Level 2 Process Areas focus on getting documented processes in place at the project level. Maturity Level 3 provides a framework of standard processes for leveraging best practices across the organization. Maturity Levels 4 and 5 focus on detailed process and product metrics for control and improvement. The staged architecture provides a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels, each serving as a foundation for the next.

The continuous architecture, also illustrated in Figure 2, was first implemented in the Systems Engineering CMM. It focuses on specific Process Areas; each PA can be rated at a Capability Level ranging from 0 to 5. These Capability Levels are analogous to the Maturity Levels of the staged architecture, but applied at the Process Area level. Each Capability Level has an associated Generic Goal, discussed in the next section. The continuous architecture has the advantage of providing a fairly well-defined improvement path for a specific PA. It allows the organization to select the order of improvement that best meets their business objectives. However, using the continuous architecture can make it difficult to provide guidance to an organization which is attempting to rationally allocate limited improvement resources across a number of PAs.

The staged and continuous representations of the CMMI models are identical at the detailed goal and practice level (except for the base and advanced practices in the continuous representation). Therefore, implementation of the two versions (for the same components) will be identical. The only question is the order of component implementation. These priorities will be driven by the needs of the organization, which are a function of the business purposes and current problems.

Process Areas, Goals and Practices

Process Areas are the major building blocks in establishing the process capability of an organization. They contain clusters of related practices which collectively achieve a set of goals (e.g., project planning). Each PA has one or more goals. A goal is a high level statement of the outcome to be achieved by effective implementation of a group of practices. Practices describe actions necessary to enact key elements of a process area.

Each Process Area within the CMMI has Specific and Generic Goals and Practices (see Figure 3). The Specific Goals and Practices focus on the activities performed to achieve the objectives of that Process Area. For example, the Requirements Management Process Area has one Specific Goal and five Specific Practices. The Specific Goal is “Requirements are managed and inconsistencies with project plans and work products are identified.” The Specific Practice short titles are: Obtain an Understanding of Requirements, Obtain Commitment to Requirements, Manage Requirements Changes, Maintain Bidirectional Traceability of Requirements, and Identify Inconsistencies between Project Work and Requirements.

Generic Goals and Practices focus on institutionalization; institutionalization implies that the process is ingrained in the way the work is performed in the organization. In the continuous representation each Capability Level has an associated Generic Goal, as portrayed in Table 2. Generic Goal 1 requires only the performance of the Specific Practices associated with Capability Level 1.

Generic Goal 2, Institutionalize a Managed Process, requires he implementation of ten Generic Practices addressing issues such as organization policy, process planning and documentation, training, stakeholder involvement, and process performance certification and review.

In the staged representation the Process Areas associated with a given Maturity Level are required to achieve the Generic Goals associated with that Level. For example, at Maturity Level 3 the Requirements Development Process Area must achieve Generic Goal 3, Institutionalize a Defined Process. In addition to the Generic Practices for Level 2 there are two Practices associated with Level 3: Establish a Defined Process, and Collect Improvement Information. These reflect the fact that Maturity Level 3 expects an organizational approach to process development and implementation.

Institutionalization Issues

Institutionalization is a critical aspect of process improvement and it is an important concept within each Maturity or Capability Level. Institutionalization, as noted previously, is addressed by the Generic Goals and Practices. Each of the Maturity or Capability Levels has the following characteristics.

A managed process is institutionalized by:
• Adhering to organizational policies
• Following established plans and process descriptions
• Providing adequate resources (funding, people, tools)
• Assigning responsibility/authority for performing the process
• Training the people performing and supporting the process
• Placing designated work products under appropriate levels of configuration management
• Identifying and involving relevant stakeholders
• Monitoring and controlling the performance of the process against the plans for performing the process and taking corrective actions
• Objectively evaluating the process, its work products, and its services for adherence to the process descriptions, objectives, and standards, and addressing noncompliance
• Reviewing the activities, status, and results of the process with higher level management, and taking corrective action.

A defined process is institutionalized by:
• Addressing the items that institutionalize a managed process
• Establishing the description of the defined process for the project or organizational unit
• Collecting work products, measures, and improvement information derived from planning and performing the process.

A quantitatively managed process is institutionalized by:
• Addressing the items that institutionalize a defined process
• Controlling the process using statistical and other quantitative techniques such that product quality, service quality, and process performance attributes are measurable and controlled throughout the project

An optimizing process is institutionalized by:
• Addressing the items that institutionalize a quantitatively managed process
• Improving the process based on an understanding of the common causes of variation inherent in the process such that the process focuses on continually improving the range of process performance through both incremental and innovative improvements

Process Area Grouping

Process Areas are grouped into four categories: Process Management, Project Management, Engineering, and Support. Table 3 shows the grouping, as well as the Maturity Levels associated with each PA in the staged representation. Keep in mind that for an organization to be rated at Maturity Level 3 in the staged representation, all the Level 2 Process Areas must satisfy both Generic Goal 2 and Generic Goal 3; that is, the Level 2 PAs must be operating at Capability Level 3.

It may be that particular Process Areas of a Level 4 or Level 5 organization attain Capability Level 4 or Level 5, but this is not a requirement of the staged representation.

Conclusion

This article provided a brief overview of the development and structure of the CMMI. Future articles will focus on providing more details about CMMI appraisals and implementation and transition.

Capability Maturity Model^® and CMM^® are registered in the U.S. Patent and Trademark Office. CMM^SM Integration is a service mark of Carnegie Mellon University.

Richard B. Waina, P.E., Ph.D., Principal of Multi-Dimensional Maturity, has over 35 years’ experience in information technology. He worked for five years at White Sands Missile Range, and worked on a number of missile programs at Hughes Aircraft Company, including Maverick for the USAF, Phoenix for the DON and TOW for the USA. At EDS he was responsible for deploying process maturity assessment methodologies globally. Dr. Waina is an SEI-authorized CMM and CMMI Lead Assessor/Appraiser and instructor for the Introduction to CMMI. He has conducted over 70 CMM/CMMI assessments in nine countries since 1990. He holds engineering degrees from Carnegie Mellon University, New Mexico State University, and Arizona State University.