Since 1991, Capability Maturity Models^® (CMM^®) have been developed for a variety of disciplines, including systems engineering, software engineering, software acquisition, work-force practices, and integrated product and process development. These models have been valuable to many organizations; however, the use of multiple models has been expensive and complicated. Organizations that want to pursue process improvement across disciplines have had to cope with differences in model architecture, content, and approach. These differences have limited these organizations' ability to focus their improvement successfully. Applying multiple models that are not integrated is costly in terms of training, assessments, and improvement activities.

The Capability Maturity Model^® Integration^SM (CMMI^SM) project was initiated to address these problems. Figure 1 shows how integrating material into the CMMI models adds up as you compare the number of model elements in discipline-specific models to those in CMMI models.


Figure 1: Model Measures
(Click on image above to show full-size version in pop-up window.)

CMMI is sponsored by the U.S. Department of Defense Office of the Under Secretary of Defense, Acquisition, Technology, and Logistics and the Systems Engineering Committee of the National Defense Industrial Association. The CMMI project has been developing a product suite, including CMMI models, appraisal method, and training, since 1998. Version 1.0 (V1.0) was released in August 2000 and Version 1.1 (V1.1) was released in January 2002. During the next few years, V1.1 will remain stable. No updates are planned for the next three years.

The experience gained in launching the Software CMM (SW-CMM^®) in the early 1990's led the CMMI project to move fairly quickly from a V1.0 to a V1.1. We felt we had an initial operating capability with V1.0, but needed to commit resources to reach a final operating capability of the baseline models. This approach drove the decision to have a formal public review period early in 2001 to gather initial user input. This was then coupled with a second phase of pilots using the model before publishing updates of the CMMI models and the Standard CMMI^SM Appraisal Method for Process Improvement (SCAMPI^SM) method.

We created a Change Control Board (CCB) populated with experts from across government and industry as well as the Software Engineering Institute (SEI). Guidelines were established to limit V1.1 changes to those addressing change requests (CRs) that identified elements that were "broken." This meant that we would not restructure the model, nor add material for new elements beyond those in V1.0. CRs that called for new process areas or combining process areas were deferred because they would result in more change than we wished to see for V1.1.

Probably the most controversial decision made for V1.1 was to maintain two representations, or architectures, of the CMMI model [1]. The systems engineering and software engineering communities that had grown accustomed to two contrasting architectures for their respective discipline-specific models felt it best to maintain both the continuous representation from the Electronic Industries Alliance/Interim Standard (EIA/IS) 731 heritage and the staged representation from the SW-CMM heritage [2]. As the CMMI models have evolved, the model content has remained consistent for both continuous and staged representations.

Stability of the CMMI Product Suite refers to maintaining essential content and structure while evolving the products to improve quality. We knew this theme was critical to users considering transition so they would have a relatively unchanging product for building their transition plans [3]. We knew that early users of the CMMI Product Suite would uncover some need for clarifications and improvements [4]. However, we gained confidence from comments during later pilot tests that the V1.0 material was, in fact, ready for operational use. Therefore, to promote transition and to preserve the investment of early adopters, the decision was made to focus V1.1 changes primarily on corrections of errors and essential clarifications that were designed to avoid confusion. The multi-organizational CCB has helped maintain an approach that honors requests for clarification with minimal impact to the "required" and "expected" elements of CMMI models.

CMMI stability could have been fully preserved by making no changes to the product suite after the CMMI V1.0 release, but usability considerations dictated otherwise. The CRs confirmed what we suspected -- a group of authors from various backgrounds and environments writing documents for users with various backgrounds and environments used words and phrases that sometimes needed to be clarified. Without that clarification, process improvement groups and appraisal teams may spend valuable time on interpretation that would clearly be better spent on improvement or its validation. We found that every process area had some room for such improvement. Some process areas such as Process and Product Quality Assurance had relatively few deficiencies. Others, particularly those that reflected more cross-discipline integration, showed a greater need for explanatory statements. Clarifications have improved the usability of the model without adversely affecting its stability.

The initial CR reviews brought confidence that most corrections could be made in informative material, rather than across the required and expected elements of the model. In the end, only one goal was deleted by a restructuring of the Organizational Process Definition process area. Three other goals have been changed or clarified: one each in the Organizational Training, Technical Solution, and Product Integration process areas. At the practice level, about 10 percent had wording clarifications, and two practices were deleted.

The V1.1 models have retained the same process areas. Further, these process areas belong to the same process area categories as V1.0 of the continuous representation, and to the same maturity levels as V1.0 of the staged representation. Figure 2 shows a high-level summary of V1.1 process areas and their position in each representation.


Figure 2: CMMI Process Areas
(Click on image above to show full-size version in pop-up window.)

Most of the changes have focused on assuring that key terms are used consistently throughout all the models. "Process capability" is a typical example. The term has a specific meaning for experts in statistical process control, but it often seemed appropriate to describe improvements in the capability dimension of the continuous representation. In V1.1, only the statistical meaning is used. Similar clarifications were provided for terms such as "life cycle," "process," and "process area."

Relationships across the engineering process areas were clarified. Of note was the elimination of the overlap between "make-or-buy" analysis in the Technical Solution and Supplier Agreement Management process areas. Greater attention to architectural analysis and design was requested in CRs, and an enhanced specific practice addressed this area.

Generic practice (GP) content was strengthened for V1.1. Improved elaborations are now provided for "Plan the Process" (GP 2.2), "Provide Resources" (GP 2.3), and "Monitor and Control the Process" (GP 2.8). Model authors also clarified the relationship of several of the GPs to their associated process areas based on feedback from some of the pilot appraisals using the continuous representation.

Some terms were replaced with more appropriate substitutes. "Capture" was replaced with "document" or "record." "Process capability model" was replaced, where appropriate, with "process performance model." And, as will be evident in the following section, we replaced the term "assessment" with "appraisal" as appropriate.

One of the significant additions to CMMI V1.1 is a single, common method for external evaluations as well as internal appraisals for process improvement. Because of the strong correlation of the Software Capability Evaluation (SCESM) V3.0 with the familiar CMM-Based Appraisal for Internal Process Improvement, the SCE was chosen as a source document for the new CMMI Method Description Document. A separate implementation guide for source selection and contract monitoring will also be provided to describe the unique characteristics of an appraisal when this kind of external use is planned.

The other key effort that the appraisal team undertook was to apply "lessons learned" from the community. Two key concepts are now part of the V1.1 release. First, the idea of "triage" has been more explicitly described. This description has the appraisal team focusing more of their attention on the areas of greater uncertainty and moving quickly through the process areas where clear evidence has been delivered. Second, when conducting an appraisal, the appraisal team will clearly expect that the appraised organization has done its homework to prepare for the visit. The materials provided by the appraised organization will be used from the beginning of the appraisal, so that the appraisal team's effort shifts from a "discovery" approach to a "verify and validate" approach. Pilot use of these approaches has shown marked improvement in the time required to assure goal satisfaction.

Because most of the changes to the model approved for V1.1 are in the informative material, few changes will be required to the training slides for CMMI courses [5]. More significant is the work required to assure that all of the instructors of the revised material understand the clarifications that were made so that they can effectively teach the revised material. We do not envision any need to provide "delta" training to those who have taken the V1.0 courses. Those who have attended V1.0 courses may wish to print a copy of the model version comparison document we have provided. The Word document with redlines can be found in the "CMMI Models" section of the CMMI Web site www.sei.cmu.edu/cmmi/.

In October 2000, a call for participation was issued for the Phase II Pilot Program to gather experiences using V1.0. Eight pilot tests were conducted. The appraisal method used was SCAMPI V1.0 with some experimental variations intended to improve the efficiency of the method. Phase II pilots included observers from the CMMI project who collected measurements to gauge progress against the defined appraisal goal of 100 hours. Observers used this goal, 100 hours or 5.7 hours per process area, for the on-site period of a SCAMPI appraisal using the CMMI model for Systems Engineering and Software Engineering (CMMISE/SW), with the 18 process areas that define Target Profile 3 or, equivalently, Maturity Level 3.

Across the eight pilot appraisals, an average of 5.3 hours per process area during the on-site period was achieved against the objective of 5.7 hours per process area. In particular, SCAMPI pilots using improved data gathering with validating interviews achieved 5.0 hours per process area. This method, involving additional pre-on-site review of objective evidence, has been included as an improved technique in SCAMPI V1.1.

Other pilot test results reinforced previously known best practices for appraisal conduct. In particular, the importance of appraisal preparation, model training, and in-depth model comprehension by the appraisal team cannot be overemphasized. Given the newness of the CMMI models and appraisal method, no one had vast amounts of experience with their use. However, those with a working knowledge attained from prior appraisals or transition experience (e.g., mapping of the model to command media) were more adept at applying the model during a SCAMPI.

The CMMI Product Suite is intended to gradually replace the SW-CMM and EIA/IS-731. The approaches being taken to sunset these two models are consistent.

The SEI plans no further updates to the SW-CMM model, appraisal methods, and training. After December 2003, the SEI will no longer provide public offerings of "Introduction to SW-CMM" training, although the SEI and SW-CMM transition partners may continue to deliver the training to select organizations. Also after December 2003, SW-CMM appraiser and evaluator training will no longer be offered. Therefore, active SW-CMM appraisers and evaluators will need to transition to CMMI SCAMPI appraiser status by December 2005. SCAMPI will then be the appraisal method of choice.

The Government Electronic Industry Association G-47 committee, the originator of EIA/IS 731, has taken a similar approach. No further updates are planned for this interim standard. The Interim Status has been renewed to cover the transition period while the CMMI Product Suite is being adopted, but no further extensions are currently envisioned.

The year 2001 has been a remarkable year for the CMMI Product Suite. The improvement to the product suite from reviews and rewrites will be obvious to the using community as it begins reading and using CMMI materials. Now we look forward to working with you to ease adoption of this even better model that builds upon and integrates the firm process improvement framework of the legacy models.

1. Shrum, S. "Choosing a CMMI Model Representation," www.stsc.hill.af.mil/crosstalk/2000/07/shrum.html, Jul. 2001.
2. SEI. Capability Maturity Model^® (SW-CMM^®) for Software, www.sei.cmu.edu/cmm, Sept. 2001a.
3. SEI. CMMI^SM Publications and Transition Materials, www.sei.cmu.edu/cmmi/publications/pubs.html, Sept. 2001f.
4. SEI. CMMI^SM Product Suite, www.sei.cmu.edu/cmmi/products/products.html, Sept. 2001e.
5. SEI. Education and Training Courses, www.sei.cmu.edu/products/courses/courses.html, Sept. 2001d.

1. SEI. Systems Engineering Capability Maturity Model^®, www.sei.cmu.edu/cmm/se-cmm.html, Sept. 2001b.
2. SEI. CMMI^SM Tutorial, www.sei.cmu.edu/cmmi/publications/stc.presentations/tutorial.html, Sept. 2001c.
3. SEI. Software Engineering Information Repository, http://seir.sei.cmu.edu, Sept. 2001g.
4. SEI. Technology Adoption, www.sei.cmu.edu/adopting/adopting.html, Oct. 2001h.
5. SEI. "Bibliography on Integrated Product and Process Development," www.sei.cmu.edu/cmmi/publications/ippd-biblio.html, Nov. 2001i.

Mike Phillips is director of Special Projects at the Software Engineering Institute (SEI), a position created to lead the Capability Maturity Model^® Integration^SM project for the SEI and the steering group. He was previously responsible for transition enabling activities at the SEI. Prior to his retirement as a colonel from the Air Force, he managed the $36 billion development program for the B-2 in the B-2 Special Programs Office and commanded the 4950th Test Wing at Wright-Patterson AFB, Ohio. Phillips has a bachelor's degree from the Air Force Academy, and master's degrees from Georgia Tech, from the University of Southern California, and from Salve Regina College and the Naval War College.

4500 Fifth Ave.
Pittsburgh, PA 15213
Phone: (412) 268-5884
Fax: (412) 268-5758
E-mail: dmp@sei.cmu.edu

^® Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office.
^SM CMMI, CMM Integration, SCAMPI, SCAMPI Lead Assessor, and SCE are service marks of Carnegie Mellon University.

CrossTalk's parent organization, the Software Technology Support Center (STSC), is a technology transition partner with the Software Engineering Institute (SEI). Organizations new to software process improvement or to the CMMI can receive additional help with understanding the information from the SEI and their technology transition partners at the STSC's and other Web sites listed on page 27.