The Origins Of CMMI

Before receiving the “CMM” name, the first Capability Maturity Model-like framework was published in 1989 by Watts Humphrey in his book, Managing the Software Process. A few years earlier, the U.S. DoD announced a request for proposals (RFP) to address the excessive amount of money being spent on software that was either never delivered or delivered late with little of its expected functionality.

The contract awarded on the basis of the RFP was to establish what we know today as the Software Engineering Institute (SEI) at Carnegie Mellon® University. The SEI brought together representatives from academia, research, and industry to expose and promote practices demonstrated to be successful at avoiding the failures so beleaguering DoD software acquisition efforts. Carnegie Mellon’s framework of practices to address the DoD’s issue became the CMM. If we look at the genesis of the CMM, it predates the internet and nearly everything associated with internet technology. For that matter, CMM predates many software development, deployment, and infrastructure technologies, languages, and methods. We’ve all learned a lot in the past 20 years. When the DoD set out to address their “software dilemma,” the software world was different than it is today.

To color this context even further, everyone working to develop the initial CMM was looking for the solution to the “software problem” from the perspective that software is a component of a larger system and that if it failed, lives would be lost (e.g., aircraft, ships, weaponry, medical devices). Systems were evolved using careful and deliberate development paths according to lowerrisk, standardization-heavy and contractually-driven relationships between the developer and the customer.

In today’s frequent discussions of increasing globalization and the important role played by trust (i.e., level of social capital) in making effective collaboration happen across stakeholders, one might describe such a development context as exhibiting low trust. Users were typically not direct contributors to the evolution of the end product prior to field testing. They instead had to depend on the contracting relationship, requirements, and standards to deliver the product they needed.

This short history of CMMI focuses more on the past twenty years, but as in the case with Agile, the roots for many of the product development, project management, and process concepts found in CMMI have a long history. 7 This definition of trust may be clearer but more elaborate: “the willingness of a party to be vulnerable to the actions of another party based on the expectation that the other will perform a particular action important to the trustor, irrespective of the ability to monitor or control that other party” [Mayer 1995]. For the purposes of this report, the particular question being asked is whether there is a level of trust between the project and its customer that will allow them to effectively negotiate scope as the project progresses, without the customer requiring detailed accounts of project effort.

These comments may be an over-generalization, but they are intended to summarize the DoD software acquisition environment that existed at the time. Further, these comments explain why the practices in CMMI sometimes exhibit some of these same high ceremony and low trust characteristics found in the high-risk, government-contractor environment in which software failure could equal lives lost.Also, within the high-risk government-contractor environment at that time, the prevailing pattern of infrequent and monolithic deliveries contributed to the high costs associated with deployment, upgrade, and replacement (e.g., software embedded in fighter aircraft in the 1980s could not be upgraded over the air or over the internet). Hence, getting it right the first time was critically important.Furthermore, most of the organizations involved in this contractual environment were large organizations working on large complex projects.

Finally, the use of public money in government contracting (or similar high-visibility and highstakes situations) requires a level of accountability by all those involved that often drives all parties toward risk-averse behavior bordering more on protecting one’s own interests than on finding the most efficient win-win solution. Ceremonial but perfunctory activities help address the often competing and incompatible self-interests of all parties, but make operating in an open and transparent manner challenging, and reinforce the perception of low trust. Within a few short years, the CMM was expanded into several other models; these were point solutions developed to address non-software development projects. Also, the CMM and these variants increasingly became used internationally and by commercial industry. Organizations attempting to adopt more than one model on any given project quickly realized the challenges of
doing so and petitioned the SEI to consolidate the various CMMs into one model, which in 1998 led to a joint industry, government, and SEI team to create CMMI.

Of course, over the years that the CMM and CMMI have been maintained, inputs on what constitutes good management and development practice have increasingly come from a wider variety of industries and from users around the world. As a result, new ideas, standards, and practices are continually being incorporated into what is now the CMMI Framework.