CMMI maturity levels are NOT implementation steps

One of the biggest mistakes organizations make when implementing CMMI (Capability Maturity Model Integration) is to use the maturity levels as a roadmap. Part of the confusion may stem from the CMMI documentation itself.¹ From the section titled, “Advancing Through Maturity Levels:”

Organizations can achieve progressive improvements in their maturity by achieving control first at the project level and continuing to the most advanced level—organization-wide performance management and continuous process improvement—using both qualitative and quantitative data to make decisions.

Since improved organizational maturity is associated with improvement in the range of expected results that can be achieved by an organization, maturity is one way of predicting general outcomes of the organization’s next project. For instance, at maturity level 2, the organization has been elevated from ad hoc to disciplined by establishing sound project management. As the organization achieves generic and specific goals for the set of process areas in a maturity level, it increases its organizational maturity and reaps the benefits of process improvement. Because each maturity level forms a necessary foundation for the next level, trying to skip maturity levels is usually counterproductive.

Emphasis mine. I feel this statement is misleading. Before I explain why, I will give a real quick overview of the CMMI maturity levels.

CMMI maturity levels and their characteristics

The five maturity levels are:

1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing

These are based on an assessment of the current capabilities of the organization. A level 1 organization’s processes are usually ad hoc and chaotic. “Maturity level 1 organizations are characterized by a tendency to overcommit, abandon their processes in a time of crisis, and be unable to repeat their successes.”² Level 2 organizations have documented processes but are not consistent across the organization. Level 3 is where processes and standards are defined at the organizational level but tailored for each project. The definitions are usually more rigorous at this level. “At maturity level 4, the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing projects.”³ This is arguably the most difficult maturity level to achieve. Statistics and metrics are used to assess quality and process performance throughout the life of projects. “A critical distinction between maturity levels 3 and 4 is the predictability of process performance. At maturity level 4, the performance of projects and selected subprocesses is controlled using statistical and other quantitative techniques, and predictions are based, in part, on a statistical analysis of fine-grained process data.”⁴  “Maturity level 5 focuses on continually improving process performance through incremental and innovative process and technological improvements.”⁵

The CMMI documentation doesn’t provide direction on which statistical methods to use, nor does it explain in detail how to implement a mature continuous improvement system. This is where quality management systems like ISO 9001 can provide more specific implementation requirements that are compatible with CMMI.

Implementing CMMI: Spiral vs. Waterfall

Take a look at the diagram used to describe the different maturity levels:

Look familiar? Readers with a software development background should recognize this pattern as a “waterfall model.” The implication is that the levels should be approached sequentially in numeric order. Let’s pretend we’re a brand new organization looking to “do things right” and want to “follow the CMMI” to be successful. Level 2 implies that we must create processes, but not to consider these processes at an organizational level, not to do any statistical analysis or metrics, and make no effort to monitor or even plan to monitor processes for improvement. Does that sound correct to you? It doesn’t to me. Sure, if there are time constraints, some process documentation and standardization is better than none. It’s also possible that an organization may not be prepared at the beginning of implementing CMMI to wrap their arms around the entire organization and may choose to focus on one or more smaller departments or projects to get a feel for it. Perhaps in those situations a waterfall model is best. However, one of the unwritten truths to the CMMI process areas is that a lack of (partial) implementation of the higher levels will make it very difficult to achieve the goals and practices of the lower level process areas. Project Planning (PP) and Project Monitoring and Control (PMC) are maturity level 2 process areas. Estimates of scope, work products, effort, and cost need to be done and some of the best data to use is based on past project performance. If there is no conformity across the organization to define how estimates are done, how can historical data ever be used reliably? If the organization has no statistical methodology in place, how will risk be assessed for PP? How can stakeholders commit to resources without some kind of Quantitative Project Management (QPM) implemented from level 4? How are progress reviews going to be performed effectively without measurements? How are corrective actions going to be documented, tracked and resolved without some form of Causal Analysis and Resolution (CAR) from level 5? Level 3 process areas have even more ties to the higher maturity levels. A waterfall implementation of CMMI may be quick to implement at first, but will require much more rework and interruption to daily operations to fix deficiencies. It’s a reactive model. We want to develop a CMMI implementation proactively.

The solution is to use a spiral model of implementation. I’m using the term differently than what Barry Boehm intended for software development back in 1986. I do recommend that an organization implements its processes in an iterative way rather than creating a giant monolithic set of directives that are implemented all at once. However, the “spiral” I’m referring to would be based on the process areas for each CMMI maturity level. Rather than apply process area goals and practices sequentially level-by-level, I suggest a holistic approach. Create a framework that includes every process area and gradually flesh them out in iterations. Process documentation should be written as if all process areas from all five maturity levels will be implemented. Do not put blinders on and ignore process areas above the intended maturity level assessment. The detail and completeness of the process areas beyond the planned assessment maturity level do not need to be as rigorous as the required process areas. Nevertheless, the inclusion of higher level process areas will provide guidance in defining and implementing the lower level areas.

References

1. CMMI Product Team, CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Software Engineering Institute, Carnegie Mellon University, 2010. http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm. Last visited on May 2013. p 29-30.
2. p 27.
3. p 28.
4. p 29.
5. p 29.