CMMI Next Gen Dreams

The CMMI Institute is currently coordinating the creation of the next generation of CMMI, a gaggle of work groups (all volunteers) are working at defining the future of the model, so I decided to weigh in with this little rant...

What I would like to see in CMMI V2, if I was in charge?


First, I believe that the CMMI is a very good model suite and would not want to see it lose too many of its defining characteristics.


The idea of the combination of continuous and staged representations of the contents is something which I believe is very valuable and should not be discarded. Yes, we all have our preference for one or the other, which proves that both are valuable.

For me, the continuous representation is the better one for real improvement, while the staged has a valuable recognition status. Achieving a maturity level is an opportunity for an organization to celebrate the progress it made, it is a commercial and quality recognition which is recognized for what it is (even if it is often considered to be a lot more than what it really is).

The intelligent manner in which the two approaches can be combined is worth protecting like the important model asset that it is.

Generic Practices

The model is currently divided into specific and generic practices. The specific practices focus on the things that need to be done in order to build, deliver, purchase or deliver something, while the generic practices focus on the infrastructure which is necessary to allow the successful and continued implementation of the specific practices.

Not only would I want to keep that split, but I would even like to add at least one additional generic practice which I would like to see appearing in the model, and that is the practice of performing peer reviews on selected important artefacts of the process area concerned.

On the other hand, I understand the problems a number of people have with trying to prove that "higher-level management" has reviewed the process for requirements management, project planning, project monitoring and control,... Really? Do we need to repeat the same thing every time? How about bringing down the generic practices to the process categories? All the GP are to be applied to the process management, project management, engineering... process areas. Let's have one set per category, that would also explain why we have categories.


A few things which I hope to see change in the next generation.


No more constellations, just one CMMI model, which is valid for product development, product and service acquisition, people management, service delivery, etc.

This would mean a larger model, which would have an impact on the implementation and usage, as we could no longer expect an organizations to implement all the process areas. I come back to this issue further down in the section "Business Focus"

Process Areas

I would hope for more process areas, with a more limited scope. For instance, I do not see why estimation has been grouped into project planning and believe that this is a sufficiently complex and important activity to merit its own process area. The same idea goes for peer reviews, which should no longer be included in the verification process area as in the current release.

Process areas which are largely identical in different constellations today (e.g. VER and AVER) should be consolidated.

A number of process areas are expected at different maturity levels than that at which they are documented. This should be made obvious by breaking them down into smaller chunks which could allow for some practices to be implemented at lower levels (it is inconceivable that an organization is CMMI-DEV ML2 without doing any of the engineering practices; setting up an organizational process focus is necessary to reach level 2, even if it is not fully structured; causal analysis should guide your approach to improving from the start…)

Business Focus

The business focus of the model should be reflected in several ways which are now missing. I will start here with the scope of the model to be implemented and cover other aspects below under different titles. There should be a variety of groups of process areas which would be chosen based on the business intent of the organization using it. One organization may be interested in development, others in maintenance, service delivery, system integration, etc. Rather than having separate constellations (or models) for these different specialities, they should have a selection of process areas which they need to satisfy in order to be appraised at a given maturity level.

The selection of process areas to be covered would be based on a standard menu related to the work performed. Each combination would be clearly identified - you may have to include in your selection some process areas from all the current constellations if you are providing a significant service in systems integration...


Business Goals

Another aspect of business focus is the formulation of the goals and practices.

As a business, I do not necessarily understand why CMMI is requiring me to perform some tasks – the result is that many businesses are doing what they believe the model is asking them to do, without understanding, and being appraised at maturity levels they do not deserve because of the bureaucracy they have implemented in response to the continuous apparent requirement for “documentation”.

The goals should be formulated in terms of business results. Even if the goal is unrealistically optimistic, I would rather have the model tell me that “no bad surprises occur due to preventable problems” instead of being told that “preparation for risk management is conducted”. The same is true for many of the practices.

Proven Results

In addition to having goals expressed in terms of business results instead of activities, I would like to see a requirement that each goal be accompanied by a requirement for data demonstrating the benefit to the organization from having satisfied this goal.

Today, there is no clear definition of the word “institutionalized”, and it could be argued that a practice which has only been performed a couple of times is now institutionalized. Requiring a measurement which demonstrates that the organization has benefitted (less deviations, less rework, higher employee satisfaction…) from achieving the goal would ensure that it is being implemented usefully rather than just done to please the model.


Finally, wouldn’t it be nice if the whole thing, model, appraisal method, everything was actually written in English rather than in some incomprehensible lingo which most people cannot understand?

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

back to top