CMMI Version 1.1: What Has Changed

S ince 1991, Capability Maturity Models ® (CMM ®) have been developed for a variety of disciplines, including systems engineering, software engineering, software acquisition, workforce 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. 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 …