This chapter describes the components found in each process area and in the generic goals and generic practices. Understanding 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.
All CMMI models are produced from the CMMI Framework. This framework contains all of the goals and practices that are used to produce CMMI models that belong to CMMI constellations.
All CMMI models contain 16 core process areas. These process areas cover basic concepts that are fundamental to process improvement in any area of interest (i.e., acquisition, development, services). Some of the material in the core process areas is the same in all constellations. Other material may be adjusted to address a specific area of interest. Consequently, the material in the core process areas may not be exactly the same.
Model components are grouped into three categories—required, expected, and informative—that reflect how to interpret them.
Required components are CMMI components that are essential to achieving process improvement in a given 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 are CMMI components that describe the activities that are important in achieving a required CMMI 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 to be satisfied, either their practices as described, or acceptable alternatives to them, must be present in the planned and implemented processes of the organization.
Authors’ Note
The required and expected components are also referred to as normative material (versus informative material).
Informative components are CMMI components that help model users understand CMMI required and expected components. These components can be example boxes, detailed explanations, or other helpful information. Subpractices, notes, references, goal titles, practice titles, sources, example work products, and generic practice elaborations are informative model components.
The informative material plays an important role in understanding the model. It is often impossible to adequately describe the behavior required or expected of an organization using only a single goal or practice statement. The model’s informative material provides information necessary to achieve the correct understanding of goals and practices and thus cannot be ignored.
For CMMI-ACQ, example supplier deliverables are added informative components that are not found in other CMMI models. These components are included in this model because of the interaction between supplier and acquirer processes.
The model components associated with Part Two are summarized in Figure 2.1 to illustrate their relationships.
Authors’ Note
All model components are important. The informative material helps you to understand the expected and required material. It is best to take these model components as a whole. If you understand the entire model, you can then understand what all the pieces are and how they fit together to form a framework that can benefit your organization.
The following sections provide detailed descriptions of CMMI model components.
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. (See the definition of “process area” in the glossary.)
The 22 process areas are presented in alphabetical order by acronym:
• Agreement Management (AM)
• Acquisition Requirements Development (ARD)
• Acquisition Technical Management (ATM)
• Acquisition Validation (AVAL)
• Acquisition Verification (AVER)
• Causal Analysis and Resolution (CAR)
• Configuration Management (CM)
• Decision Analysis and Resolution (DAR)
• Integrated Project Management (IPM)
• Measurement and Analysis (MA)
• Organizational Process Definition (OPD)
• Organizational Process Focus (OPF)
• Organizational Performance Management (OPM)
• 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)
• Solicitation and Supplier Agreement Development (SSAD)
Authors’ Note
Every time we release a model, someone inevitably tells us that the process areas are not in alphabetical order. Because most users after a short time refer to the process areas by their acronyms, it made sense to list them alphabetically by acronym instead of by full name.
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, work environment standards, and rules and guidelines for teams.”
Authors’ Note
All purpose statements follow the same sentence structure and always contain the process area acronym. An easy way to find a process area in an electronic file is to search for part or all of the purpose statement.
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 Monitoring and Control process area is “When actual status deviates significantly from expected values, corrective actions are taken as appropriate.”
The Related Process Areas section lists references to related process areas and reflects the high-level relationships among the process areas. The Related Process Areas 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 analyzing risks and mitigating risks.”
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. (See the definition of “specific goal” in the glossary.)
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 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 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. See the definition of “generic goal” in the glossary.)
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.
The specific goal and practice summary provides a high-level summary of the specific goals and specific practices. The specific goal and practice summary is an informative component.
Authors’ Note
The specific goal and practice summary shows you at a glance a high-level summary of what is contained in a process area.
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. (See the definition of “specific practice” in the glossary.)
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.
The example work products section lists sample outputs from a specific practice. An example work product is an informative model component. (See the definition of “example work product” in the glossary.)
For instance, an example work product for the specific practice “Monitor Project Planning Parameters” in the Project Monitoring and Control process area is “Records of significant deviations.”
To aid the acquirer, example supplier deliverables are also provided. An example supplier deliverable represents an artifact that is input into or supports the acquirer’s implementation of the practice. An example supplier deliverable is an informative model component.
For instance, an example supplier deliverable for the specific practice “Perform activities with the supplier as specified in the supplier agreement” in the Agreement Management process area is “Supplier project progress and performance reports.”
Authors’ Note
CMMI-ACQ includes a model component called “example supplier deliverables.” This component presents lists of often valuable inputs to the acquirers’ processes that yield, in turn, the example work products of the acquirers’ activities. Example supplier deliverables were included in the model to enable synergy across the acquirer–supplier team, particularly when both organizations are using the same CMMI best practices. Supplier deliverables do not become evidence for appraisals as example work products often do, but providing these deliverables may aid project team members during early planning and acquisition requirements development so that a more complete solicitation can be prepared.
A subpractice is a detailed description that provides guidance for interpreting and implementing a specific or generic practice. Subpractices can be worded as if prescriptive, but they are actually an informative component meant only to provide ideas that may be useful for process improvement. (See the definition of “subpractice” in the glossary.)
For example, a subpractice for the specific practice “Take Corrective Action” in the Project Monitoring and Control process area is “Determine and document the appropriate actions needed to address identified issues.”
Generic practices are called “generic” because the same practice applies to multiple process areas. The generic practices associated with a generic goal describe the activities that are considered important in achieving the generic goal and contribute to the institutionalization of the processes associated with a process area. A generic practice is an expected model component. (See the definition of “generic practice” in the glossary.)
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.
Generic practice elaborations appear after generic practices to provide guidance on how the generic practices can be applied uniquely to process areas. A generic practice elaboration is an informative model component. (See the definition of “generic practice elaboration” in the glossary.)
For example, a generic practice elaboration after the generic practice “Establish and maintain an organizational policy for planning and performing the process” is “This policy establishes organizational expectations for planning and performing the process, including not only the elements of the process addressed directly by the acquirer but also the interactions between the acquirer with suppliers.”
Additions are clearly marked model components that contain information of interest to particular users. An addition can be informative material, a specific practice, a specific goal, or an entire process area that extends the scope of a model or emphasizes a particular aspect of its use. There are no additions in the CMMI-ACQ model.
In many places in the model, further information is needed to describe a concept. This informative material is provided in the form of the following components:
• Notes
• Examples
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 Action Proposals” in the Causal Analysis and Resolution process area is “Only changes that prove to be of value should be considered for broad implementation.”
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 and Resolve Noncompliance Issues” in the Process and Product Quality Assurance process area.
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. (See the definition of “reference” in the glossary.)
For example, a reference that accompanies the specific practice “Compose the Defined Process” in the Quantitative Project Management process area is “Refer to the Organizational Process Definition process area for more information about establishing organizational process assets.”
The difference between a reference that appears in the Related Process Areas section of a process area and one that appears elsewhere in the process area is that the references in the Related Process Areas section represent more fundamental or important relationships and apply to the whole process area.
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 are also 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.
The typographical conventions used in this model were designed to enable you to easily identify and select model components by presenting them in formats that allow you to find them quickly on the page.
Figures 2.2, 2.3, and 2.4 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.
3.139.81.115