Chapter 4
CMMI As Your Guide

Because the title of this tome is CMMI Survival Guide, it is obvious that we believe CMMI is an important and useful tool for process improvement. Putting its name recognition and support infrastructure aside, it is the most flexible and most widely useful of all the improvement models we’ve worked with. In this chapter, we discuss some of the characteristics of CMMI that lead us to this opinion. If you’ve already chosen a model other than CMMI, you can skip this chapter.

4.1 Why Cmmi?

To begin, we provide a defense of our preference for CMMI (other than Rich’s having been one of the authors). Essentially, we have confidence in CMMI’s historical foundations and are satisfied that its scope meets the needs of many, if not most, organizations.

4.1.1 Pedigree

CMMI is the latest in a line of development-oriented models. It draws on the initial work that led to the CMM for Software, which goes back to at least 1985, but also includes ideas from several other sources. It was developed by a team of more than 200 authors, reviewers, and analysts over a period of 2 years. Mark Schaeffer in the U.S. Office of the Secretary of Defense began the CMMI project as a response to the growing concern about the proliferation of models being used within the defense community. He chartered SEI and a team from industry, government, and academia to bring as wide a perspective as possible to the development of an integrated, extensible process improvement framework. Drafts and versions were put out for review to the entire process improvement community, and thousands of comments were received, considered, and processed.

The CMMI project had both initial and longer-term objectives. The initial objective (which was achieved in 2000 with the release of version 1.0 of the CMMI-SE/SW and CMMI-SE/SW/IPPD models) was to integrate three specific process improvement models: software, systems engineering, and integrated process and product development.^†

† For version 1.1 of CMMI, the designation CMMI-SE/SW stands for the CMMI model that contains the disciplines of systems engineering and software, whereas the designation CMMI-SE/SW/IPPD stands for the model that adds to it the materials for integrated process and product development.

The longer-term objective was to lay a foundation for the potential future addition of other disciplines (such as acquisition and services) into CMMI. With the release of version 1.2 of CMMI-DEV (CMMI for Product Development, which encompasses all the content of the former CMMI-SE/SW/IPPD/SS), and the constellations for acquisition and services that will follow soon, these objectives are on their way to fulfillment as well.

CMMI is not a de jure standard (one that is released by an acknowledged national or international standards organization) in the same sense as ANSI/ISO standards. The level of adoption it has achieved, however, has put it in the category of a de facto standard (one that is generally accepted and used even though it is not released by an official national or international standards organization).

4.1.2 Process Coverage

Figure 4-1, used as part of CMMI introductory training, provides an idea of the scope of the topics covered by CMMI-DEV in terms of the aspects of an organization’s work.¹

1. Garcia, Suzanne. “Standardization as an Adoption Enabler for Project Management Practice.” In IEEE Software, vol. 22, no. 5, pp. 22–29.

The current configuration of CMMI primarily focuses on product development as “the work” of the organization, so people trying to use it to improve their financial accounting practices probably would find interpretation to be challenging. Work is going on at the SEI to incorporate other aspects of organizational work into the CMMI framework, however. Right now, a Services constellation (the term being used for the clustering of model elements related to a particular focus) and an Acquisition constellation are being designed, in addition to the existing Product Development constellation.

Figure 4-1: The work areas of an organization supported by CMMI

Regardless of the constellation, you can see from Figure 4-1 that the CMMI perspective is that “doing the work” is only one part of what goes on in an organization. For the organization to be successful doing the work, the other elements shown in the diagram also need to function appropriately. The model’s practices are meant to provide useful guidance for performing, supporting, managing, and improving the work being done in the organization.

4.2 Cmmi Primer

The CMMI Product Suite contains an enormous amount of information and guidance to help an organization improve its processes. But how does this information help? To answer this question, we start by noting that essentially two kinds of materials are contained in the CMMI models:

1.   Materials to help you improve and evaluate the content of your processes—information that is essential to your technical, support, and managerial activities.

2.   Materials to help you improve process performance—information that is used to increase the capability of your organization’s activities.

We start with a brief look at each of these types. As we discuss the materials, you can refer to Table 4-1 for a list of Process Areas arranged by process category.

Table 4-1: CMMI-DEV Process Areas

4.2.1 Process Content

CMMI provides guidance for your managerial processes. For example, CMMI recommends establishing and maintaining a plan for managing your work, and ensuring that everyone involved is committed to performing and supporting the plan. That certainly seems reasonable. And when you plan, you should establish exactly how you develop and maintain cost, schedule, and product estimates. If you ever want or need to justify your estimate to a customer, you’ll find this information invaluable. When you do the work that you plan, you compare the performance and progress with the plan and take corrective actions if you find actual and planned results out of sync. CMMI provides information on managing project risk, working with suppliers, and creating and managing teams as well.

CMMI guidance on technical matters includes expectations for the basic activities in developing, elaborating, and managing requirements, as well as developing and implementing technical solutions that meet those requirements. The guidance reminds you that integrating product components depends on good interface information, and needs to be planned and verified. In today’s world, integration is one of the issues cited most often in project failure. CMMI recommends that the products and services you develop be consistent with the requirements agreed to, and that they satisfy the customer’s actual needs in its environment through verification and validation practices. If you verify only that the product works in your environment, what happens if your environment is different from your customer’s? (Nothing good, we assure you!)

Support processes for technical and managerial activities are also addressed within the model. CMMI recommends that you manage the versions and configurations of your intermediate work products, as well as end products and services. That could come in handy if you have a hard-disk crash on your favorite software development machine. You should have methods of ensuring that the processes you have defined are being followed and that the products you are developing meet the quality specifications you have established. If you didn’t think that these processes were important to the success of your project, why would you have bothered to ask people to follow them?

Measurement is another common activity CMMI addresses. You need to decide what information is important to you in making decisions. Then you need to establish ways to measure and track that information. It will greatly raise the probability of obtaining the data if you ensure that the information is also useful to the practitioners who supply it. If the information isn’t useful to the collectors, the quality of the data will never be what you expect or need, because people usually only collect data that they understand and see a use for.

CMMI draws on hundreds of years of experience when it recommends planning ways to formally resolve issues early in the project; you’re not caught having to improvise when an important conflict arises. CMMI then provides guidance on figuring out the root cause of serious problems with your products or key processes.

One characteristic often missed by newcomers to CMMI is that the PAs generally do not line up one-for-one with your processes. So don’t think you have to define a process for each PA. Your processes should be based on how you do business. CMMI provides a checklist of related critical success factors that you can compare to your process implementation to identify gaps.

4.2.2 Improving The Capability Of Your Processes

Now let’s look at improving the processes that you’ve established. The improvement information in CMMI models includes suggesting the creation of a viable, improvable process infrastructure. To build this infrastructure, CMMI includes ways to get your organization to focus more on defining and following its processes. Through training and standardization, you can make sure that everyone knows their roles and how to execute them in the process. By following CMMI practices, you learn to use the measurement data you collect effectively to improve your process performance, innovate when processes need to evolve, and ensure your ability to meet changing needs.

Processes need to be planned just like projects, and it helps if the organization has given some weight and validity to this activity through policy. CMMI recommends that you make sure that resources are available for trained, empowered people to perform the process. Those with an interest in the outcomes of a particular process need to be identified and involved. Work products and the process documentation should be controlled, and the progress against the plan for performing that process should be tracked as well. Someone should be responsible for objectively evaluating that the process is being followed, and management should be briefed periodically on the process performance.

Processes become more capable when there is enough information about project performance that they can be standardized across the organization and their performance can be monitored against historical data. This way, you can detect variation in performance early enough to address it less expensively. Ultimately, the process should be improving continuously through identifying the root causes of variability and innovative ways to fulfill its objectives. Generic Practices are the model construct used to communicate this improvement within a process. Generic Practices are arranged into a set of Generic Goals that essentially define capability and maturity levels.

If this seems a bit confusing, you are not alone. We recommend CMMI Distilled² for a more complete (and probably more understandable) discussion of this topic.

2. Ahern, Dennis, Aaron Clouse, and Richard Turner. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. 2d ed. (Boston: Addison-Wesley, 2004).

4.3 Some Choices To Think About In Using Cmmi

If you’ve decided that CMMI is the model you should (or must) use, there are some decisions about CMMI you will have to make before you dive into your process improvement effort. While many of these things are covered in other books about the model, we want to highlight a few that we feel are key.

This section focuses on several decisions we have particular opinions about. Our choices may be different from other authors’ choices, but we believe that describing them will be useful to you. These choices revolve around:

•   Which representation to use (there are two)

•   How rigorously you want or need to adopt the model

•   At what point you want to introduce Generic Practices, one of the elements of the model

4.3.1 The Staged/Continuous Choice

You will hear people advocate (sometimes passionately) for one or the other of two representations that are expressed in CMMI version 1.2. One choice is the staged representation; the other is the continuous representation. In some ways, this is more of an appraisal choice than an implementation choice because the model content is almost the same in each representation, and the place where you see the results of using one representation over the other most clearly is in appraisal results.

So if you are appraised against the staged representation, your result would be a Maturity Level rating, which could range from 1 to 5, and a set of findings and recommendations that provide more detail on where you have gaps between your Maturity Level and the next one above you. A Maturity Level is a predetermined cluster of related Process Areas that meet a specified set of goals (some specific and some generic) for that Maturity Level. Each higher Maturity Level subsumes the one(s) below it. So Maturity Level 3 includes all the goals and Process Areas associated with both Maturity Level 3 and Maturity Level 2. (There are no Process Areas or goals at Maturity Level 1.)

If you are appraised against the continuous representation, your result would be a profile chart of all the Process Areas within your improvement scope, showing the Capability Level (from 0 to 5) for each Process Area that was rated. You also would get a set of findings and recommendations that provide more detail on the gaps within each Process Area from your current Capability Level to the ones above you. Figure 4-2 shows an example Capability Level profile.

Figure 4-2: Notional CMMI Capability Profile

Even though this is primarily an appraisal choice, it can have implications for your implementation, depending on how you approach it. If you choose the staged representation as the one you work with primarily, assuming that you start your improvement at Maturity Level 1 (the default level, where anyone who hasn’t been appraised at a higher Maturity Level is assumed to be working), you would have a predetermined set of six Process Areas, mostly covering topics related to project management and support, that you would be expected to work on. You would be trying to meet the Specific Goals of each Process Area, and you would also be trying to meet the Capability Level 2 Generic Goal for each of the Process Areas.

If you choose to work primarily with the continuous representation, you would choose a set of Process Areas you want to work with initially. That set could be six, or one, or three, or ten. (Most organizations start with fewer rather than more.) You would establish which Capability Level Generic Goal you want to achieve for each one of these Process Areas, depending on some inherent dependencies in the model, as well as on your improvement goals and how they translate into Capability Levels. You could represent your set of Process Areas and your desired Capability Level for them in a profile, such as the example shown in Figure 4-3.

Figure 4-3: Target Capability Profile

It may not be obvious at first, but you can work with the two representations together, should you choose to do so. The way most organizations do this is to establish a baseline of their capability, using the continuous representation. This gives them a fair amount of detail on their strengths and weaknesses in different areas of the model. It especially helps them see something that is not apparent in a staged appraisal of a lower-maturity organization. In a staged appraisal, any Process Area that doesn’t meet the goals for Capability Level 2 is automatically assigned to Maturity Level 1, with no further elaboration of its rating. In the continuous representation, a Specific Goal for Capability Level 1 drives you to implement the Specific Practices for each PA. If you meet those specific goals, that PA is at Capability Level 1, so you know that you’re at least performing the expected practices of the PA in a basic fashion. If you do not meet the Specific Goals for a PA, that PA is rated as Capability Level 0—called the Incomplete Level, for obvious reasons! (Rich recommends referring to this level as “not yet Level 1,” because no one likes to be a zero!) So the profile for a continuous appraisal gives you more rating detail than a staged appraisal.

That detail is really helpful for the team that is implementing CMMI. More than a dozen years of experience with these kinds of models, however, shows us that many senior executives (not to mention marketing departments) prefer the shorter expression of capability expressed by a Maturity Level, and for good reason. It’s much easier to say, “Our widget organization achieved a Maturity Level 3 rating in our last appraisal” than to say, “Our widget organization is Capability Level 3 in the following Process Areas: Requirements Management, Requirements Development, Project Planning, Project Monitoring and Control, Product and Process Quality Assurance, Configuration Management, Measurement and Analysis, Organization Process Definition, Organization Process Focus, Risk Management, Decision Analysis and Resolution, Organization Training, Integrated Project Management, Technical Solution, Product Integration, Verification, and (have you taken a breath yet?) Validation.” The first of these statements actually expresses the same content as the second, but in a much more concise way. And anyone who understands even the basics of the model will understand.

So when you complete an appraisal, if your Capability Profile is suspiciously close to that of a Maturity Level, communicating your achievement with a Maturity Level makes a great deal of sense. CMMI contains an explicit concept called equivalent staging that allows you to create a series of Capability Level profiles that are equivalent to each of the Maturity Levels represented in the staged representation, so this is completely feasible. While you’re on your way to achieving one of those equivalent Maturity Levels, the Capability Profile provided by the continuous representations allows your process improvement group to see current status and plan the next steps in a richer, more detailed fashion than by using just the Maturity Level information.

One “techie” way to think of the representations is as different report views from a single database. The database content is the same no matter which view you choose; each view shows you that content in a different way. Depending on your purpose at any time, one view may be more useful than another. It’s the same with CMMI.

4.3.2 The Alternative Practices Choice

This choice revolves around how rigorously you want to use the guidance at different abstraction levels within CMMI. From an appraisal viewpoint, the required content of the model includes the statements of the Specific and Generic Goals. This means that to get a particular capability rating for a Process Area, you must achieve the Specific Goals of the Process Area and the associated Generic Goal for the Capability Level.

Most organizations achieve those goals by implementing, in their own processes, the Specific Practices associated with the Specific Goals of the Process Area and the Generic Practices associated with the Generic Goal of the Capability Level being addressed. The Specific Practices and Generic Practices are designated as expected elements of the model. What this means is that an appraiser would expect to see implementations of the practices as the way that the organization achieves the associated goals. All the other material—front matter, purpose statements, subpractices, discipline amplifications, and so on—is designated as informative. If it helps you understand or implement the model, great! If it doesn’t, don’t use it. You will not be rated against informative material of the model scope you choose in an appraisal. The SEI appraisal method associated with CMMI is called SCAMPI (Standard CMMI Appraisal Method for Process Improvement).^†

† There is a bit of fun in the acronym SCAMPI even beyond the reference to culinary delights. When defining it, the developers were intent on making a point about how the method was used. If you don’t use it for process improvement, thus removing the PI from the acronym, you’re left with nothing more than a SCAM.

The designation of expected for specific practices can be a useful convention, particularly for organizations whose size, domain, or organizational focus makes the use of a particular Specific Practice to meet a goal inappropriate. In this case, the organization may choose to implement an alternative practice as the means for implementing the goal. Where, you may ask, will you find these alternative practices? You find them in your own organization’s practices. There is no canonical set of published alternative practices.

We have observed two effects from this. First, many organizations are hesitant to use or document alternative practices because they’re afraid that their alternatives will not be judged as acceptable by an appraisal team. This can lead to ineffective implementations of model practices, which in turn leads to a reduced return for your process improvement effort. The second effect is that appraisal teams sometimes are afraid to allow a particular alternative practice because they have no “official” reference for its acceptance.

Our recommendation is that initially, while you’re still gaining confidence in your understanding of the model, implement the practices that obviously make sense for your organization. For those practices you aren’t sure about, simply attempt a reasonable implementation. Why? Because often, you will find that you get unexpected benefit from a practice you didn’t think would fit your organizational context. If, however, implementation of one of these practices turns into something unreasonable, either from an adoption-resistance viewpoint or a cost/effort viewpoint, we suggest two paths:

•   If you’re working with an authorized lead appraiser, try to get recommendations of alternative practices that may fit your situation or get an opinion on an alternative practice you’re thinking of implementing.

•   If you don’t have access to a lead appraiser, document the difficulty that you encountered in your improvement notes for that Process Area, as well as the alternative practice you came up with and why you think it meets the intent of the goal it supports.

This may seem like a lot of trouble, but four or six or nine months from now when you engage in an appraisal, having those notes at hand will make things easier and faster for both you and the appraisal team.

4.3.3 The Generic Practices Timing Choice

The last of the choices we discuss in this section is the choice of when to introduce the Generic Goals and Practices into your implementation. If you’re using the staged representation, and you’re attempting to achieve Maturity Level 2, you’ll be faced with implementing Specific Goals and Practices of six Process Areas, plus ten Generic Practices. The Generic Practices are called generic because they are expected to be applied against every Process Area within the scope of the Generic Goal they’re associated with.

For example, Generic Practice 2.1, Establish an Organizational Policy, is expected to be applied to all six of the Process Areas of Maturity Level 2. Also, remember that as you increase Maturity Levels, the goals of the previous level are subsumed or included in the goals of the current level. So all the Maturity Level 2 Generic Practices would be expected to be implemented for all the Maturity Level 3 Process Areas, as well as those of Maturity Level 2. In the Maturity Level 2 case, for the topics of Project Planning, Project Monitoring and Control, Requirements Management, Measurement and Analysis, Process and Product Quality Assurance, and Configuration Management, an appraisal team would expect to see objective evidence that these topics are appropriately discussed in the organization’s policies.

Note that you are not expected to generate a separate policy for each Process Area. That rarely makes sense. Many organizations would have one policy for Project Management that makes statements that apply to Project Planning and Project Monitoring and Control. They might also have a Corporate Quality policy that addresses some of the Measurement and Analysis coverage, as well as Product and Process Quality Assurance. And they may have another policy on Organizational Support for Projects that also applies to the rest of the Measurement and Analysis coverage, as well as coverage for Configuration Management. Coverage for the Requirements Management PA might be included in a policy called Engineering Management. On the other hand, the organization may have one policy called Project Support that covers all six Process Areas. (Obviously, there would be content in these policies besides statements related to CMMI.)

What does this discussion have to do with timing? Chances are that as you were reading it, if this is your first time dealing with CMMI, you were starting to think something like this: “Oh, no! Not only do I have to implement the practices in all these Process Areas, but I also have these other ten Generic Practices to implement across these six PAs! That’s 10 × 6 = 60 implementations! Aargh! How will I ever get to Maturity Level 2?”

Your first reaction may be “Enough, already! I’ll just start with the Maturity Level 2 Process Areas and worry about the Generic Practices later.” That’s a fairly common reaction. Understanding a little more about some of the inherent dependencies between the Process Areas and the Generic Practices, however, may help you time the addition of Generic Practices to your implementation a little more practically. Selected dependencies are elaborated in the front matter of the Chrissis, Conrad, and Shrum CMMI book.³ There is also a very good presentation on GP/Process Area relationships by Sandra Cepeda from the 2004 NDIA CMMI User’s Conference.⁴

3. Chrissis, Mary Beth, Mike Conrad, and Sandy Shrum. CMMI: Guidelines for Process Integration and Product Improvement. (Boston: Addison-Wesley, 2003).

4. Cepeda, Sandra. “Generic Practices—What Do They Really Mean?” In Proceedings of NDIA CMMI Technology & User Conference 2004, www.nida.org (NDIA, 2004).

The primary thing to note when looking at the relationship tables and elaborations in the CMMI book is that most of the Capability Level 2 Generic Practices are supported by, or are related to, a particular Process Area. The Configuration Management PA, for example, is related to Generic Practice 2.6, Manage Configurations. A practical way to approach Generic Practice implementation is to address a particular Generic Practice at the same time that you address its related Process Area. In the case of Configuration Management, when you start implementing practices related to version control, you would want to think about how you will address version control for the work products of your processes related to Project Planning, Project Monitoring and Control, and so on. When you’ve completed your overall implementation for Configuration Management, you will already have addressed the Generic Practice 2.6 implementation for your Maturity Level 2 PAs.

Although the dependencies between PAs and Generic Practices may seem complex at first, this is one of the unique elements of CMMI that, in our minds, makes it more powerful than other reference models we’ve used. When you’ve mastered the content of one of the PAs with a Generic Practice relationship, if you’ve thought explicitly about how it applies across the scope of PAs that you’re implementing, you’re already on your way to institutionalizing that set of practices. And that institutionalization aspect is what sets CMMI apart from most of the models available to support process improvement. Institutionalization is a concept that is thoroughly discussed in CMMI and in SEI materials. Fundamentally, it means that the level of adoption of a particular set of practices (in this case CMMI’s practices) is deep enough, and broad enough, that their use would continue even through organizational and leadership changes. The generic practices are the primary mechanism used within CMMI to foster institutionalization.^†

† Rich has always had problems with the use of institutionalize in referring to organizational process deployment. Where he grew up, this word meant the act of locking away a mentally ill person, and so he is confused as to the subject: processes or process improvers.

4.3.4 Cmmi Choices Summary

That’s probably as much CMMI detail as you want to know at this point in your journey. Check Chapter 15 for lots of useful references when you’re ready for them.

If you find yourself unclear on some of the issues, don’t worry—it happens to all of us. Most likely, you’ll come back to this chapter after you’ve learned more about CMMI itself. (After you go a little farther and figure out more of how the model really works, you’ll reread this chapter and say, “Of course! Why didn’t I see that the first time?”)

None of the choices we talk about in this chapter is a “one time only” choice. If you make a choice and decide after more learning that a different choice is better, by all means change your choice, and go with the one that makes more sense! Remember, in the final analysis, George Box (a 20th-century mathematician) got it right when he said, “All models are wrong, but some models are useful.” We want you to get the most utility from CMMI, even knowing that it cannot be completely right for any single organization. It is a model, after all.

4.4 Using Cmmi To Guide Your Improvement

At this point, we don’t expect you to be able to interpret how CMMI supports typical process improvement tasks. So in Table 4-2, we’ve given you a starting point. As you’re getting familiar with CMMI, you may want to refer to this table to think about how each of these tasks relates to what you’re learning about CMMI. These are not the only tasks performed as part of an improvement effort, of course, but they are a good set to start with.

The tasks are organized around the challenges that we introduced in Chapter 3, and we’ve provided a reference for you to show where you can find additional information related to that task later in the book.

When you look at the list of tasks in the table, you may be thinking—“this is a lot to do!” and you’re right—there are many tasks to do at different points in your improvement journey. The good news is, you don’t have to do all of them at once. In the next chapter, we’ll introduce you to a “lightweight” improvement life cycle that allows you to minimize your infrastructure while you’re getting started with your improvement effort. And, as you get accustomed to the rhythm of your improvement cycle, you’ll figure out which of the tasks you need to pay attention to at any one point.

In Parts 3 and 4, we’ll introduce the tasks and techniques or approaches that we’ve used to support their accomplishment. Some of these approaches are more suited to larger contexts; in those cases, we try to give you some alternatives that are more suited to smaller settings. The biggest difference in how you approach the tasks is in the “Developing Infrastructure” and “Defining Processes” categories. How you approach tasks such as creating a measurement repository will depend on how big your organization is and what kind of measurement infrastructure you already have in place. We’ll highlight some of the different approaches we’ve seen as we go through them.

Table 4-2: Task/CMMI Cross Reference

For a few of the tasks, we’ve gone into a fair bit of detail in relating the task to particular aspects of CMMI content. We’ve done this because we believe that the discussion may be helpful to you when you’re making your own interpretations of CMMI.

Table 4-2 lists at least one supporting PA for each improvement task. We bring this up for two reasons. First, using CMMI to help you define your own improvement activities helps you learn the model. Second, and just as important, it allows you to model the behavior you would like your organization to exhibit—that is, to lead by example. This table can get you started down that path.