Catch, then, oh catch the transient hour; Improve each moment as it flies! | ||
| --Samuel Johnson, Winter: An Ode (1709–1784) | ||
Anyone who isn’t confused really doesn’t understand the situation. | ||
| --Edward R. Murrow (1908–1965) | ||
Chapter 5 presented some basic information about the two CMMI representations, continuous and staged. This chapter continues to explore the relationships between the two representations by taking a more detailed look at how the capability and maturity dimensions are implemented in CMMI.[1] Essentially, the differences in the two representations reflect the methods used to describe the process dimension for each capability or maturity level. Rest assured that while the mechanics of the descriptions may differ, both representations achieve the same improvement purposes through the use of generic goals and practices as required and expected model elements.
Continuous models describe improvement by focusing on capability within individual process areas. Capability levels for a process area are defined by the generic goals. An organization reaches a particular process area capability level when it has satisfied all of the specific goals, all of the generic goals defined for that level, and all of the generic goals from lower levels. Looking at a number of process area capability levels creates a “continuous” profile of the organization’s capability.
Staged models describe the maturity of organizations through successful implementation of ordered groups of process areas. These groups, or stages, improve processes together, based on achievements in the previous stage. Each process area in the staged model includes the appropriate generic goals and practices for its stage.
This chapter discusses in detail the characteristics and mechanisms used by CMMI in defining the capability dimension, the maturity dimension, generic practices, and staging. Chapter 7 addresses the process dimensions for both representations.
The capability dimension is used in the continuous representation of CMMI, just as it was in CMMI’s predecessor source model, EIA 731 (see Section 3.3.2). To start this chapter, we describe the capability levels in CMMI and summarize the mechanism of capability improvement. Section 6.3 offers a more detailed discussion of the individual generic practices.
CMMI includes six levels of process area capability, imaginatively called capability levels (CLs), and numbered 0 through 5. These CLs indicate how well the organization performs in an individual process area. As shown in Figure 6-1, capability level 0 (CL 0) indicates that the processes are Not Performed, which means that one or more of the specific goals of the process area are not satisfied. The capability levels increase up to capability level 5 (CL 5), where the process is performed consistently well and is being continuously improved.
Table 6-1 shows the generic goal statements for each capability level. As indicated in the table, no generic goal exists for CL 0 (Not Performed). The reason for not having a goal is that this level simply signifies “not yet CL 1.”[2]
Table 6-1. Generic Goals
Capability Level | Generic Goal |
|---|---|
CL 0 | No goal. |
CL 1 | GG 1: The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. |
CL 2 | GG 2: The process is institutionalized as a managed process. |
CL 3 | GG 3: The process is institutionalized as a defined process. |
CL 4 | GG 4: The process is institutionalized as a quantitatively managed process. |
CL 5 | GG 5: The process is institutionalized as an optimizing process. |
Capability level 1 is called Performed, and the generic goal for this level focuses on the achievement of the specific goals of the process area. One generic practice is mapped to the CL 1 generic goal; it specifies that the specific practices of the process area are performed at this level of capability. Even though 1 is a lowly number, reaching CL 1 represents a significant achievement for an organization. If a process area is at CL 1, then the specific goals of the process area are satisfied. The added capabilities for CL 2 through CL 5 depend on the specific practices within a process area being performed at their capability level; only when they are performed can they be improved by satisfying higher-level generic goals. Figure 6-2 illustrates how a process increases in capability.
Capability level 2 is called Managed, and its generic goal focuses on institutionalization as a managed process. Ten generic practices are mapped to the CL 2 generic goal. A managed process has increased capability over a performed process; the 10 generic practices provide a definition for that increased capability. In general, a process operating at CL 2 has an organizational policy stating which processes will be used. The projects follow a documented plan and process description. They apply adequate and appropriate resources (including funding, people, and tools), and they maintain appropriate assignment of responsibility and authority. In addition, the projects allow for training of the people performing and supporting the process. Work products are placed under appropriate levels of configuration management. All relevant stakeholders are identified and involved as appropriate. Personnel monitor and control the performance of the process and take corrective action when needed. They objectively evaluate the process, its work products, and its services, and suggest corrective actions where they find noncompliance. The activities, status, and results of the process activities are reviewed with appropriate levels of management, and corrective action is taken if necessary. Thanks to this robust set of generic practices at CL 2, most of which target individual projects, a managed process represents a significant advance relative to a performed process.
Capability level 3 is called Defined, and the generic goal for this level focuses on institutionalization as a defined process. In layman’s terms, for each process area considered, each project in an organization will have a managed process (like that created under CL 2) that is tailored from the organization’s standard processes using standard tailoring guidelines.[3] Two generic practices are mapped to the CL 3 generic goal: Besides the establishment of defined processes, process assets and process measurements must be collected and used for future improvements to the process.
Whereas capability level 2 targets the capability of individual process instances,[4] capability level 3 focuses on organizational standardization and deployment of the processes. Process performance is stabilized across the projects because processes are standardized across the organization; the standard processes, in turn, are tailored for each instance in which that process is needed. Personnel can readily apply their process-based knowledge and skills across multiple instances of the process without expensive retraining.
Capability level 4 is called Quantitatively Managed, and its generic goal focuses on institutionalization as a quantitatively managed process. Without getting into the finer points of statistical process control, a CL 4 process is a defined process (like that created under CL 3—see how this inheritance works?) that uses statistical and other quantitative methods to control selected subprocesses. For example, if you know that requirements-related defects for a certain product historically account for less than 5 percent of the total volume and your process measures (as instituted at CL 3) deviate from that percentage significantly, you can be fairly certain that a problem exists and should be investigated.
Because of the overhead involved and to make general common sense, the process measures selected for CL 4 relate to individual subprocesses—not necessarily all processes or even entire processes. Obviously, the organization should quantitatively manage only those subprocesses that are important to its particular business needs and objectives.
Capability level 5 is called Optimizing, and the generic goal for this level focuses on institutionalization as an optimizing process. CL 5 is a bit tricky, because it essentially requires the organization to constantly adapt the quantitatively managed subprocesses established at CL 4 based on their measures and established objectives for quality and process performance. This requirement doesn’t mean just fixing problems (such as the quality anomaly cited earlier), but also entails analyzing trends, surveying technical practice, addressing common causes of process variation, and then determining how best to adapt the process to changing business needs. This procedure could result in either evolutionary or revolutionary action.
The maturity dimension of a CMMI model is described in the staged representation. Five levels of maturity exist, each of which indicates the process maturity of the organization. Figure 6-3 shows the maturity levels (MLs) and their characteristics.
Note the overlap in the names for maturity levels 2 through 5 and the names for capability levels 2 through 5. Although these capability levels and maturity levels have the same names, they are fundamentally different. A capability level is independently applied to an individual process area, whereas a maturity level specifies a set of process areas whose combined set of goals must be achieved. Furthermore, generic goals and practices follow different inclusion rules in the staged representation than they do in the continuous representation. They are included in the process areas according to the level where the process area is staged. During an appraisal for maturity level 2, for example, the process areas staged at maturity level 2 use the CL 2 generic goal and its associated generic practices. Process areas staged at maturity levels 3 through 5 include the CL 3 generic goal, plus the generic practices from both capability levels 2 and 3. The generic goals and practices for capability levels 1, 4, and 5 are not used in the maturity level definitions—no process areas are staged at level 1, and the generic goals for capability levels 4 and 5 are addressed by the specific goals and practices of the four process areas staged at maturity levels 4 and 5.
Note that maturity level 1 has a different name (Initial) from that assigned to capability level 1 (Performed). In the staged representation, ML 1 is similar to CL 0 in its negative connotation; that is, an organization at ML 1 is one that has not yet reached ML 2. No goals need to be met to qualify for ML 1. Unlike CL 1, ML 1 does not connote any significant achievement for an organization.
Figure 6-4 shows the structure of a maturity level. In the staged representation, each process area exists at a maturity level. The process areas required for each staged level were shown in Chapter 5. In Chapter 7, we will describe each of the process areas in detail.
In Sections 6.1 and 6.2, we saw how generic goals and practices are used to define both capability levels and maturity levels. The continuous representation includes 17 generic practices grouped by capability levels 1 through 5. As stated earlier, only the capability level 2 and 3 generic practices are included in the staged representation. This section takes a more detailed look at the full set of generic practices used in the continuous representation. Section 6.4 scrutinizes the partial set of generic practices used in the staged representation.
Capability level 0 does not have any generic practices. It is the Not Performed level, which means that one or more of the specific goals for a process area are not satisfied.
Table 6-2 shows the single generic practice for capability level 1. When GP 1.1 is applied to a process area, the specific practices of the process area are performed. Although version 1.1 of the CMMI model included both base and advanced specific practices, version 1.2 does not include advanced specific practices.
Table 6-3 shows the generic practices for capability level 2.
Table 6-3. Generic Practices from Capability Level 2
Name | Generic Practice |
|---|---|
GP 2.1 Establish an Organizational Policy | Establish and maintain an organizational policy for planning and performing the process. |
GP 2.2 Plan the Process | Establish and maintain the plan for performing the process. |
GP 2.3 Provide Resources | Provide adequate resources for performing the process, developing the work products, and providing the services of the process. |
GP 2.4 Assign Responsibility | Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process. |
GP 2.5 Train People | Train the people performing or supporting the process as needed. |
GP 2.6 Manage Configurations | Place designated work products of the process under appropriate levels of configuration control. |
GP 2.7 Identify and Involve Relevant Stakeholders | Identify and involve the relevant stakeholders as planned. |
GP 2.8 Monitor and Control the Process | Monitor and control the process against the plan for performing the process and take appropriate corrective action. |
GP 2.9 Objectively Evaluate Adherence | Objectively evaluate adherence of the process against its process description, standards, and procedures, and address noncompliance. |
GP 2.10 Review Status with Higher-Level Management | Review the activities, status, and results of the process with higher-level management and resolve issues. |
GP 2.1 establishes an organizational policy that requires planning and execution of the process area. Organizational policies need not be labeled with the term “policy,” but senior management sponsorship must be documented in a manner that requires planning and the use of the processes associated with the process area.
Implementing GP 2.2 establishes the requirements and objectives for the processes associated with the process area, and it forms the basis for process planning. This GP has five subpractices that provide information on how this feat could be accomplished, dealing with management sponsorship, documenting the process, planning for performing the process, reviewing the process with relevant stakeholders, and revising the process as necessary.
This “Plan the Process” generic practice can create confusion when it is applied to the Project Planning process area, as it seems to entail a need to “plan the plan.” This result is actually the desired one; the planning of the activities for the Project Planning process area is a logical and necessary set of tasks in any project. The process for planning a project is one that, like any other process, should be planned.[5]
Another potential source of confusion is the fact that some process areas include a goal or specific practices to establish a strategy or a particular plan. This concept differs from the GP 2.2, in that a specific practice for planning will address detailed product or product component strategies and plans—not planning across the full scope of process area activities. For example, in the Risk Management process area, SP 1.3 establishes and maintains the strategy to be used for risk management and SP 3.1 develops risk mitigation plans for the most important risks to the project. In contrast, the generic practice expects that both of these activities will be planned, along with the other risk management practices.
GP 2.3 is a favorite of all project and program managers. When applied to a process area, it ensures that adequate resources are allocated for carrying out the processes associated with the process area. This practice includes the resources required to develop the work products of the process area and provide the services associated with the process, as well as the need for funding, facilities, people, and tools.
When a project applies GP 2.4 to a process area, responsibility and authority are assigned to perform the processes associated with that area. The three subpractices cover assigning responsibility for personnel who are in charge of the process as well as workers who perform the tasks of the process, and confirming that those individuals understand their responsibilities.
The focus of GP 2.5 is ensuring that process participants are adequately trained. This generic practice includes training of the people who will perform and support the process so that they understand the process sufficiently to perform or support it. The Organizational Training process area provides guidance on how to develop an organizational training program that supports GP 2.5. The generic practice and the process area differ, however, in that the process area provides training practices at the organizational level whereas the generic practice addresses training for each process. Of course, a project may choose to rely on organizational training assets to the extent that they are available.
When a project applies GP 2.6 to a process area, it ensures that the appropriate level of configuration management is maintained for the process work products. Formal configuration management may or may not be expected, and a work product may be subject to different levels of configuration management at different points in time. The Configuration Management process area provides the specific practices needed to manage the selected work products for each project-related process area.
GP 2.7 includes the expectation that all of the affected entities will be involved in the process. The relevant stakeholders are specifically identified and drawn into the process associated with the process area.[6] The three subpractices identify stakeholders, let project planners know who these stakeholders are, and get the stakeholders involved.
GP 2.8 ensures that the process activities are monitored relative to the plan (which was defined in GP 2.2) for executing the process and that corrective actions are taken when necessary. Its seven subpractices provide more detailed information on how to monitor and control processes. The Project Monitoring and Control process area supports this generic practice by providing specific goals and practices for monitoring and taking corrective actions.
Objective evaluation of process and work product performance is provided to a process area through GP 2.9. While a quality assurance group or department may be used to perform the evaluations, the CMMI does not assume any particular organizational structure. Note, however, that people who are not directly responsible for managing or performing the process should perform the evaluation to enhance objectivity. The Process and Product Quality Assurance process area supports this generic practice by providing guidance on how to accomplish objective evaluations.
When a project applies GP 2.10 to a process area, its higher-level management will review the activities, status, and results of the process and resolve any outstanding issues with the process performance. Each level of management may have its own needs for information about the process performance. The reviews should be both periodic and event driven.
Table 6-4 shows the generic practices for capability level 3.
Table 6-4. Generic Practices from Capability Level 3
Name | Generic Practice |
|---|---|
GP 3.1 Establish a Defined Process | Establish and maintain the description of a defined process. |
GP 3.2 Collect Improvement Information | Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization’s processes and process assets. |
GP 3.1 supports the institutionalization of processes by expecting that projects will establish and maintain a defined process tailored from the organization’s standard processes. Defined processes may be established for a project or an organizational group; although various parts of the organization may have different defined processes, all will be based on the standard processes. This tailoring provides flexibility to companies that have similar units that are organized differently, while ensuring that the standard processes remain truly standard across the enterprise.
GP 3.1 has five subpractices that support the establishment of the defined process associated with the process area. The Organizational Process Definition process area supports GP 3.1 by providing specific goals and practices related to the establishment of standard processes. The Integrated Project Management process area is also closely related to this generic practice. The notes in the model on individual specific practices offer more information on the use of these processes in an organization.
GP 3.2 serves as a key to further process improvement, because it expects the organization to collect example work products, measures, and other data about the process for future use. Without such historical data, the process may be difficult to plan and impossible to manage quantitatively—the focus of CL 4. Three of the subpractices within GP 3.2 provide information on the contents of the process library; the fourth subpractice captures proposed improvements to the process assets. The Organizational Process Focus process area supports this generic practice by addressing process asset deployment and incorporating process-related experiences into the organizational process assets.
Table 6-5 shows the generic practices for capability level 4.
Table 6-5. Generic Practices from Capability Level 4
Name | Generic Practice |
|---|---|
GP 4.1 Establish Quality Objectives | Establish and maintain quantitative objectives for the process that address quality and process performance based on customer needs and business objectives. |
GP 4.2 Stabilize Subprocess Performance | Stabilize the performance of one or more subprocesses to determine the ability of the process to achieve the established quantitative quality and process-performance objectives. |
GP 4.1 expects an organization to use its business objectives to define process performance and quality objectives. All relevant stakeholders should participate in this activity. Once established, the quantitative objectives are allocated to the processes. These processes may be related to process areas or to a set of process areas. The Quantitative Project Management (QPM) process area encompasses quantitatively managing processes, so the information in that area is extremely useful in implementing GP 4.1, especially in project-related process areas.
In implementing GP 4.2, the organization uses the quality and process performance objectives to statistically manage selected subprocesses. A strong rationale for choosing the particular subprocesses should exist, and the organization needs to demonstrate how those subprocesses are managed to meet the intent of the generic practice. The Quantitative Project Management process area also supports this generic practice.
Table 6-6 shows the generic practices for capability level 5.
Table 6-6. Generic Practices from Capability Level 5
Name | Generic Practice |
|---|---|
GP 5.1 Ensure Continuous Process Improvement | Ensure continuous improvement of the process in fulfilling the relevant business objectives of the organization. |
GP 5.2 Correct Common Cause of Problems | Identify and correct the root causes of defects and other problems in the process. |
Implementing GP 5.1 drives the organization to select and deploy process and technology improvements that contribute to its ability to meet quality and performance objectives for the process. The Organizational Innovation and Deployment process area provides more information in terms of goals and practices regarding ways to implement this generic practice.
The root causes of defects in the process are identified and corrected through application of GP 5.2.[7] Without this practice, organizations would find it difficult to gain the agility needed to rapidly solve problems and effectively evolve their processes. Goals and practices that can be applied in implementing GP 5.2 appear in the Causal Analysis and Resolution process area.
The maturity dimension is used in the staged representation for the CMMI model. As discussed in Section 6.2, only the generic goals and practices from capability levels 2 and 3 are used in establishing the maturity dimension. Within this dimension, the generic practices have the exact same meaning that they have in the capability dimension.
Users of staged models often have difficulty in understanding how a continuous model measures organizational progress. When one is accustomed to a model in which process areas build on one another, it is not always obvious how possibly unrelated process areas might be improved without some kind of staging. Users may also wonder when work should be carried out in a particular process area. Although staged models do not explicitly prohibit addressing higher-level key process areas before lower-level ones, they imply that this sequence should not be the normal way of proceeding. In continuous models, of course, this implication would be meaningless.
The following example may help explain how an ML 4 process area fits into the capability level used in the CMMI model. Quantitative Project Management is an ML 4 process area. Obviously, it doesn’t make sense for an organization to start its process improvement journey with this particular process area. In fact, cautionary statements in the Introductory Notes section of the process area specifically warn against taking this approach. The continuous representation, however, does not dictate the time or the state that must be reached before delving into this—or any other—process area.
When an organization initially establishes a QPM process, it may be rated at CL 1. By adding generic goals and practices, it may improve its capability to CL 5 if deemed appropriate by the organization. In contrast, strict adherence to the staging in the staged representation would not implement QPM until ML 3 has been implemented.[8] The bottom line is that the two means of achieving the advanced capability are striving for the same objective: quantitatively managed processes.
[1] At some point in our description of the two CMMI architectural representations, you may ask, “Which representation should I use?” When that point comes, you may wish to turn to Chapter 8, which covers picking a representation. In Chapter 6, we focus on building a good understanding of these structures and their implementation in CMMI.
[2] It is highly recommended that when describing an organization’s capability as “zero” that the words “not yet level 1” be substituted—no one wants to be considered as being at level 0.
[3] This example assumes the process area considered is a project-related process area—that is, from the Project Management process area category.
[4] Usually, each instance of the process is associated with a project.
[5] Only one level of “recursion” exists. Nothing in the model requires you to “plan to plan the plan.”
[6] A relevant stakeholder is a person or role that is affected by or held accountable for a process outcome, and whose involvement in a particular activity is planned.
[7] The concept of a root cause is frequently misunderstood. Clearly, it is not a cause for which no preceding cause exists; only a god or the “big bang” would be a candidate to meet that definition. Rather, a root cause is an antecedent cause of a problem or defect such that, if it were removed, the problem or defect would be lessened or eliminated. Do not confuse a possible solution that may address a root cause with the root cause itself. In other words, avoid characterizing a root cause with a negative formulation such as “Solution A to the problem was not implemented” or “There was a lack of A.” Think of a cause as something that was present, not something that was absent.
[8] In EIA 731, the practices in QPM are addressed as advanced practices in other focus areas.