Objectives of CMMI

Contrary to what most developers believe, CMMI’s sole purpose isn’t to make their life difficult. In fact, it’s just the opposite. In their book, CMMI Distilled: A Practical Introduction to Integrated Process Improvement (Addison-Wesley, 2003), Ahern, Clouse, and Turner paint a picture of the business objectives of CMMI that include having the ability to consistently produce higher-quality products and services, create additional value for sponsors and corporate stakeholders by implementing cost saving techniques and best practices, increasing market share by increasing both quality and velocity, and, believe it or not, increase employee satisfaction. As we’ve already stated, CMMI represents an integration of many models and provides a more unified approach for model integration and consolidation. This achievement means that CMMI helps to eliminate inconsistencies between various similar underlying models, increases clarity and consistency, and provides a common glossary and set of terminology. This integrated model also works to provide a more repeatable and consistent style of constructing maturity models while at the same time respecting legacy efforts.

Truly, CMMI is not about authoring documents but rather gaining efficiencies in the construction of software or delivery of service. We have observed, however, that this persona has arisen due to reasons much less about structure of CMMI than about the methods by which CMMI goals and practices have been implemented, which usually employ a more traditional document artifact–based model. In many cases, the recommendation that is provided by CMMI is to track information. The CMMI model does not dictate the method by which information is tracked. Traditional methods have chosen document-based artifacts for this purpose, a method the authors of this book do not necessarily endorse. For example, take the CMMI Engineering Requirements Development and Requirements Management process areas. Nowhere in the definition of this process area does it state that team members have to create lengthy documents by using Microsoft Office Word; in fact, what this process area suggests is that your teams should simply develop product requirements. If you can do that with a user sitting right next to you, fantastic! Let’s think about the Project Management process areas as another example. One of the practices within this process area is to manage risk and to monitor the project against a plan. Even agile development has some level of a plan (it might not be overly specific, but it’s a plan)-yet it doesn’t need to be in a thick document or follow a CMMI-prescribed document template to be compliant with CMMI. Many organizations choose to adopt a document-driven approach to help govern and control the process (“When this document is submitted and approved, go to step 2”). In fact, CMMI SCAMPI Distilled suggests that more than 400 document types and 1000 artifacts are required to facilitate a CMMI appraisal-that’s a lot of documents, none of which were likely fun to create ( CMMI SCAMPI Distilled: Appraisals for Process Improvement, SEI Series in Software Engineering, by Ahern, Armstrong, Clouse, Ferguson, Hayes, and Nidiffer, Addison-Wesley Professional, 2005). We should not confuse the act of collecting and tracking information (and the information that can be further inferred from it) with the creation of documents. Ultimately, you will need to track information; however, the manner in which you choose to store that information should best suit the needs of your organization-and in our opinion, documents are rarely adequate.

One reason that CMMI is associated with obsessive documentation is the need to provide objective evidence for a CMMI appraisal. Objective evidence consists of qualitative or quantitative information, records, or statements of fact pertaining to the characteristics of an item or a service or to the existence and implementation of a process element ( Software Engineering Institute: Standard CMMI Appraisal Method for Process Improvement [SCAMPI], Version 1.1: Method Definition Document, December 2001, page 1–11 and Glossary).

Note 

Microsoft Visual Studio Team System uses several different approaches to help an organization produce objective evidence for a CMMI appraisal. First, evidence gathering is a by-product of the normal development cycle. In other words, Visual Studio Team System captures process-related evidence automatically in the normal course of using the tool. Second, Visual Studio Team System generates reports, not documents, as the artifact-generation tool.

The most important aspect of CMMI is its underlying theme of continual process improvement and the management of organizational change. This aspect of CMMI will force you to look at your processes and say, “Yeah, that didn’t work, let’s try something new,” instead of simply continuing to make bad choices or relying upon heroics for varied results. On the other hand, you may find things that worked really well and say, “Hey, let’s make sure we do that again.” If you find that your organization is producing too much documentation without making any positive impact on the quality of your process, software, or services, CMMI promotes a model that encourages you to change to help ensure that the highest degree of value is flowing through and out of your team and your organization. CMMI stresses gradual change because it is very difficult to simply jump to a high level of CMMI maturity or capability. This gradual and yet continual model of positive change is really the end goal of CMMI, achieved at Level 5, which focuses on continual process improvement that encourages organizational improvement and innovation around process and technology.