In an earlier posting I highlighted the clarification of the high maturity process areas in this new CMMI version. This time I’m going into changes in the model architecture, which is about how to deploy the CMMI by “tailoring” it toward your needs.
A warning upfront: This posting goes into how the CMMI models are build up, and how you can “tailor” them to get maximum benefit. The posting is quite complex, and requires a deeper understanding of and experience with the CMMI. If you are new to CMMI and process improvement, what follows may not be useful for you. But it is very relevant for CMMI professionals that want to get maximum business value when deploying the CMMI, and for the organizations that they are delivering value to!
There are 3 CMMI models released: CMMI for Acquisition, CMMI for Services, and CMMI for Development. The so called CMMI framework is the underlying structure for these models. There are 16 core process areas which are the same in the three models. In my opinion, the biggest benefit from this model architecture is that you can combine process areas of the different models into one roadmap of processes that would best serve the needs of an organisation. So if your organization develops software, delivers services, and acquires products, you don’t need to chose between the different CMMI models anymore, but combine the process areas from all models that are useful for you.
The CMMI V1.3 has maturity and capability levels, just as V1.2 had. But a major difference is that the description of maturity levels 4 and 5 have been simplified, by removing the generic goals for these maturity level. To my knowledge, this has no impact on the requirements for maturity level 4 and 5; the criteria for a maturity level have not been changed. Also, you can still map capability levels to maturity levels using equivalent staging. So it is possible for an organization to use the continuous representation to improve their performance, and still get a (staged) maturity level.
Throughout the model relationships among the process areas have been clarified. The relationships between the Requirements Management (REQM) process area and the Project Planning has been intensified by adding REQM to the basic Project management process areas. Also in the descriptions of the process areas the relationships have been clarified. This will significantly help people to deploy process areas more effectively.
The elaborations for the generic goals, which were previously described in section of the process area itself, have all been put in one section with the generic goals. The advantage of this way of subscribing is that the model doesn’t repeat the generic goals for each process area, making the CMMI smaller (in pages). But I see a risk that people become unaware of the generic goals when deploying a process area, because they are no longer mentioned together with the specific goals and practices. Given that many organizations have problems institutionalizing processes, I am afraid that the way CMMI V1.3 has documented the generic goals may increase the chance that these problems wil happen. Also, combining all the elaborations in one chapter makes it very hard to read and understand them. Since the models are also available in source (Word) format, you can of course gather all material of the process areas that you are deploying and make your own document, but that is quit cumbersome and error prone. Time will tell if this new way of documentation generic goals and elaborations works out.
I warned you that this would be a complex, technical posting. Deploying the CMMI is not an easy thing, and you need to have a good understanding of how the model is build before you start tailoring it to your situation. If you don’t have that understanding (yet), then you probably need an expert to help you with that which can be costly, and take quite some time before you start getting the benefits. There are some alternatives to this, one being to do the staged approach and deploy a fixed set of processes to increase your organizations maturity level, and another to use (pre-defined) CMMI Roadmaps. There have been lots of discussions about the the staged model vs continuous model, e.g. by the SEI, in the CMMI FAQ, in the constageduous approach from Tim Kasse, and in the books CMMI Distilled and CMMI survival guide to name a few. The CMMI Roadmaps, which are are a goal-driven approach to selecting and deploying relevant process areas from the CMMI, is less known in the CMMI community. In a next posting, I will describe the roadmap approach, and discuss how it can be used with the CMMI V1.3.