If we cannot now end our differences, at least we can help make the world safe for diversity. | ||
| --John Fitzgerald Kennedy (1963) | ||
We tend to see our own experiences as the normal process, so we are often amazed that anyone could have taken a different path. But when we do meet up, it’s always fascinating to compare notes about the different ways to get there. | ||
| --Daniel Gilly, Unix in a Nutshell (1992) | ||
In previous versions of the CMMI models, the user faced a fundamental choice: Do you use the continuous representation or the staged representation? In fact, a distinct, separately published representation was available for each of these options—one for continuous and one for staged. CMMI version 1.2 brings these two representations closer together. For example, advanced practices[1] and common features,[2] both of which were in the earlier model versions, have been removed. Also, in version 1.2 a single published model contains both representations. However, one architectural feature remains that makes the two representations different: the use of generic goals and practices.[3]
The two representations exist in CMMI to provide users with multiple tools for process improvement. The key to using the model is to follow a structured approach for process improvement, and multiple ways to do this are provided. In this chapter, we address how different approaches to process improvement relate to continuous and staged representations.
An organization may choose to approach process improvement from the perspective of either process area capability or organizational maturity. Simply put, a process area capability perspective focuses on establishing baselines and measuring improvement results in each area individually. This approach is supported in a continuous representation, with its use of the key term “capability.” In contrast, an organizational maturity perspective emphasizes sets of process areas that are intended to define proven stages of process maturity across an organization. This approach is employed in a staged representation, with its use of the key term “maturity.”
A staged model provides a predefined road map for organizational improvement based on proven grouping and ordering of processes and associated organizational relationships. The term “staged” comes from the way that the model describes this road map—namely, as a series of “stages” that are called “maturity levels.” Each maturity level has a set of process areas that indicate where an organization should focus to improve its organizational process. In turn, each process area is described in terms of the practices that contribute to satisfying its goals. The practices describe the infrastructure and activities that contribute most to the effective implementation and institutionalization of the process areas. Progress occurs by satisfying the goals of all process areas in a particular maturity level.[4]
Appraisals against a staged model evaluate the organization as a whole by determining which of the process areas have been achieved—that is, how many goals have been met. Based on the satisfied process areas, the organization is assigned a single maturity level. When you hear that a corporation “is at maturity level 3,” for example, it means that the organization has conducted an appraisal and satisfied all goals associated with the process areas included in maturity levels 2 and 3 of a staged model.
Continuous models provide less specific guidance on the order in which improvement should be accomplished. These models are called continuous because they lack discrete stages and, therefore, have no concept of organizational maturity. EIA 731 is an example of a continuous model.
Like staged models, continuous models have process areas that contain practices. Unlike in staged models, however, the practices of a process area in a continuous model are organized in a manner that supports individual process area growth and improvement. Most of the practices associated with process improvement are generic; they are external to the individual process areas and apply to all process areas.[5] The generic practices are grouped into capability levels, each of which has a definition that is roughly equivalent to the definition of the maturity levels in a staged model. Process areas are improved and institutionalized by implementing the generic practices in those process areas. In a continuous model such as EIA 731, goals are not specifically stated, which puts even more emphasis on practices. The collective capability levels of all process areas determine organizational improvement, and an organization can tailor a continuous model so as to target only certain process areas for improvement. In other words, the organization can create its own “staging” of process areas.
In a continuous appraisal, each process area is rated at its own capability level. An organization will most likely have different process areas rated at different capability levels. The results of this rating can be reported as a capability profile, like that shown in Figure 5-1.
The capability profile may include just the level number ratings, as in Figure 5-2, or it may also contain detailed information at the goal or practice levels. The latter option provides more specific information in graphical form by highlighting the findings (i.e., weaknesses and strengths) with different colors. Typically, profiles are created via a spreadsheet.
Capability profiles can also be used to define a target for process improvement activities in an organization. Because a target profile shows the desired capability profile at a specific point in time, it can be used to show progress along the process improvement journey.
Another way to use capability profiles is to organize the process dimension so that it represents the staged maturity levels. For example, a series of profiles may be used to set goals for the organization or to evaluate the results of an appraisal using equivalent staging (Section 5.3.3 describes the application of this concept to CMMI). In addition, capability profiles can be defined for subsets of process areas when different parts of the organization own the processes related to them. Alternatively, the same process areas may be included in multiple owners’ target profiles. When the entire organization undergoes an appraisal, the process areas are rated as a whole.
The CMMI Team was given an unprecedented challenge: Create a single model that could be viewed from two distinct perspectives, continuous and staged. This mandate meant that each representation should include the same basic information for process improvement. As a consequence, a CMMI process appraisal that addressed the same scope should result in the same findings, no matter which model representation was used during the appraisal.
As described in Chapter 4, a major challenge centered on the selection of the process areas for CMMI.[6] A second, even thornier issue was whether the process areas in the two representations would need to be (or should be) identical.[7] The team employed a well-defined set of criteria in identifying process areas. That is, a process area was defined as containing a related set of activities that, if performed, would result in a high probability of significant improvement in the area, thereby aiding in the achievement of business objectives for the organization.[8]
For example, the inadequate definition or management of project requirements is frequently mentioned in trying to understand what went wrong in a given program. Furthermore, a set of recognized activities exists that, if performed, would go a long way toward correcting what might have gone wrong with requirements. As a consequence, it should come as no surprise that CMMI includes two process areas related to this topic: Requirements Development and Requirements Management. No debate occurs regarding whether process areas such as Requirements Development and Requirements Management would be appropriate in both a staged representation and a continuous representation. Whichever architectural representation was to be adopted for the model, both areas would be of critical importance.
But suppose that the CMMI Team had been asked to proceed differently. That is, imagine it had been asked not to develop one model with two representations, but rather a single model representation (e.g., continuous, staged, or some hybrid). It is not clear that the resultant list of process areas would have been exactly identical for each of the various possible single model representations. In other words, the process areas needed in a staged representation and the process areas needed in a continuous representation are not necessarily the same.
For example, in a staged model, the process areas exist at a single maturity level only; they do not span levels. Requirements Management is a process area staged at maturity level 2; no parts of the Requirements Management process area exist at higher maturity levels. Thus, as an organization works to achieve maturity levels 3, 4, or 5, it need not tackle additional tasks that come from the Requirements Management process area.
Of course, the organization should not ignore the maturity level 2 process areas as it moves ahead to higher maturity levels. To be an organization at maturity level 3 means (in general) that the processes used on projects are tailored from the organization’s standard set of processes. This approach includes the management of requirements; a standard set of processes should exist for handling requirements management across the organization, and individual projects should derive their specific processes for requirements management from that standard set.
In CMMI, the Integrated Project Management (IPM) process area, which is staged at maturity level 3, expects an organization to return to the process areas from maturity level 2 (such as Requirements Management) and perform them in a manner consistent with maturity level 3 expectations. In IPM, a goal for a project is to use a defined process that is tailored from the organization’s set of standard processes.
Moving from the staged representation to the continuous representation, a generic practice at capability level 3 (GP 3.1) also sets the expectation for a defined process. In Requirements Management, for example, GP 3.1 reads as follows: “Establish and maintain the description of a defined requirements management process.” By performing that practice, and the comparable generic practice in other process areas staged at maturity level 2, the organization may raise each process area to capability level 3 when viewed from the perspective of the continuous representation. The continuous representation does not require an independent mechanism (such as the first goal in IPM) to raise maturity level 2 process areas to maturity level 3. Also, if you look at IPM from a continuous viewpoint, some practices may look like they really belong (perhaps as “advanced” practices) in the Project Planning or Project Monitoring and Control process areas.[9]
We will not explore in detail all of the architectural nuances that might distinguish the two representations. Rather, we simply note that the CMMI team had a choice: allow the process areas to be different in the two representations, or keep them the same. The former option (different process areas) would have allowed for the construction of “better” or “purer” staged or continuous representations, albeit at the cost of potential confusion to those who might need to deal with two representations having different process areas. The latter option (same process areas) would enhance the sense that the two representations are really just one CMMI model with two views, albeit at the cost of potentially confusing duplication or positioning of material in the model, which would be needed to allow both representations to work. The decision was made to have the same process areas in both representations for CMMI.
The 22 process areas of CMMI for Development are presented in alphabetical order by acronym in the model. They are identified as being in one of four maturity levels in the staged representation and in one of four process categories in the continuous representation. For example, for Decision and Analysis Resolution the following is stated under the process area name: “A Support Process Area at Maturity Level 3.”
Tables 5-1 and 5-2 show the staged and continuous groupings of the process areas for CMMI for Development, respectively.
Table 5-1. Staged Groupings
Staged Grouping | Acronyms | Process Areas |
|---|---|---|
Maturity level 2 | REQM | Requirements Management |
PP | Project Planning | |
PMC | Project Monitoring and Control | |
SAM | Supplier Agreement Management | |
MA | Measurement and Analysis | |
PPQA | Process and Product Quality Assurance | |
CM | Configuration Management | |
Maturity level 3 | RD | Requirements Development |
TS | Technical Solution | |
PI | Product Integration | |
VER | Verification | |
VAL | Validation | |
OPF | Organizational Process Focus | |
OPD+IPPD | Organizational Process Definition+IPPD | |
OT | Organizational Training | |
IPM+IPPD | Integrated Project Management+IPPD | |
RSKM | Risk Management | |
DAR | Decision Analysis and Resolution | |
Maturity level 4 | OPP | Organizational Process Performance |
QPM | Quantitative Project Management | |
Maturity level 5 | OID | Organizational Innovation and Deployment |
CAR | Causal Analysis and Resolution |
Table 5-2. Continuous Groupings
Acronyms | Process Areas | |
|---|---|---|
Process Management | OPF | Organizational Process Focus |
OPD+IPPD | Organizational Process Definition+IPPD | |
OT | Organizational Training | |
OPP | Organizational Process Performance | |
OID | Organizational Innovation and Deployment | |
Project Management | PP | Project Planning |
PMC | Project Monitoring and Control | |
SAM | Supplier Agreement Management | |
IPM+IPPD | Integrated Project+IPPD Management | |
RSKM | Risk Management | |
QPM | Quantitative Project Management | |
Engineering | REQM | Requirements Management |
RD | Requirements Development | |
TS | Technical Solution | |
PI | Product Integration | |
VER | Verification | |
VAL | Validation | |
Support | CM | Configuration Management |
PPQA | Process and Product Quality Assurance | |
MA | Measurement and Analysis | |
DAR | Decision Analysis and Resolution | |
CAR | Causal Analysis and Resolution |
To reinforce the concept of one model with representations, CMMI provides a mapping to move from the continuous perspective to the staged perspective. For maturity levels 2 and 3, this concept is straightforward and easy to understand. If an organization using the continuous representation has achieved capability level 2 in the seven process areas that make up maturity level 2 (in the staged representation), then it can be said to have achieved maturity level 2 (Figure 5-2).
Similarly, if an organization using the continuous representation has achieved capability level 3 in the 7 process areas that make up maturity level 2 and the 11 process areas that make up maturity level 3 (a total of 18 process areas in CMMI for Development), then it can be said to have achieved maturity level 3 (Figure 5-3).
For maturity levels 4 and 5, a similar mechanism is not available to define an equivalent staging. For example, maturity level 4 in the staged representation does not require that the kinds of activities found in this level occur in each and every process area. Nor is quantitative management of processes or subprocesses required for any given process area. One organization that achieves maturity level 4 may conduct quantitative management in one set of areas, whereas another organization may handle quantitative management in another set of areas; there may be no overlap between the two sets, and yet both organizations may operate at maturity level 4. Thus, in Figure 5-4, we cannot highlight any particular process area as being capability level 4 and claim that it is required for an equivalent staging to maturity level 4.
Instead, to obtain an equivalent staging for maturity level 4, we require that an organization meet the goals up through capability level 3 in the process areas that are staged at maturity levels, 2, 3, and 4. This idea may sound confusing, but it is correct. Table 5-3 details the three goals of the two maturity level 4 process areas. To achieve capability level 3 in these two process areas means two things:
The three specific goals in Table 5-3 are met: The project is quantitatively managed, subprocesses are statistically managed to meet quality and process performance objectives, and baselines and models for expected process performance exist.
A defined process is used for the activities performed to achieve these goals.
Table 5-3. Maturity Level 4 Process Areas and Goals
Process Area | Specific Goals |
|---|---|
Quantitative Project Management (QPM) | SG 1: The project is quantitatively managed using quality and process-performance objectives. |
SG 2: The performance of selected subprocesses within the project’s defined process is statistically managed. | |
Organizational Process Performance (OPP) | SG 1: Baselines and models that characterize the expected process performance of the organization’s set of standard processes are established and maintained. |
These items are exactly what would need to be established for maturity level 4, based on the CMMI staged representation. Consequently, to be rated at maturity level 4, some subprocesses in some process areas must be statistically managed, but it is not possible to specify in advance which process areas are targeted. In a real-life capability profile for an organization at maturity level 4, the capability level of at least one process area would be at level 4.
The equivalent staging for maturity level 5 is handled in a similar way (Figure 5-5). In this manner, the user of the continuous representation could establish a maturity level rating, if desired, for any maturity level (1 through 5).
For CMMI, if an organization wanted to have a single-number rating of a maturity level, then it could choose a CMMI staged representation. Of course, because this equivalent staging comprises a set of four target profiles, the organization could also choose a CMMI continuous representation.
Two representations of the CMMI model have been developed: continuous and staged. With each new release of the model, the differences between these representations have dwindled to the point that there is currently little to discuss. In the next version of the CMMI Framework, this consideration will likely cease to exist altogether.
For now, however, model users need to select which version (or versions) of the model from the CMMI Product Suite they will use; we will discuss considerations related to that decision in Chapter 8. When the time comes to make a selection, the information in this chapter, which focuses on what distinguishes the two representations, should provide you with the basic understanding that you will need to make an informed choice.
[1] In the continuous representation of CMMI V1.1, advanced practices were specific practices that resided at capability levels 2 and 3. They were located in the Engineering process areas only.
[2] In the staged representation of CMMI V1.1, common features provided four groups of generic practices: commitment to perform, ability to perform, directing implementation, and verifying implementation.
[3] See Section 5.3.3 for a discussion of the use of generic goals.
[4] The concept of five stages or maturity levels goes back to Crosby in Quality Is Free, which described a five-level scale with “world-class” as level 5. Actually, Crosby’s proposed scale is closer to capability levels in a continuous model than to maturity levels in a staged model, because he applied a similar scale across many areas. Section 5.2 describes the capability levels in a continuous model.
[5] EIA 731 introduced the concept of advanced practices. These technical practices within a process area (called a focus area in 731) are associated with higher capability levels and so augment the generic practices.
[6] As discussed in Chapter 3, the CMMI Team did not start with a blank slate. Its task was not to create a new model from scratch, but rather to integrate (initially) three existing models. Each of these models already had process areas identified, and these areas made up the initial set of candidates. Team members then considered the hopes or expectations among users of the CMMI source models that process areas to which they were accustomed would remain in CMMI.
[7] In this section, we invite the reader to enter (briefly) this “briar patch”—not to share the pain (well, maybe a little), but to provide some insight. You can, of course, decline the invitation. The bottom line (which you need to know) is that the two CMMI representations have the same process areas, specific goals, and specific practices.
[8] A variety of other criteria for what makes a good process area exist, including the following: A process area tells you what to do, not how to do it or who should do it; it can be implemented in multiple organizational and product contexts; and it has sufficient cohesion and granularity to be separately implemented, rated, and improved.
[9] As we noted at the start of this chapter, all advanced practices were removed from the model in CMMI version 1.2. If and when CMMI evolves to a single representation, perhaps the potential role of advanced practices should be reexamined. They represent a powerful mechanism to enrich capability level definitions within individual process areas.