CMMI V1.3: The CMMI Process and Measurement roadmaps

In two previous posting on the CMMI roadmaps for CMMI V1.3, I described how the project roadmap and the product and product integration roadmaps have been improved. This posting  covers the last 2 roadmaps: process and measurements.

What is a CMMI roadmap? A roadmap is a set of CMMI process areas that together serve an organization to identify and implement process improvements. CMMI roadmaps are an effective tool to start with the CMMI continuous representation; thus providing an alternative for the staged approach. Biggest benefit from the CMMI roadmap approach is the alignment of your process improvement initiative with the business goals, ensuring quicker and more effective business results. The CMMI roadmaps are described in a Technical Note, which is published by the Software Engineering Institute.

The CMMI process roadmap consist of Organizational Process Focus, Organizational Process Definition, Measurement and Analysis, Causal Analysis and Resolution and Process and Product Quality Assurance.The process area Causal Analysis and Resolution (CAR) has been extended to also cover process performance issues (additional to quality issues). This extension strengthens this roadmap, since CAR now provides feedback that the Organizational Process Focus and Organizational Process Definition process area can use to continuously improve processes. The usage of the Measurement and Analysis process area to steer CAR has been clarified, which makes it easier to use these two process areas in the process roadmap. In version 1.2, CAR was only applicable to quantitatively managed processes (CMMI level 4). Version 1.3 states that CAR can also be used with processes that are not quantitatively managed (CMMI level 2 or 3), but of course the result may be less. But it is good to read that CAR can now be combined with OPF and OPD directly, and that high maturity process areas are not required. The CAR process area now refers to the Decision Analysis and Resolution process area, this supports the extension of the process roadmap with DAR for situations where a formal decision process is needed to manage process improvement. The process area Organizational Proces Definition (OPD) now mentions examples when there may be a need to revise processes, e.g. when CAR has identified causes related to processes, or when process improvements have been identified and submitted to OPF. Also process tailoring has been clarified in OPD. In OPD, the measument repository has been elaborated and linked to the M&A process area.

The process area Organizational Process Focus (OPF) now mentions needs which may trigger process improvement, e.g. changing business requirements or the result of benchmarking studies. Also examples of process performance objectives are given. The process area Process and Product Quality Assurance (PPQA) contains limited information about deploying quality in agile organizations. Examples of objectives, measures and information catagories have been added to the process area Measurement and Analysis (M&A), making it much easier to deploy measurements. Also analysis of measurements has been clarified.

The CMMI measurement roadmap consists of Measurement and Analysis, Organizational Process Focus, Decision Analysis and Resolution and Process and Product Quality Assurance. The changes to the first 3 and the last process area have just been described in the process roadmap. The process area Decision Analysis & Resolution has been clarified, and support for quality attributes has been added.

My conclusion is that the interaction between the process areas in the process roadmap (OPF, OPD, M&A, CAR and PPQA) and the measurement roadmap (M&A, OPF, DAR and PPQA) has been intensified and clarified, resulting in a more coherent and effective roadmaps for improving organizational results. It is good to see that Root Cause Analysis is now recognized in the process management areas, enabling organization to learn and improve their way of working based upon major defects and disturbances. The support for agile, though still limited, helps to understand and assess agile organizations within the scope of the CMMI.

There are 3 CMMI V1.3 models released: CMMI for Acquisition (ACQ), CMMI for Services (SVC), and CMMI for Development (DEV). 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, and the above mentioned process and measurement roadmaps consist of core process areas. This implies that you can use these roadmaps also if you want to deploy the CMMI for Services or CMMI for Acquisition, and when needed can extend the roadmaps with process areas from these models.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 2 Comments


    Hello Ben,

    Nicely explained, yes when i coordinated for CMM V1.2 assessment in oct’2009 even i used to think there must be a strong linkage/ process traceability within these process areas and the PIID must be formed as a interactions between these process areas so that assessment team and project representatives can also understand the need of fulfilling certain specific practices for instance in case of DAR/ CAR, even though the TR008 was referring to one to another process areas in a very broad way.

    Somehow CMMI V 1.3 is trying to strengthen the linkage between these process areas. Even for continuous representation this might help and give a clear transparency of choosing the set of process areas for the organizational process improvement journey.

    I have a good friend through linkedin who always used to say if you take process improvement journey as a seperate project or initiative using these frameworks it will always have a less chance to see the real improvement rather it should be based on the need that can fulfill or improve customer values, satisfaction and intimacy.


  2. BenLinders

    Hi Raj,

    Fully agree, a process improvement initiative must be started from a business need, and should continuously show the delivered benefits. The cost of defects are high for many organizations, certainly when found in final testing or by customers.

    Root Cause Analysis lowers your defect rates, thus improving product quality and reducing project risks. It can be a quick win for any organization that is starting on a process improvement journey.

    Best regards,
    Ben Linders

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.