In october 2010, version 1.3 of the Capability Maturity Model Integration (CMMI) has been released by the Software Engineering Institute. I’ve published several articles on the benefits of CMMI V1.3. This is (for now) the last article, which sums it all up.
The main changes in CMMI V1.3 as mentioned in the SEI News are clarifications of the high maturity process areas, alignment of the representations (staged and continous) and the addition of modern engineering practices like agile.
The clarifications to the high level maturity areas are a big step forward. The new process area Organizational Performance Management (OPM) links business objectives and organizational improvement; thereby setting the stage for and creating a business case in process improvement. I also like the improved process area Quantitative Process Management (QPM), which helps projects to select, deploy and use measurements. This process area includes Root Cause Analysis, which is crucial for project and teams to learn from mistakes and prevent similar mistakes to happen in the future.
The way the staged and continuous representation is documented has changed. The description of maturity levels 4 and 5 have been simplified, by removing the generic goals for these maturity level. Mapping capability levels to maturity levels using equivalent staging makes it possible for an organization to use the continuous representation to improve their performance, and still get a (staged) maturity level. The elaborations for the generic goals, which were previously described in the 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 it makes 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 this increases the chance that such problems wil happen.
In the new CMMI V1.3, agile has been included with an interpretation guideline and by adding notes to the applicable process areas in the introduction on how to interprete agile practices. Some agile techniques or aspects are not mentioned in the CMMI V1.3. It doesn’t mention specific methods, like Scrum, XP or DSDM. It mentions some agile techniques, like user stories, backlogs, story cards, pair programming, frequent builds, retrospectives, but doesn’t mention others like planning poker, test driven development, burn down charts, etc. There is still room for interpretation in the CMMI process areas, which in my opinion is both bad and good. Bad because not including certain agile term makes it more difficult to recognize and map agile practices to the process area. But the good thing is that the CMMI defines the “what”, and not the “how”, leaving room for organizations to deploy agile in such a way that they reach the business (and CMMI) goals.
There are 3 CMMI V1.3 models released: CMMI for Acquisition (ACQ), CMMI for Services (SVC), and CMMI for Development (DEV). The new CMMI version makes it easier to combine process areas of the different models into one roadmap of processes that would best serve the needs of an organization. The selected process areas should be linked to the main business issues that your organization is facing, to assure that your investment will deliver business results.
The changes in version 1.3 makes it easier to deploy the CMMI, and to get higher business benefits from your process improvement initiative. For more information about the CMMI, please see my article CMMI V1.3: where to find information. If you have any question on the CMMI, feel free to comment on this article.
