NEWS AT SEI

The CMMI Steering Group has approved criteria for the next release  of the CMMI Product Suite. This column will describe the key ingredients and  the plans for release of CMMI Version 1.3.

What is the need for another release?

In the last column, I described the need to clarify the  coverage of high maturity practices in CMMI models. Initially we created and  reviewed model updates that we felt could be released as CMMI Version 1.2A. This  version, considered a minor update, would include updates made only to informative material.¹

These model updates were reviewed by CMMI High Maturity Lead  Appraisers and the CMMI Steering Group at a workshop in late September 2008. As  a result of the review, the Steering Group determined that modernizing the  practices for maturity levels 4 and 5 was a better choice than a more limited  attempt to clarify practices by updating only informative material. So rather  than releasing a CMMI for Development V1.2A, we instead are including these and  other updates to address the coverage of high maturity practices in the planned  release of CMMI V1.3 for all three constellations—Development, Services, and  Acquisition

Over the last few months, the CMMI Product Team has reviewed  more than 1,150 change requests for the models and 850 for the appraisal  method. Teams were formed to initiate the development of CMMI Version 1.3, and  the Steering Group has provided criteria to guide the range of acceptable product  suite updates. The criteria are in Figure 1 below.

Figure 1: Steering Group Criteria for CMMI Version 1.3

So what are the major elements of Version 1.3?

High Maturity  Clarifications

  As mentioned in the previous column, a clear focus of  current model development is on clarifying the practices associated with high maturity for organizations using the  staged approach—and high capability in process areas for organizations using the continuous approach. The CMMI Product  Development Team has formed a High Maturity Team. This team’s members are focusing  on making these changes. A team lead was chosen from industry participants to ensure  that the improvements made are representative of current best practices in the  community.

The redlines produced in the effort I mentioned earlier are only  a part of the full array of change requests now available to assist this team  in its improvement effort. This team’s work focuses on the four high maturity  process areas: Organizational Process Performance (OPP), Quantitative Project  Management (QPM), Causal Analysis and Resolution (CAR), and Organizational  Innovation and Deployment (OID).

Constellation Commonality

  As we leveraged the content of the CMMI-DEV V1.2 model to  create two new constellations (Services and Acquisition), we modernized some of  the material in the 16 core process areas that are common to all three  constellations. This modernization meant that we knew we had to eventually revisit  CMMI-DEV and modernize it as well. Even though we allowed some differences between  the constellations, some of the differences can be harmonized to make the three  constellations more consistent and able to be used together.

For example, we have two different approaches to integrated  teaming in CMMI models: in CMMI-DEV, teaming is covered in two goals that are  treated as optional, or additions; in CMMI-ACQ and CMMI-SVC, teaming is covered  in two specific practices in two process areas (OPD and IPM). These practices  are expected model components and  therefore not optional. In CMMI V1.3, we will determine how best to provide  teaming information in a single approach in all three CMMI constellations. This  work to ensure commonality of the approach to teaming has gained importance  since the Team Software Process has demonstrated the performance potential of high-performing  teams.

Translations

CMMI models are now available in several different languages.  The teams that created these translations have requested that we improve the  models’ ease of translation. A simple example of changes we can make to the model  to ease its translation is eliminating the use of words such as “stovepipe,” which  is difficult to interpret into different languages appropriately because its  literal meaning is different from how we use it in CMMI models.

Expanded Coverage

A number of change requests have suggested further expansion  of CMMI models in new directions. We do not see this release as being suitable  for major expansions like the ones we had with the two recent constellations,  but we will likely add some of the current information on architecture,  software assurance, Agile, and Lean Six Sigma. We’ve also been encouraged to  add more emphasis on activities to assure customer satisfaction. These types of  expansions assist in the modernization of model coverage without adding new  process areas.

Multi-Constellation Coverage

Many students taking either of the one-day Supplement  courses that cover acquisition or service delivery have commented that many  organizations span more than one area of interest. One theme for the V1.3 release  is to enable as much sharing of best practices across the constellations as  possible. An earlier CMMI in Focus column  described our current thinking about joint appraisals. Given some effective  pilots, we plan to improve the SCAMPI Method Definition Document to facilitate  appraisals that use process areas from multiple constellations.

Appraisal Efficiency

When we modified the appraisal method associated with the  SW-CMM from its discovery focus to a verification focus, it was intended to  save appraisal time. The Practice Implementation Indicator Documents (PIIDs)  were introduced to reduce on-site appraisal time. However, if organizations are  spending excessive time preparing PIIDs, we need to examine ways of upholding  appraisal confidence without driving up preparation expenses. The SCAMPI  Upgrade Team is looking for innovative ways to achieve this goal.

Model Sizing

To meet the fourth criterion that limits the overall size of  CMMI models, we are looking for ways to balance model additions with deletions.  We received change requests resulting from an effort collecting input from  multiple lead appraisers that many of you know as ATLAS, which was sponsored by  Pat O’Toole. This group submitted change requests that identified some lower-value  practices that might be removed to add others now viewed as more important. As  mentioned above, additional process areas will not be encouraged for V1.3.   

Schedule

Given the number of change requests and the span of  contentious issues to be resolved by the teams, we have not yet decided on a  release schedule for the various elements of CMMI Version 1.3. The Steering  Group has approved our proposal to assure a significant period of overlap  between the release of CMMI Version 1.3 and the sunset of CMMI Version 1.2. We are  also investigating innovative ways of providing information about CMMI improvements  to you in draft form. However, we do not encourage you to delay process  improvement by waiting for the release of the next version.

Beta testing

Some of you reading this column may be in organizations who can use Version  1.3 development drafts (published monthly during the piloting period) and give  us feedback on proposed changes as we move through the upgrade to Version 1.3. These  monthly drafts will be available for your review and use from October 2009  through March 2010. If your organization is interested in reporting on its use  of draft versions of a CMMI Version 1.3 draft model (CMMI-DEV, CMMI-ACQ,  CMMI-SVC) during this period, contact SEI Customer Relations (info@sei.cmu.edu).  We will send you details of how you can receive the drafts and how we will be  collecting structured feedback from you.

Summary

After the release of CMMI V1.1, we began to consider future  release strategies. The Steering Group agreed that CMMI versions should be released  approximately three to five years apart to allow sufficient time for  organizations to understand and deploy healthy approaches in reasonable  improvement cycles. Version 1.2 was at the higher end of that range. Version 1.3  may be closer to the lower end. The concerns about the clarification of high  maturity practices and for commonality across the three constellations suggest  that the timing of a late 2010 release is sensible.

¹  All CMMI model components are grouped into  three categories: required, expected, and informative. Unlike the required and  expected model components, the informative model material is not considered  normative.

About the Author

As the director of special projects at the Software Engineering Institute, Mike Phillips leads the Capability Maturity Model Integration (CMMI) project for the SEI. 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 $36B development program for the B-2 in the B-2 SPO and commanded the 4950th Test Wing at Wright-Patterson AFB, Ohio. In addition to his bachelor’s degree in astronautical engineering from the U.S. Air Force Academy, Phillips has master’s degrees in nuclear engineering from Georgia Tech, in systems management from the University of Southern California, and in international affairs from Salve Regina College and the Naval War College.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.