Process Area Components

This chapter describes the components found in each process area, and in the generic goals and generic practices. Understanding the meaning of these components is critical to using the information in Part Two effectively. If you are unfamiliar with Part Two, you may want to skim the “Generic Goals and Generic Practices” section and a couple of process area sections to get a general feel for the content and layout before reading this chapter.

Required, Expected, and Informative Components

Model components are grouped into three categories—required, expected, and informative—that reflect how to interpret them.

Required Components

Required components describe what an organization must achieve to satisfy a process area. This achievement must be visibly implemented in an organization’s processes. The required components in CMMI are the specific and generic goals. Goal satisfaction is used in appraisals as the basis for deciding whether a process area has been satisfied.

Expected Components

Expected components describe what an organization may implement to achieve a required component. Expected components guide those who implement improvements or perform appraisals. The expected components in CMMI are the specific and generic practices.

Before goals can be considered satisfied, either the practices as described or acceptable alternatives to them must be present in the planned and implemented processes of the organization.

Informative Components

Informative components provide details that help organizations understand the required and expected components. Subpractices, typical work products, goal and practice titles, goal and practice notes, examples, and references are examples of informative model components.

The CMMI glossary of terms is not a required, expected, or informative component of CMMI models. You should interpret the terms in the glossary in the context of the model component in which they appear.

Components Associated with Part Two

The model components associated with Part Two can be summarized to illustrate their relationships, as shown in Figure 2.1.

Figure 2.1: CMMI Model Components

The following sections provide detailed descriptions of CMMI model components.

Process Areas

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

There are twenty-four process areas, presented in alphabetical order by acronym:

· Capacity and Availability Management (CAM)

· Causal Analysis and Resolution (CAR)

· Configuration Management (CM)

· Decision Analysis and Resolution (DAR)

· Integrated Project Management (IPM)

· Incident Resolution and Prevention (IRP)

· Measurement and Analysis (MA)

· Organizational Innovation and Deployment (OID)

· Organizational Process Definition (OPD)

· Organizational Process Focus (OPF)

· Organizational Process Performance (OPP)

· Organizational Training (OT)

· Project Monitoring and Control (PMC)

· Project Planning (PP)

· Process and Product Quality Assurance (PPQA)

· Quantitative Project Management (QPM)

· Requirements Management (REQM)

· Risk Management (RSKM)

· Service Continuity (SCON)

· Service Delivery (SD)

· Service System Development (SSD)

· Service System Transition (SST)

· Strategic Service Management (STSM)

Purpose Statements

A purpose statement describes the purpose of the process area and is an informative component.

For example, the purpose statement of the Organizational Process Definition process area is “The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.”

Introductory Notes

The introductory notes section of the process area describes the major concepts covered in the process area and is an informative component.

An example from the introductory notes of the Project Planning process area is “Planning begins with requirements that define the product and project.”

Related Process Areas

The related process areas section lists references to related process areas and reflects the high-level relationships among the process areas. The related process area section is an informative component.

An example of a reference found in the related process areas section of the Project Planning process area is “Refer to the Risk Management process area for more information about identifying and managing risks.”

Specific Goals

A specific goal describes the unique characteristics that must be present to satisfy the process area. A specific goal is a required model component and is used in appraisals to help determine whether a process area is satisfied.

For example, a specific goal from the Configuration Management process area is “Integrity of baselines is established and maintained.”

Only the statement of the specific goal is a required model component. The title of a specific goal (preceded by the goal number) and notes associated with the goal are considered informative model components.

Generic Goals

Generic goals are called generic because the same goal statement applies to multiple process areas. A generic goal describes the characteristics that must be present to institutionalize the processes that implement a process area. A generic goal is a required model component and is used in appraisals to determine whether a process area is satisfied. (See the “Generic Goals and Generic Practices” section in Part Two for a more detailed description of generic goals.)

An example of a generic goal is “The process is institutionalized as a defined process.”

Only the statement of the generic goal is a required model component. The title of a generic goal (preceded by the goal number) and notes associated with the goal are considered informative model components.

Specific Goal and Practice Summaries

The specific goal and practice summary provides a high-level summary of the specific goals, which are required components, and the specific practices, which are expected components. The specific goal and practice summary is an informative component.

Specific Practices

A specific practice is the description of an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities that are expected to result in achievement of the specific goals of a process area. A specific practice is an expected model component.

For example, a specific practice from the Project Monitoring and Control process area is “Monitor commitments against those identified in the project plan.”

Only the statement of the specific practice is an expected model component. The title of a specific practice (preceded by the practice number) and notes associated with the specific practice are considered informative model components.

Typical Work Products

The typical work products section lists sample output from a specific practice. These examples are called typical work products because there are often other work products that are just as effective but are not listed. A typical work product is an informative model component.

For example, a typical work product for the specific practice “Monitor actual values of project planning parameters against the project plan” in the Project Monitoring and Control process area is “Records of significant deviations.”

Subpractices

A subpractice is a detailed description that provides guidance for interpreting and implementing a specific or generic practice. Subpractices may be worded as if prescriptive, but they are actually an informative component meant only to provide ideas that may be useful for process improvement.

For example, a subpractice for the specific practice “Take corrective action on identified issues” in the Project Monitoring and Control process area is “Determine and document the appropriate actions needed to address identified issues.”

Generic Practices

Generic practices are called generic because the same practice applies to multiple process areas. A generic practice is the description of an activity that is considered important in achieving the associated generic goal. A generic practice is an expected model component.

For example, a generic practice for the generic goal “The process is institutionalized as a managed process” is “Provide adequate resources for performing the process, developing the work products, and providing the services of the process.”

Only the statement of the generic practice is an expected model component. The title of a generic practice (preceded by the practice number) and notes associated with the practice are considered informative model components.

Supporting Informative Components

There are many places in the model where further information is needed to describe a concept. This informative material is provided in the form of the following components:

· Notes

· Examples

· References

Notes

A note is text that can accompany nearly any other model component. It may provide detail, background, or rationale. A note is an informative model component.

For example, a note that accompanies the specific practice “Implement selected action proposals developed in causal analysis” in the Causal Analysis and Resolution process area is “Only changes that prove to be of value should be considered for broad implementation.”

Examples

An example is a component comprising text and often a list of items, usually in a box, that can accompany nearly any other component and provides one or more examples to clarify a concept or described activity. An example is an informative model component.

The following is an example that accompanies the subpractice “Document noncompliance issues when they cannot be resolved in the project” under the specific practice “Communicate quality issues and ensure the resolution of noncompliance issues with the staff and managers” in the Process and Product Quality Assurance process area.

Examples of ways to resolve noncompliance in the project include the following:

· Fixing the noncompliance

· Changing the process descriptions, standards, or procedures that were violated

· Obtaining a waiver to cover the noncompliance

References

A reference is a pointer to additional or more detailed information in related process areas and can accompany nearly any other model component. A reference is an informative model component.

For example, a reference that accompanies the specific practice “Select subprocesses that compose the project’s defined process based on historical stability and capability data” in the Quantitative Project Management process area is “Refer to the Organizational Process Definition process area for more information about the organization’s process asset library, which might include a process element of known and needed capability.”

Numbering Scheme

Specific and generic goals are numbered sequentially. Each specific goal begins with the prefix SG (e.g., SG 1). Each generic goal begins with the prefix GG (e.g., GG 2).

Specific and generic practices also are numbered sequentially. Each specific practice begins with the prefix SP, followed by a number in the form x.y (e.g., SP 1.1). The x is the same number as the goal to which the specific practice maps. The y is the sequence number of the specific practice under the specific goal.

An example of specific practice numbering is in the Project Planning process area. The first specific practice is numbered SP 1.1 and the second is SP 1.2.

Each generic practice begins with the prefix GP, followed by a number in the form x.y (e.g., GP 1.1).

The x corresponds to the number of the generic goal. The y is the sequence number of the generic practice under the generic goal. For example, the first generic practice associated with GG 2 is numbered GP 2.1 and the second is GP 2.2.

Typographical Conventions

The typographical conventions used in this model were designed to enable you to select what you need and use it effectively. We present model components in formats that allow you to find them quickly on the page.

Figures 2.2 through 2.3 are sample pages from process areas in Part Two; they show the different process area components, labeled so that you can identify them. Notice that components differ typographically so that you can easily identify each one.

Figure 2.2: Sample Page from Decision Analysis and Resolution

Figure 2.3: Sample Page from Acquisition Technical Management