Coming soon: CMMI v1.3 for Development

August 29, 2010

1      Overview

In a couple of months, CMMI v1.3 will become a reality. This is a welcome development for many as it aims at standardizing the model, incorporating the variations that currently exist between the three different CMMI “constellations” (development, acquisition and services). It also clarifies and (possibly) rationalizes some of the high-maturity practices which in the past have cause problems with interpretation and implementation.

For high-maturity organizations (maturity levels 4 and 5), this is a major evolution as the requirements change significantly from version 1.2 of the product. But, what about the organizations at maturity levels 1, 2 and 3? Appraisals based on the current version (1.2) can continue to be used for twelve months following the release of the new version, and will be valid, as all appraisals, for a period of three years. So, theoretically, this only becomes a major roadblock by the third quarter of 2014. However, the question can be asked now as to whether you want to make the jump to the new version and be one of the early adopters, or let things continue as they are for a while…

I would like to discuss here the differences regarding the most popular version of CMMI: the CMMI-DEV or “CMMI for Development” constellation, at “lower” maturity levels. The lower maturity levels generally focus on the implementation of a manner in which best practices in the organization can be identified and shared in order to repeat successes and learnt from failure.

2      Additional Practices and Expectations

The concepts of IPPD have been moved from being a model addition to be integrated in the core of the model. While this means that IPPD is no longer something optional, it has also been downgraded again into something less meaningful. The original concepts were found in a separate model, within CMMI v1.1, they were inserted into the model as a series of additional process areas that could be included or not. In v1.2, the process areas were downgraded to goals and the goals to practices, while remaining as an optional addition to the model.

In v1.3, IPPD has been taken away as an addition and included in the core of the model. At the same time, the (required) goals have been downgraded to (expected) practices and the (expected) practices have been classified as (informative) sub-practices. The “integrated teams” have been replaced with “teams”. As a consequence, while it may appear that IPPD is now part of the core model, the fundamental concepts that made the strengths and usefulness of the IPPD approach have been so watered down and dissolved that very little usefulness remains. Basically, all that remains is that you should have teams working together.

I do not believe that this should have any impact on any organization moving from v1.2 to v1.3.

3      General and Cosmetic Changes

A number of changes have been included in the new version which should have no impact on the result or the implementation. This includes changing terms like “typical work products” to “example work products” – which may clarify that you are not expected to produce all the products listed, but that these are included to help understand what the practice is referring to and what products one should expect.

Amplifications have been removed from the model. These were examples and clarifications of practices for organizations or teams that focused specifically on engineering software, hardware or systems. In version 1.2, it was considered an improvement to extend the amplifications to include hardware specific aspects; in version 1.3, it is considered an improvement to simplify the model by removing them…

Other clarifications and simplifications include distinguishing product lifecycles from project lifecycles, replacing “work products, measurements and improvement information” with “experience”, updating the glossary and more.

Some new material has been included in the model, this includes references to agile methodologies and architecture-centric development, the notions products, systems of systems, release increments and quality attributes and the long awaited and much needed reference to customer satisfaction.

Some minor changes to the changes to the generic practices include clarification of terms in a few areas. The most noticeable changes in this area are the removal of the high-maturity goals and practices (GG4 and GG5) and the fact that all the generic goals and practices have been consolidated into a single section of the documentation.

This latter change is (in my opinion), the unsatisfactory choice between the three possibilities that were present in the v1.2 constellations: CMMI for Development had the description of the generic goals and practices consolidated at the beginning of section 2, with examples of what this means and amplifications included in each process area; CMMI for Acquisition removed all examples and amplifications from the process areas, leaving the description of the practices grouped together at the beginning of section 2 of the model; CMMI for Services had the layout that has been maintained with each description completed with a long list of additions and clarifications for all the process areas. A consequence of this approach is that it becomes a lot more difficult to find the information within this list of examples which can reach several pages for each practice.

The process area called IPM (Integrated Project Management) has been renamed to IWM (Integrated Work Management).

4      What has not been included

A number of expected improvements have finally not been included in the model:

Requirements development (RD) was to be moved to maturity level 2, which would have been more logical, in line with the reality of most engineering organizations and coherent with the other constellations. This appears to have been dropped.

The project strategy was a welcome addition to project planning activities in both CMMI for acquisition and for services (even though it was unfortunately included in the estimating activities rather than in the planning activities), this has not been included in CMMI for development, leaving the numbering of the identical practices to differ between the constellations for what is supposed to be a shared process area.

I have long been hoping for a reinforcement of the peer review practices. I do not believe that these are given appropriate weight as a goal within the verification: peer reviews can be used for validation purposes as well as for verification, peer reviews are one manner for V&V and should not be a required goal separate from performing verification activities. The description of the reviews is too light to be of any use and I would like them to be expanded into a full process area (at maturity level 3) and included as a generic practice, ensuring that key products in all process areas are reviewed. This will not (yet?) be happening in this release of the product. I understand that there are number of people who would want to see reviews removed completely from the model as they have not understood their potential value. I will file another change request on the same subject, in the hope that it will be read this time around.

A proposal was originally made that some key high-maturity practices, like causal analysis, should be included at lower maturity levels, in a simplified manner. These have been discarded.

5      Conclusion

The value of moving from v1.2 to v1.3 of the model at lower maturity levels is certainly minimal at best. This release does not really correct any weaknesses in the lower maturity levels as the changes are largely purely cosmetic. Few organizations will want to make the investment of upgrading to the new version until they have to perform a reappraisal. The value of being “one of the first appraised in the new structure” may have some interest from an advertising point of view, but the expense and effort to upgrade, get the new training, etc. may dissuade most.

I do not believe that CMMI-DEV v1.3 will significantly revitalize the process improvement industry.

CMMI is a registered trademark of Carnegie Mellon University, Pittsburgh PA, USA



  1. Peter,

    Just a quick correction, IPM has been changed to IWM (Integrated Work Management) in the CMMI-SVC constellation only. In the CMMI-DEV, it will continue to be called IPM (Integrated Project Management).



  2. Indeed – thanks for that correction, Pat.

  3. Really an awesome post to refer, many organizations committed to excellence do great work in Spanish, here is some more information regarding CMMI @ KPMG International

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: